|
|
Hauptseminar
Robotik: Simulation for Intelligent Transportation
Systems, (c) byMarkus Herbord
1. Allgemeine Ziele:
2. Verschiedene Simulatortypen:
3. Echtzeitfaktoren in Fahrsimulatoren:
4. Hank: Virtual Driving Environment
3. Echtzeitfaktoren in Fahrsimulatoren:
4. Hank: Virtual Driving Environment
HANK ist ein Gemeinschaftsprojekt von:
4.1. Eigenschaften:
Ein Schwerpunkt liegt bei der Entwicklung, Anwendungen
unterstützender Technologien, deren Aufgabe die
interaktive Simulationen zur Untersuchung menschlichen
Fahrverhaltens ist. Wichtig war die Implementierung
starker und flexibler Mechanismen, um Szenarios undFahrzeugeigenschaften,
sowie Fußgänger und andere
Objekte zu unterstützen.
(Aisha Walcott und Bryan Paulsmeyer arbeiten z.B. an
einem HANK-Fahrrad)
4.3. Forschungsziele:
Definieren und erweitern des Verhaltens von Fahrzeugen,
Fußgängern und Verkehrszeichen in einer
höheren
Programmiersprache.
Entwicklung neuer physikalischer Modelle, simulierter
Objekte, durch ändern des Aussehens, den Freiheits-
graden oder den zugrundeliegenden dynamischen Eigenschaften
von Objekten.
Erzeugen von "Driving Scenarios", mittels Hochsprachenprogrammen,
die das Objektverhalten online während
der Simulation steuern.
Entwicklung von Straßenmodellen durch Modifizierung
vorhandener Straßenmodelle oder entwerfen komplett
neuer Modelle.
4.4. Software:
Eine Datenbank, in der die Eigenschaften eines Straßennetzwerks abgelegt sind.
Eine Programmiersprache zur Verhaltensspezifikation, sowie
eine Umgebung zur Laufzeitausführung, basierend
auf HCSM
Ein Laufzeit - Scheduler, der die fundamentalen Simulationsprozesse
ausführt. Zu den fundamentalen Simulations-
prozessen gehören Prozesse für das Verhalten,
Dynamik, Bilddarstellung, Ein-/Ausgabe und Datensammlung.
Hank verfügt nicht über Laufzeit
- Grafik - Bibliotheken. Derzeit wird Silicons "Graphics Performer"für
die Bild-
erzeugung verwendet. Szenen - Datenbankmodelle werden
mittels "Mulitgen" erzeugt.
4.5. Prozeß Organisation
Der Simulator ist als Menge unabhängiger paralleler
Prozesse organisiert, in denen die wichtigsten Funktionen
implementiert sind:
Der Darstellungsprozeß ist für die Aktualisierung
der Bildgenerator spezifischen Datenbank und der Initialisier-
ung des Rendering Prozesses verantwortlich. Um weiche
Bewegungen und fortlaufende Bilderzeugung zu
garantieren, läuft dieser Prozeß mit 60-76
Hz.
Der Dynamik - Prozeß führt ein Dynamik
Modell für jedes Objekt der Datenbank aus, welches fortwährend
das
physikalische Verhalten von simulierten Objekten beschreibt.
Dieser Prozeß läuft mit einer Frequenz größer oder
gleich der des Darstellungsprozesses.
Der zustandsbehaftete und logische Entscheidungen
treffende Aspekt des Objektverhaltens ist in HCSM kodiert.
Diese unterstützenden Berechnungen sind normalerweise
komplizierter als die Dynamik- und Darstellungsberech-
nungen, weshalb der Verhaltensprozeß mit niedriger
Frequenz läuft (ca. 5 Hz).
Der Ein-/Ausgabeprozeß empfängt Daten
des Lenkrads, Brems- und Gaspedals.
Um diese Daten filtern zu können, läuft dieser
Prozeß mit einer sehr hohen Priorität.
Die Frequenz der anderen Prozesse wird an deren momentane
Wichtigkeit angepaßt.
Prozesse interagieren über eine Datenbank, in der
Informationen über die virtuelle Welt abgelegt werden.
Updates dieser Datenbank müssen Synchronisiert werden,
um Konflikte zu vermeiden und Konsistenz zwischen den
verschieden häufig laufenden Prozessen zu gewährleisten.
Diese Datenbank wurde mittels Shared Memory Konzepten
implementiert, um den Prozessen effizienten Zugriff zu
gewähren.
4.6. Szenario Modellierung
Die HCSM Verhaltensmodelle in Hank stellen geeignete Methoden
bereit , um komplexe Szenarios aufzubauen. Um
die Effizienz von Aktionen vergleichen zu können,
müssen die essentiellen Punkte eines Ereignisses oder einer
Situation von Versuch zu Versuch wiederholt werden können.
In HANK werden "HCSM Director Objects" verwendet, um kritische Situationen und Ereignisse zu erzeugen.
Diese "Directors" sind lediglich Verhaltens ? Objekte.
Die "Directors" steuern die Simulation durch Datenbankanfragen
und senden Anweisungen an Fahrzeuge, Lichtsignale und
Fußgängerobjekte.
4.7. Sonstiges
Bei einem Projekt von Jillian M. Tidd and Lea D. F. Wittie
wurde sogar versucht, Stereobilder mit dem Fahrsimulator zu
vereinen. Mehr zu diesem Thema findet man unter:http://www.cs.uiowa.edu/~lwittie/paper.html
5. SHIVA
Simulated Highways for Intelligent Vehicle Algorithms
Shiva der Film:
5.1. Ziele:
5.2. Implementierung
SHIVA läuft auf SUN SPARC Workstations (unter X) und SGI Workstations.
Eine Klassenhierarchie für Sensoren und Fahrzeuge
sowie Displayanzeigen ermöglichen dem Benutzer Algorithmen für
spezifische Fahrzeug/Sensor Konfigurationen zu entwickeln
und diese dann mittels graphischer Tools zu debuggen.
Simulierte Szenarios können interaktiv online in
3D dargestellt werden.
Informationen wie zum Beispiel Durchsatz können offline abgefragt werden.
SHIVA ist objektorientiert in C++ implementiert.
5.3. Straßen
Durch die objektorientierte Programmierung von SHIVA ergeben
sich folgende Klassen zur Repräsentation der Straße:
RoadSegment, RoadSlices und RoadPosition
Autobahnen sind als Gruppen verbundener Straßensegmente
(RoadSegment) organisiert, wobei jedes Segment
länglich mit "beliebiger" Form, jedoch fester Fahrbahnanzahl,
ist.
Durch die Verbindung von Segmenten lassen sich beliebige
Autobahnstrukturen realisieren. Jedes Segment enthält
weitere Informationen z.B. über Fahrbahnbegrenzungen,
Geschwindigkeitsbegrenzungen und Oberflächenstruktur.
Spezielle Arten von Straßensegmenten lassen sich
ableiten.
Jedes "RoadSegment" wird in Straßenstreifen ("RoadSlices")
zerlegt, wobei diese stets senkrecht die Fahrbahn
schneiden und durch einen Ursprung und einen Offset-Vektor
definiert sind.
Der Abstand zwischen zwei Streifen hängt vom erwarteten Verkehr und der Kurvenkrümmung ab.
Die Klasse "RoadPossition" ist ein transparentes Interface
zwischen der Straßendarstellung und andern Objekten in
SHIVA.
Obwohl die Straßen diskret dargestellt sind, kann
ein Fahrzeug beliebige Positionen einnehmen und u.U. sogar die
Straße verlassen (falls der Fahrbahnerkennungsalgorithmus
hinreichend schlecht ist).
*) Unter "Driver Models" versteht man den Entscheidungsalgorithmus,
da man davon ausgeht, daß
sowohl automatisch, als auch manuell gesteuerte Fahrzeuge
verwirklicht werden können.
5.4. Fahrzeuge
Kinematisch exakt, zwei - achsig und vorderradgelenkt.
Es werden drei Fahrzeugklassen, mit ihren jeweiligen physika-
lischen Charakteristika, unterschieden
Zusätzlich zu den herkömmlichen physikalischen
Eigenschaften, besitzen alle SHIVA Fahrzeuge folgende Untersysteme:
5.5. Controller
Die SHIVA Controller sind mit dem selben Interface ausgestattet,
wie die echten Controller des Navlab II Projekts, wo-
durch sichergestellt wird, daß die simulierten
Fahrzeuge nur Aktionen durchführen, wie sie auch in echten Fahrzeugen
möglich sind und umgekehrt, Algorithmen, die für
simulierte Fahrzeuge entwickelt wurden, ohne Änderungen, auf die
Navlab Fahrzeuge übertragbar sind.
Folgende Kommandos werden unterstützt:
Viele andere Simulatoren arbeiten mit unrealistischen
Annahmen über die Sensoren. So wird zum Beispiel angenommen,
das die Beschleunigung anderer Fahrzeuge direkt und perfekt
gemessen werden kann, Autobahnen keine Kurven haben
oder man geht von "durchsichtigen" Fahrzeugen aus.
Im Gegensatz dazu wird bei SHIVA darauf Wert gelegt, daß
die entwickelten Algorithmen erfolgreich mit echten Ein-
gabewerten arbeiten können. SHIVAs Sensorcharakteristika
enthalten sowohl den Sensortyp (Fahrbahnerkennung,
Fahrzeugerkennung, GPS) als auch Detailstufen (z.B.:
Rauschempfindlichkeit).
5.6.1. Entfernungssensor
Als Entfernungssensor kommt ein Laserscanner mit benutzerdefinierter
Reichweite, Blickfeld und Auslösung (definiert
durch die Anzahl der Strahlen n), zum Einsatz. Dabei
werden die n Strahlen gleichmäßig über das Blickfeld verteilt.
Jeder
Strahl liefert eine Distanz zurück. Um realistisch
zu sein, wird der Winkel zwischen zwei Strahlen und das zurückgelieferte
Signal durch ein gaussísches Rauschen verändert.
5.6.2. Fahrbahnerkennung
Die Fahrbahnerkennung funktioniert Vision basiert und
baut auf dem "ALVINN road follower" auf und liefert Informatio-
nen über die gegenwärtige Straßengeometrie.
L ist dabei die Distanz, mit der nach vorne gescannt wird. L ist lediglich
ein
Erfahrungswert, was dazu führt, daß falls
L zu kurz ist, die Fahrzeugkontrolle unsicher wird, andererseits falls
L zu lang ist,
das Fahrzeug anfängt zu schlingern. Bei geringer
Geschwindigkeit ist ein Wert von 15m, bei hoher Geschwindigkeit 25m,
gut geeignet. SHIVA unterstützt
auch Systeme zur Fahrbahnerkennung, die das Fahrzeug aktiv steuern.
5.6.3. Positionierung
SHIVA ist in der Lage zwei Arten von Positionierungssensoren
zu simulieren: GPS und Dead-Reckoning. Bei
beiden
Sensoren werden die Fahrzeugkoordinaten in globalen Koordinaten
zurückgegeben. Die sich jedoch in ihren Rausch-
eigenschaften unterscheiden.
5.6.4. Fahrzeugerkennung
5.7. Kommunikation
Unter der Voraussetzung, daß die anderen Fahrzeuge
gleichwertig ausgestattet und in Reichweite sind, können sie
durch ein asynchrones Nachrichtensystem kommunizieren.
Dadurch können Annahmen über Aktionen im Voraus
zwischen den Fahrzeugen ausgetauscht werden und dadurch
die Gefahr von Kollisionen verringert werden, wie hier
zum Beispiel beim sogenannten "Pinch Manöver".
5.8. User Interface
SHIVAës Design trennt die Simulation vom Benutzerinterface,
ohne dabei auf Offline-Animationen zurückzugreifen.
Man kann zwischen verschiedenen Kameraperspektiven wählen
(Fahrersicht, Vogelperspektive, "Fahrzeugsicht", u.a.).
Derzeit werden drei Schnittstellen unterstützt:
TTY, X, SGI
Weiterhin existiert eine Infobox, in der der Benutzer
für ein ausgewähltes Fahrzeug die Attribute betrachten kann.
5.9. SHIVAís Features
| Design | Implementierung |
| genaue Beschleunigung
genaue Dynamik |
ja, mittels v(t)dt
nur in erweiterten Versionen |
| Straßengeometrie
Highway Unterstützung Stadtstraßen Fahrzeugtypen |
2D
ja nein PKW, LKW, Bus |
| Fahrzeugmodelle
Motormodelle Suspension Räder-/Oberflächenmodelle Sensor Modelle Driver Models |
mehrere, Benutzerdefiniert
nein nein nur in erweiterten Versionen mehrere, Benutzerdefiniert mehrere, Benutzerdefiniert |
| Verkehr | heterogen, gemischter Verkehr möglich |
| Offline Simulation
Simulation und visuelle Darstellung Simulationsfortsetzung |
ja, auf verschiedenen Plattformen
ja bedingt: in Datei speichern und wiederherstellen |
| interaktives Debugging
interaktive Szenario Generierung aktive Steuerung eines Fahrzeugs durch Benutzer |
ja
ja ja, jedoch nur auf dem "tactical level" |
6. Sonstige Forschungen
6.1. PARK
Automatisches Einparken mit Fuzzy Control
Beim PARK Projekt geht es darum, ein Modellauto rückwärts
in eine Parklücke zu manövrieren. Dabei werden folgende
Anforderungen an das Fahrzeug gestellt:
6.2. VAMP/VaMoRs-P
VAMP steht für "Versuchsfahrzeug für
autonome
Mobilität
und Rechnersehen ? PKW"
6.2.1. VAMP Features:
6.2.3. Sensoren:
6.2.4. Bordrechnersystem:
Transputer-basiert:
16-bit T-222 für
PC-486 und Laptop-486 als Hostrechner für:
Rechneransteuerbare Regler:
Literatur:
http://www.cs.cmu.edu/afs/cs/usr/rahuls/www/shiva.html
http://almond.srv.cs.cmu.edu/afs/cs.cmu.edu/user/rahuls/www/shiva.html
http://www.unibw-muenchen.de/campus/LRT/LRT13/Fahrzeuge/VaMP.html
http://www.ccad.uiowa.edu/research/ids/ (große Bilder und Filme Sammlung)
http://www.cs.uiowa.edu/~lwittie/paper.html
