Komplexes Rangieren und Navigieren eines autonomen

Masterarbeit
Komplexes Rangieren und
Navigieren eines autonomen
Fahrzeuges auf unkartiertem
Gelände
Betreuer:
Prof. Dr. Raúl Rojas
Verfasser:
Lars Marten
29. März 2011
Freie Universität Berlin
Institut für Informatik
Erklärung
Hiermit versichere ich, die vorliegende Arbeit selbstständig und unter ausschließlicher
Verwendung der angegebenen Literatur und Hilfsmittel erstellt zu haben.
Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde
vorgelegt und auch nicht veröffentlicht.
Berlin, 29. März 2011
I
Vorwort
Diese Arbeit stellt den Abschluss zum Master of Science (M.Sc.) meines Masterstudiums
in der Fachrichtung Informatik an der Freien Universität Berlin dar. Angefertigt wurde
diese Arbeit am Institut für Informatik der FU Berlin in der Arbeitsgruppe Künstliche
Intelligenz im Rahmen des Projekts AutoNOMOS.
Die AG Künstliche Intelligenz befasst sich mit einer Vielzahl von Projekten, wie z.B. der
Entwicklung von fußballspielenden humanoiden Robotern oder autonomen Fahrzeugen.
Im Rahmen dieser Masterarbeit wurde ein Konzept für ein Zonenverhalten von autonomen Fahrzeugen entwickelt und implementiert, mit dem Pfade auf unkartiertem Gelände
geplant und Missionen abgefahren werden können.
An dieser Stelle möchte ich mich bei Prof. Dr. Raúl Rojas für die Betreuung dieser
Arbeit bedanken. Des Weiteren sei besonderer Dank an Miao Wang gerichtet, der mir
jederzeit die vollste Unterstützung zukommen ließ. Besonderer Dank gilt auch an Dr.
Daniel Göhring, Tinosch Ganjineh, Fabian Wiesel und Sebastian Hempel sowie dem
AutoNOMOS-Team, die alle stets ein offenes Ohr für meine Fragen hatten und mit Rat
und Tat zur Verfügung standen.
II
Kurzfassung
Im Rahmen des AutoNOMOS Projektes werden Technologien für die fahrerlosen Fahrzeuge der Zukunft entwickelt. Neben dem Straßenverkehr gibt es Szenarien, in denen
die Navigation des Fahrzeuges ohne Verkehrsregeln und vorhandenen Kartenmaterial
benötigt wird. Solche Szenarien sind zum Beispiel verstopfte Kreuzungen oder das Befahren von Parkplätzen.
Ziel dieser Masterarbeit ist es, ein Zonenverhalten zu entwickeln, mit dem Pfade auf
unkartiertem Gelände geplant und Missionen abgefahren werden können. Für die Entwicklung eines solchen Verhaltens, wird zunächst ein Konzept mit den Anforderungen
und der Architektur für ein entsprechendes Modul zusammengestellt. Dieses Modul wird
in das vorhandene System eingebunden und nutzt für die Kommunikation mit anderen
Modulen die bestehenden Schnittstellen. Die erarbeiteten Konzepte werden anschließend
implementiert. Um die Suche nach einem Pfad zu beschleunigen, werden Heuristiken für
die Reduzierung des Suchraumes eingesetzt. Außerdem müssen Hindernisse beachtet
und Kollision vermieden werden. Rückwärtsfahren kann als zusätzliche Dimension in die
Planung eingebunden werden, um Rangiermanöver zu ermöglichen. Zusätzlich wird ein
Modul zur Visualisierung entwickelt. Da ein besonderes Augenmerk auf die Performance
gelegt wird, werden Profiler zur Optimierung eingesetzt. Das Modul wird in der Simulationsumgebung und am Testfahrzeug innerhalb verschiedener Szenarien getestet und
bewertet. Weiterhin werden alternative Ansätze für die Algorithmen der Pfadplanung
betrachtet und mit der implementierten Lösung verglichen.
III
Abstract
Within the framework of the AutoNOMOS project technologies for the driverless vehicles of the future are being developed. Besides the traffic there are scenarios in which a
navigation of the vehicles is required without traffic regulations and available cartographical material. Such scenarios are for instance blocked intersections or the driving on
car parks.
The aim of this Master’s Thesis is to develop a zone behavior, with which paths can
be planned on unmapped terrain and to get to one mission after another. For the development of such a behaviour a concept with the requirements and the architecture for a
specific module will be created first. This module will be integrated in the existing system
und it uses for the communication with other modules the interfaces being available. The
developed concepts will be implemented afterwards. To accelerate the search for a path
heuristics will be used for the reduction of the search space. Furthermore, barriers must
be considered and collisions avoided. To make maneuvers possible reversing the vehicle
can be involved in the planning as an additional dimension. Apart from that a module
for visualization will be developed. Since special attention will be given to performance
profiler will be used for optimization. The module will be tested and evaluated in the
simulation environment and on the test vehicle within different scenarios. Furthermore,
alternative basic approaches for the algorithms of the path planning will be looked at and
compared with implemented solutions.
IV
Inhaltsverzeichnis
Erklärung
I
Vorwort
II
Kurzfassung
III
Abstract
IV
1 Einleitung
1.1 Problemstellung und Zielsetzung . . . . . . . . .
1.2 Rennen zwischen autonomen Fahrzeugen . . . .
1.3 Fahrerassistenzsysteme und ihre Kategorisierung
1.4 Komponenten autonomer mobiler Roboter . . .
1.5 Eigenschaften von Echtzeitsystemen . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
5
7
2 Pfadplanungskonzept
2.1 Verwandte Arbeiten . . . . . . . . . . . . . .
2.2 Grundprinzipien der Navigation . . . . . . .
2.3 Steuerungsarchitekturen autonomer Roboter
2.4 Annahmen zum Fahrzeugmodell . . . . . . .
2.5 Orocos Real-Time Toolkit . . . . . . . . . .
2.6 Schnittstellen zum Zonenverhalten . . . . . .
2.7 Straßennetz und Zonen . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
11
13
14
15
16
17
3 Realisierung
3.1 Aufbau des FreeFormNavigation Moduls . . . . . . .
3.2 Pfadplanungsalgorithmus . . . . . . . . . . . . . . . .
3.2.1 A*-Algorithmus . . . . . . . . . . . . . . . . .
3.2.2 Verwendung von kontinuierlichen Koordinaten
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
23
23
25
V
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3
3.4
Details zur Pfadplanung . . . . . . . . . . .
Heuristiken für den kürzesten Weg . . . . .
3.4.1 Nicht-Holonom ohne Hindernisse . .
3.4.2 Holonom mit Hindernissen . . . . . .
3.5 Richtungswechsel und Rückwärtsfahren . . .
3.6 Konvertierung des Pfades zum Plan . . . . .
3.7 Fahren von Missionen und Einparkmanöver
3.8 Visualisierung . . . . . . . . . . . . . . . . .
3.9 Verwendung des Moduls . . . . . . . . . . .
3.10 Performanceoptimierungen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
29
30
32
33
35
37
38
38
40
4 Analyse und Test des Moduls
42
4.1 Einsatz von Werkzeugen zur Analyse . . . . . . . . . . . . . . . . . . . . 42
4.2 Simulationsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Testfahrzeuge der Freien Universität Berlin . . . . . . . . . . . . . . . . . 43
5 Alternative Ansätze
45
5.1 Anytime Dynamic A* . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Rapidly-Exploring Random Trees . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Vergleich zur implementierten Lösung . . . . . . . . . . . . . . . . . . . . 47
6 Zusammenfassung und Ausblick
49
Literaturverzeichnis
51
Abbildungsverzeichnis
53
Abkürzungsverzeichnis
54
Anhang
55
6.1 A*-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 RRT-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Anytime Dynamic A*-Algorithmus . . . . . . . . . . . . . . . . . . . . . 57
VI
1
Einleitung
Im Kapitel 1 werden einige allgemeine Aspekte im Kontext der Arbeit vorgestellt. Dabei wird zunächst die Problemstellung und die Zielsetzung dieser Arbeit definiert (1.1).
Besonders die Rennen zwischen autonomen Fahrzeugen haben die Entwicklung und Forschung im Gebiet der autonomen mobilen Roboter in den letzten Jahren vorangetrieben
(1.2). Viele daraus entstandene Projekte werden heute noch weiterhin durchgeführt, wie
z.B. das Projekt AutoNOMOS der Freien Universität (FU) Berlin. Auch die zunehmende
Akzeptanz und Nachfrage nach Fahrerassistenzsystemen fördern zusätzlich die Weiterentwicklung von autonomen Systemen. Unter 1.3 werden die verschiedenen Kategorien
von Fahrerassistenzsystemen mit dazugehörigen Beispielen beschrieben. Anschließend
werden die Komponenten von autonomen mobilen Robotern wie Sensoren, Aktoren und
Bussysteme mit entsprechenden Beispielen erläutert (1.4). Bei autonomen Fahrzeugen
handelt es sich um Echtzeitsysteme, deren Eigenschaften unter 1.5 aufgezählt werden.
Im zweiten Kapitel werden die Themen für den Entwurf eines Konzeptes zur Pfadplanung
diskutiert. Anschließend wird im Kapitel 3 die im Rahmen dieser Arbeit entwickelte
Lösung detailliert vorgestellt. Die Lösung basiert dabei auf den Entwurf aus Kapitel 2.
Das Kapitel 4 beschreibt die Methoden und Mittel für die Tests des entwickelten Moduls.
Alternative Ansätze für die Implementierung der Pfadplanung werden im Kaptitel 5
vorgestellt und mit der entwickelten Lösung verglichen. Schließlich folgt im Kapitel 6
eine Zusammenfassung mit Ausblick auf mögliche Weiterentwicklungen.
1.1 Problemstellung und Zielsetzung
Im Rahmen dieser Arbeit soll ein Verhalten entwickelt werden, um ein autonomes Fahrzeug auf unkartiertem Gelände zu navigieren. Beim Problem der Pfadplanung ist im
Allgemeinen eine Startposition, eine Zielposition und eine Umgebungskarte gegeben.
1
1.2. RENNEN ZWISCHEN AUTONOMEN FAHRZEUGEN
Gesucht ist nun eine Kombination von Aktionen, um den Roboter kollisionsfrei vom
Start- zum Zielpunkt zu navigieren. Dabei ist es erwünscht, dass der Weg möglichst
kurz bzw. günstig bewertet ist und möglichst schnell gefunden wird. Die Navigation
stellt für einen mobilen Roboter eine der elementaren Funktionen dar, um Aufgaben in
Bezug auf die Roboterumgebung ausführen zu können.
Das Verhalten soll als ein eigenständiges Modul realisiert werden, das über bestehende
Schnittstellen in das vorhandene System integriert werden kann. Für die Beschleunigung der Pfadplanung müssen Heuristiken entwickelt werden, um so den Suchraum einzuschränken. Außerdem wird ein Zugriff auf das Straßenmodell und den Missionsdaten
benötigt, um entsprechende Missionen abfahren zu können. Schließlich muss der gefundene Pfad in eine für den Controller abfahrbare Form konvertiert werden. Abschließend
soll das Modul analysiert, innerhalb verschiedener Szenarien getestet und mit anderen
Ansätzen verglichen werden.
1.2 Rennen zwischen autonomen Fahrzeugen
Die Defense Advanced Research Projects Agency (DARPA) hat insgesamt drei Rennen
zwischen autonomen Roboterfahrzeugen organisiert. Ziel dabei war es, die Entwicklung
von vollkommen autonom fahrenden Landfahrzeugen weiter voranzutreiben. Dazu wurden für die Gewinner jeweils Preisgelder in Millionenhöhe ausgesetzt, allerdings unter
bestimmten Bedingungen wie z.B. Zeitvorgaben oder die Beachtung von den jeweiligen
Regeln. Das erste Rennen, die DARPA Grand Challenge 2004, fand in der MohaveWüste in den USA statt. Allerdings gelang es keinem der 15 Teams die Strecke von
241 Kilometern erfolgreich abzufahren. Der Favorit namens Sandstorm der Universität
Carnegie Mellon legte lediglich 12 Kilometer zurück bis das Fahrzeug von der Strecke
abkam, ein Hindernis rammte und schließlich Feuer fing.
Daher wurde der Wettbewerb mit der DARPA Grand Challenge 2005 ein Jahr später
wiederholt. Nun registrierten sich 195 Teams für die etwa 212 Kilometer lange Strecke.
Fünf Teams absolvierten die Strecke und vier davon in der vorgegebenen Zeit von zehn
Stunden. Sieger war mit unter sieben Stunden Stanley, ein modifizierter VW Touareg
der Stanford Universität.[1] Die größten Streckenabschnitte mussten dabei meist durch
das offene Gelände quer durch die Wüste absolviert werden.
Im dritten Rennen der DARPA Urban Challenge 2007 änderten sich noch einmal die
Bedingungen grundlegend. Nun mussten Parcours in einem bebauten Gebiet einer verlassenen Kaserne in Kalifornien absolviert werden. Dabei wurde der Stadtverkehr durch
andere autonome Fahrzeugen sowie durch zusätzliche von Menschen gesteuerte Autos
simuliert. Nun mussten auch Vorfahrtsregeln beachtet werden. Allerdings waren die Anforderungen im Vergleich zum realen Stadtverkehr etwas reduziert, da es hier z.B. keine
Ampeln oder Fußgänger gab. Dabei durften öffentlich zugängliche Signale wie z.B. GPS
benutzt werden, aber während des Rennens war das Versenden von Steuerkommandos
2
1.3. FAHRERASSISTENZSYSTEME UND IHRE KATEGORISIERUNG
an die Fahrzeuge nicht erlaubt. Sieger wurde diesmal das Team Tartan Racing der Carnegie Mellon Universität mit dem Fahrzeug Boss, einem umgebauten Chevy Tahoe.[3]
Zweiter wurde das Stanford Racing Team mit dem VW Passat Junior.[2] Unter den
deutschen Teams war auch die Freie Universität vertreten, die mit dem Dogde Caravan
Spirit of Berlin das Halbfinale erreichte.
1.3 Fahrerassistenzsysteme und ihre Kategorisierung
Bei Fahrerassistenzsystemen (FAS) handelt es sich um elektronische Zusatzeinrichtungen in Kraftfahrzeugen. Dabei wird der Fahrer bei seiner Fahraufgabe unterstützt und
gezielt entlastet. Eine wichtige Rolle spielt dabei in erster Linie der Sicherheitsaspekt
und die Steigerung des Fahrtkomforts. Mithilfe von Sensoren realisieren Fahrerassistenzsysteme die Wahrnehmung und Informationsgewinnung aus der Umgebung. Fahrerassistenzfunktionen lassen sich anhand des Grades der Automatisierung kategorisieren.[17]
So haben sich die ersten Fahrerassistenzsysteme darauf beschränkt, einzelne Größen zu
messen. Dabei beschreiben die Größen meist den Zustand des eigenen Fahrzeuges. Ein
Beispiel hierfür ist das Antiblockiersystem (ABS). Es dient dazu bei starkem Bremsen,
ein mögliches Blockieren durch Verminderung des Bremsdrucks entgegenzuwirken. Dazu
misst ein ABS sämtliche Raddrehzahlen des eigenen Fahrzeuges. Ein weiteres Beispiel
ist die Fahrdynamikregelung (engl. Electronic Stability Control - ESC). Dabei soll dem
Ausbrechen des Wagens entgegengewirkt werden, indem einzelne Räder gezielt abgebremst werden. Hier müssen die Gierrate, die Querbeschleunigung, die Geschwindigkeit
und der Lenkradwinkel gemessen werden. Bei diesen Systemen kann bereits eine hohe
Verlässlichkeit nachgewiesen werden. Daher unterstützen sie den Fahrer, ohne dass ihm
die Möglichkeit zu einem überschreibenen Eingriff gewährt wird.
Bei der nächsten Generation der Fahrerassistenzsysteme wird nicht nur der Zustand des
eigenen Fahrzeuges gemessen, sondern es wird auch die Fahrumgebung wahrgenommen.
Dazu gehört z.B. die Erfassung der Fahrbahngeometrie oder die Lokalisierung anderer
Fahrzeuge. Dies wird als maschinelle Wahrnehmung bezeichnet. Nach [17] werden die
folgenden Klassen von Fahrerassistenzsystemen nach ihren jeweiligen Funktionen unterschieden:
• Fahrerinformationssysteme
• Komfortsysteme
• Effizienzsteigernde Systeme
• Autonome Systeme
Bei Fahrerinformationssystemen wird anders als bei den autonomen oder Komfortsystemen das Fahrverhalten nicht direkt beeinflusst. Stattdessen werden dem Fahrer
Informationen zur Verfügung gestellt, die bei seiner Fahraufgabe nützlich sein könnten.
Dazu gehören z.B. Navigationssysteme oder die Erkennung von Verkehrszeichen. Auch
3
1.3. FAHRERASSISTENZSYSTEME UND IHRE KATEGORISIERUNG
Warnfunktionen werden durch solche Systeme realisiert wie zum Beispiel beim Verlassen
der Spur.
Komfortsysteme entlasten die Fahrer durch Manipulationen an Stellgrößen und übernehmen so einen Teil der Fahraufgabe. Jedoch ist eine Mitwirkung des Fahrers erforderlich wie z.B. die kontinuierliche Überwachung. Die Verantwortung bleibt bei solchen Systemen also beim Fahrer und er hat stets die Möglichkeit, selbst in das System einzugreifen
und es so zu übersteuern. Ein Beispiel hierfür ist der Abstandsregeltempomat bzw. die
Adaptive Geschwindigkeitsregelung (engl. Adaptive Cruise Control - ACC). Bei diesem
System wird die Position und die Geschwindigkeit des vorausfahrenden Fahrzeugs z.B.
mit Radarsensoren gemessen. Mit diesen Informationen wird eine Längsregelung durch
Motor- und Bremseingriffe realisiert und so der Abstand zum vorausfahrenden Fahrzeug geregelt. Dadurch kann der Fahrer auf langen Autobahnfahrten entlastet werden,
allerdings muss er jederzeit für entsprechende Eingriffe bereit sein.
Mit effizienzsteigernden Systemen wird versucht, den Verbrauch sowie die Emissionen zu verringern. Dies kann durch vorausschauende Berücksichtigung des horizontalen
und vertikalen Straßenverlaufs sowie durch Beobachtung des Verhaltens anderer Verkehrsteilnehmer umgesetzt werden. Dies ist besonders für den Güterverkehr interessant.
Autonome Systeme übernehmen aktiv Teilfunktionen bei der Fahrzeugführung. Die
jeweiligen Stellgrößen werden ohne Eingreifen des Fahrers manipuliert. Die Längs- bzw.
Querführung des Fahrzeuges wird dabei meist direkt übernommen. Weitere fahrdynamische Größen wie zum Beispiel die Verteilung der Radlasten können ebenfalls autonom
beeinflusst werden. Das im Rahmen dieser Arbeit entwickelte Zonenverhalten stellt ein
Beispiel für ein autonomes System dar. Mit diesem System können z.B. Zonen vollständig
autonom befahren werden.
Aufgrund der Unterstützung in der Fahrzeugführung haben FAS direkte Auswirkungen auf die Fahrsicherheit. Welches Potenzial FAS für die Fahrzeugsicherheit haben
wird durch eine Studie zu Schwerstunfällen für die USA aus dem Jahr 2000 erkennbar:
In gut 41% der Unfälle tritt zunächst eine Kollision mit einem anderen motorisierten
”
Verkehrsteilnehmer auf. In weiteren gut 30% der Unfälle ist eine Kollision mit einem
unbeweglichen Hindernis das erste Schadensereignis. Schließlich treten in über 16% der
tödlichen Unfälle zuerst Kollisionen mit beweglichen Objekten auf. [...] Insgesamt wäre
ein autonom handelndes, kollisionsvermeidenes oder - mildernes Fahrerassistenzsystem
für fast 90% der betrachteten Unfälle relevant.“ [17]
Obwohl durch Fahrerassistenzsysteme die Fahrzeuge sehr viel sicherer werden, sind noch
viele juristische Fragen offen. Wer für die Haftung im Falle eines Schadens zuständig
ist, kann nicht eindeutig beantwortet werden. Besonders bei autonomen Systemen ist
diese Frage sehr kritisch. Dennoch erhalten solche Technologien zunehmende Akzeptanz.
Daher gewinnen auch autonome Systeme immer mehr an Bedeutung. Die Stärken der
bisherigen FAS liegen besonders bei einfachen, aber zeitkritischen Aufgaben.
4
1.4. KOMPONENTEN AUTONOMER MOBILER ROBOTER
1.4 Komponenten autonomer mobiler Roboter
Autonome Roboter bestehen aus einem Sortiment von Sensoren, Aktoren, Bordcomputern und Kommunikationsgeräten. Zwischen diesen Komponenten herrscht ein Datenfluss, der maßgeblich für das Design der Softwarearchitektur ist. Sensoren dienen
zur Erfassung von Messwerten und der Kontrolle von Veränderungen in der Umwelt.
Bei Robotern werden üblicherweise nicht-elektrische Messgrößen in elektrische Signale
umgewandelt. Mit Hilfe von Gerätetreibern kann die Anwendung transparent mit der
Hardware kommunizieren. Auf einem Bordcomputer läuft eine Steuerungssoftware, die
das Verhalten des Roboters plant und regelt. Die Signale der Sensoren werden hier aufbereitet und verarbeitet und ggf. an die Planungskomponenten für längerfristige Ziele
weitergereicht. Indem ein Regler die Aktoren ansteuert, setzt er mit den Informationen
aus der Planung und den Sensoren die entsprechenden Bewegungen um. Über Kommunikationsschnittstellen wie z.B. WLAN oder Bluetooth können Daten ausgetauscht werden. Beispielsweise ist dies eine Möglichkeit, das Verhalten des Roboters zu überwachen
oder Missionsbefehle an ihm zu senden.
Sensoren in autonomen Fahrzeugen
Die Abbildung 1.1 zeigt die verschiedenen Sensoren des Testfahrzeuges MiG der Freien
Universität Berlin. Im Folgenden werden einige wichtige Sensoren für autonome Fahrzeuge vorgestellt.
Abbildung 1.1: Übersicht der Hardware vom Testfahrzeug MiG
5
1.4. KOMPONENTEN AUTONOMER MOBILER ROBOTER
Die Trägheitsplattform (engl.: Inertial Measurement Unit, abgekürzt IMU) dient zur
Messung von Beschleunigungen in X, Y und Z-Richtung sowie von Drehgeschwindigkeiten um die X, Y und Z-Achse. Diese Daten werden für die Navigation genutzt und sind
somit elementar für die Steuerung von autonomen Fahrzeugen. Der zurückgelegte Weg
kann mit diesen Daten ermittelt werden und so wird dementsprechend die neue Position
bestimmt.
Das Global Positioning System (GPS) ist ein satellitengestütztes Navigationssystem. Die
GPS-Satelliten senden Signale zur weltweiten Positionsbestimmung und Zeitmessung.
Die Genauigkeit befindet sich dabei in einer Größenordnung von unter zehn Metern.
Mit Hilfe von Differenzmethoden in der Umgebung eines Referenzempfängers lässt sich
die Genauigkeit auf einige wenige Zentimeter steigern. Eine Alternative zu GPS ist das
europäische Satellitennavigationssystem Galileo für zivile Zwecke, dessen Fertigstellung
voraussichtlich im Jahr 2013 erfolgt.
Light Detection and Ranging (Lidar) ist eine Methode zur optischen Abstands- und Geschwindigkeitsmessung. Dabei werden Laserstrahlen eingesetzt. Dazu werden Laserimpulse ausgesendet und anschließend wird das an Objekten reflektierte Licht detektiert.
Anhand der Laufzeit der Signale kann so die Entfernung zu dem Objekt bestimmt werden. Beim Radar (engl.: Radiowave Detection and Ranging) handelt es sich um eine
ähnliche Methode. Statt der Laserstrahlen werden Funkwellen ausgesendet und die von
Objekten reflektierten Echos empfangen.
Auch konventionelle Kameras werden für maschinelles Sehen verwendet. Dabei können
eine Vielzahl von Aufgaben gelöst werden. Mit Hilfe von Methoden zur Objekterkennung
können beispielsweise Verkehrsschilder, die Fahrspur oder Hindernisse erkannt werden.
Weiterhin kann durch eine Sequenz von Bildern der optische Fluss bestimmt werden, um
die Bewegungsrichtung und -geschwindigkeit von Objekten zu analysieren. Dies kann
dazu dienen, Hindernisse auszuweichen oder Abstände abzuschätzen.
Die Odometrie ist die Wissenschaft von der Positionsbestimmung eines mobilen Systems z.B. durch Beobachtung der Räder. Ein Gerät, das mit Hilfe der Odometrie den
zurückgelegten Weg eines Fahrzeuges misst, wird Odometer genannt. So kann durch die
Anzahl der Radumdrehungen die neue Position bestimmt werden. Allerdings führen viele
Faktoren wie Verschleiß und Ungenauigkeiten bei der Radgeometrie, unebene Bodenbeschaffenheiten, Spiel bei der Lenkung und ungleiche Gewichtsverteilung im Fahrzeug
schnell zu Ungenauigkeiten bei der Messung. Aufgrund solcher Fehlereigenschaften wird
dieses Verfahren meist ergänzend zu weiteren Verfahren eingesetzt.
Aktoren und Bussysteme
Aktoren sind die ausführenden Elemente und bezeichnen demnach Wandler zur Umsetzung von elektronische Signale in mechanische Bewegungen oder anderen physikalischen
Größen. Dadurch wird regulierend in das System eingegriffen bzw. die Sollgrößen vorgegeben. Bei den elektronischen Signalen kann es sich um Befehle von einem Steuerungs-
6
1.5. EIGENSCHAFTEN VON ECHTZEITSYSTEMEN
computer handeln. Beispiele für Aktoren sind Elektromotoren, Ventile, Pumpen oder
Schalter.
Die Kommunikation zwischen einem Steuergerät, den Sensoren und den Aktoren wird
durch einen Feldbus realisiert. Durch Protokolle wird festgelegt, wie mehrere Kommunikationsteilnehmer über dieselbe Leitung ihre Nachrichten austauschen. Der CAN-Bus
(Controller Area Network ) gehört zu den Feldbussen und hat sich besonders in den
sicherheitsrelvanten Bereichen wie die Automobiltechnik durchgesetzt. Durch den Einsatz solcher Feldbusse konnten die Kabelbäume in Fahrzeugen erheblich reduziert und
dadurch gleichzeitig Gewicht eingespart werden. Zuvor wurden bei der parallelen Verdrahtung vom Steuergerät jeweils eine Leitung zu jedem Sensor und Aktor gezogen.
Mittels Feldbusse wird die serielle Verdrahtung realisiert, bei der nur noch eine Leitung
vom Steuergerät an alle Sensoren und Aktoren vorbeiführt.
1.5 Eigenschaften von Echtzeitsystemen
Echtzeitsysteme bezeichnen Computersysteme, die ein Ergebnis innerhalb eines vorher
fest definierten Zeitintervalls garantieren. Nach DIN 44300 wird der Echtzeitbetrieb eines
Rechensystems wie folgt definiert: Ein Betrieb eines Rechensystems, bei dem Program”
me zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten
können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen. [10]“
Echtzeitsysteme zeichnen sich durch eine Reihe von Eigenschaften wie Rechtzeitigkeit,
Gleichzeitigkeit, Verfügbarkeit, Determiniertheit und Vorhersagbarkeit aus. Die Eigenschaften werden im Folgenden kurz vorgestellt.
Rechtzeitigkeit
Die Aufgaben müssen innerhalb einer vorgegebenen Zeit erledigt werden. Hierbei werden
die folgenden drei Echtzeitanforderungen unterschieden [11]:
Harte Echtzeitanforderungen
“Hier müssen Zeitbedingungen auf jeden Fall eingehalten werden, anderen Falls droht
Schaden.”
Feste Echtzeitanforderungen
“Bei festen Echtzeitbedingungen wird die durchgeführte Aktion nach Überschreiten der
Zeitbedingung wertlos und kann abgebrochen werden. Es droht jedoch kein unmittelbarer
Schaden.”
7
1.5. EIGENSCHAFTEN VON ECHTZEITSYSTEMEN
Weiche Echtzeitanforderungen
“Hier sind die Zeitbedingungen als Richtlinien anzusehen, die durchaus in gewissem
Rahmen überschritten werden dürfen.”
Gleichzeitigkeit
“Realzeitsysteme müssen gleichzeitig mehrere parallel ablaufende Vorgänge im technischen Prozeß automatisieren. Die Automatisierungsaufgaben müssen in dem Rechensystem so gelöst und die Ausführung der Automatisierungsprogramme so organisiert werden, daß sie einem außenstehenden Beobachter als gleichzeitig ablaufend erscheinen.
[12]” Auf Ein-Prozessormaschinen erfolgt die Verarbeitung quasiparallel. Die Aufgaben
werden jeweils nur für kurze Zeiträume von der CPU bearbeitet, so dass die Abarbeitung parallel erscheint. Hierfür wird vorausgesetzt, dass die Bearbeitung der Aufgaben
unterbrochen werden kann.
Verfügbarkeit
“Echtzeitsysteme müssen unterbrechungsfrei betriebsbereit sein, da es sonst zu Verletzung von Zeitbedingungen kommen kann. (...) Pausen in der Verfügbarkeit sind nicht
zulässig, da in diesen Pausen nicht auf Ereignisse reagiert werden kann. [11]” Ereignisse sind Aufgaben, die zu unregelmäßigen Zeitpunkten eintreffen. Diese müssen entsprechend abgearbeitet werden, ohne dass die anderen Aufgaben in ihrer Rechtzeitigkeit
beeinträchtigt werden. Selbst im Fehlerfall muss das System innerhalb kürzester Zeit
wieder reagieren, ohne dass die Funktionalität beeinträchtigt wird bzw. Schaden eintreten kann. Sollte ein Fehler auftreten, so muss sichergestellt werden, dass dieser auch
erkannt wird. Wenn zum Beispiel an einer seriellen Schnittstelle Daten verloren gehen,
sollte dies protokolliert oder angezeigt werden. Eine Möglichkeit zur Fehlerbehandlung
ist z.B. die Verwendung von Watchdogs.
Determiniertheit und Vorhersagbarkeit
“Technische Ausfälle, (...), lassen sich nicht durch eine Erweiterung der Zeitbedingung
erfassen. Sie wirken sich unmittelbar auf die Zuverlässigkeit des Echtzeitsystems aus.
Ziel muss sein, Ausfälle so weit wie möglich auszuschließen. [10]” Die Funktionalität
des Systems muss nachgewiesen werden können. Dies kann zum Beispiel durch ein Berechnungsmodell erfolgen. Alternativ kann auch ein experimenteller Nachweis erfolgen.
8
2
Pfadplanungskonzept
In diesem Kapitel werden die Grundlagen und notwendigen Überlegungen für den Entwurf eines Konzeptes zur Pfadplanung diskutiert. Zunächst werden einige ausgewählte
verwandte Arbeiten vorgestellt (2.1). Im folgenden Abschnitt werden die Grundlagen
der Navigation und deren Kernkompetenzen beschrieben sowie Punkte zu den Anforderungen an den Pfad zusammengestellt (2.2). Unter 2.3 werden Steuerungsarchitekturen
von autonomen mobilen Robotern und unter 2.4 Annahmen zum Fahrzeugmodell betrachtet. Innerhalb des Projektes wird das Orocos Real-Time Toolkit für die Erstellung
und Konfiguration der einzelnen Module verwendet, auf dem auch das entwickelte Zonenverhalten basiert und dessen Konzepte unter 2.5 kurz erläutert werden. Durch das
vorhandene System sind die Schnittstellen für ein neues Verhaltensmodul bereits gegeben (2.6). Schließlich wird für die Pfadplanung auch ein Modell zu dem Straßennetz und
den Zonen benötigt, das in einem speziellen Format zur Verfügung gestellt wird (2.7).
2.1 Verwandte Arbeiten
Im Rahmen der DARPA Grand Challenges und der Urban Challenge 2007 wurden bereits
einige Konzepte für die Pfadplanung auf unkartiertem Gelände entwickelt. Einige dieser
Lösungen werden an dieser Stelle vorgestellt.
Die Pfadplanung des Gewinnerfahrzeuges Boss der DARPA Urban Challenge 2007 basiert auf den Anytime Dynamic A* -Algorithmus.[4] Dabei wird initial ein suboptimaler
Plan generiert, der anschließend innerhalb der verfügbaren Zeit schrittweise verbessert
wird. Der Algorithmus wird ausführlich im Abschnitt 5.1 beschrieben.
Das zweitplazierte Fahrzeug der Urban Challenge Junior benutzt den Hybrid A* -Algorithmus zur Pfadplanung.[5] Bei der herkömmlichen A*-Suche entsteht ein diskretisierter
9
2.1. VERWANDTE ARBEITEN
Abbildung 2.1: Vergleich verschiedener Algorithmen [5]
Plan, der nicht von einem Fahrzeug abgefahren werden kann. Daher wird zu jeder diskreten Zelle ein kontinuierlicher Zustand des Fahrzeuges zugeordnet. Wobei die Bewertung
der Zelle den Kosten des zugeordneten Zustands entspricht.
Die Abb. 2.1 stellt verschiedene Suchalgorithmen im Vergleich dar. Der A*-Algorithmus
referenziert die Kosten mit dem Zentrum jeder Zelle und verwendet nur Zustände bei
der Suche, die dem Zellenmittelpunkt entsprechen. Dadurch entstehen sehr zackige Pfade, welche bestenfalls näherungsweise von einem Fahrzeug abgefahren werden können
(links). In der Mitte ist ein Beispiel für den Field D* -Algorithmus dargestellt.[6] Dabei
werden die Kosten mit Punkten an den Rändern der Zelle assoziiert und dadurch beliebige lineare Pfade von Zelle zu Zelle ermöglicht. Rechts ist die Funktionsweise des Hybrid
A* -Algorithmus skizziert. Nun können die Kosten zu einem kontinuierlichen Punkt innerhalb einer Zelle zugeordnet werden. Die Bewertung der Zelle entspricht dabei den
Kosten des zugeordneten kontinuierlichen Zustandes.
Ein weiterer Ansatz ist die Potentialfeldmethode. Dabei betrachtet man den Roboter
als einen Massepunkt, der unter dem Einfluss eines Potentialfeldes steht. Zwei Kräfte
beeinflussen den Weg des Roboters. Eine Kraft stösst ihn von Hindernissen ab und eine
weitere Kraft wirkt in Richtung des Zielpunktes anziehend. Die Pfadplanung versucht
nun den Abstand zu den Hindernissen zu maximieren und die Entfernung zum Ziel zu
minimieren. Den geplanten Weg kann man mit einer ins Tal rollenden Kugel vergleichen. Dabei entsteht das Problem der lokalen Minima. Befindet sich z.B. ein U-förmiges
Hindernis auf dem Weg zum Ziel, kann der Roboter darin steckenbleiben. Um aus dem
lokalen Minima wieder heraus zu gelangen, könnten Zufallsbewegungen genutzt werden.
Eine Problematik bei dieser Methode ist die Wahl der Kostenfunktion. Diese könnte sich
beispielsweise aus Faktoren wie der Glätte des Pfades, dem Abstand zu den Hindernissen,
der Krümmung und dem Einhalten der Spur zusammensetzen. Für ein bestimmtes Fahrverhalten müssen die einzelnen Faktoren unterschiedlich gewichtet in die Kostenfunktion
einfließen. Im Artikel unter [7] wird für die Navigation eines autonomen Fahrzeuges zu
einem Parkplatz die Potentialfeldmethode benutzt. Die Gewichtung der Faktoren wurde
dabei aus einem Satz von Beispielen für verschiedene Szenarien bestimmt. Für diese
Beispiele ist zunächst ein menschlicher Fahrer jeweils die Strecken zu einem Parkplatz
gefahren. Anhand von nur vier solcher Beispiele konnte die Gewichtung so angepasst wer-
10
2.2. GRUNDPRINZIPIEN DER NAVIGATION
den, dass das Auto auch in neuen Situationen einen Pfad mit dem angelernten Fahrstil,
ähnlich wie der des menschlichen Fahrers, findet. Mit dieser Methode kann dem Auto
schnell ein entsprechender Fahrstil beigebracht werden. Ein guter Fahrstil zeichnet sich
zum Beispiel dadurch aus, dass die meiste Zeit vorwärts gefahren wird und die Spuren
des Parkplatzes eingehalten werden. Bei einem unsauberen Fahrstil werden auch längere
Strecken rückwärts gefahren und außerdem die vorgesehenen Fahrstreifen größtenteils
ignoriert.
2.2 Grundprinzipien der Navigation
Die Navigation bezeichnet die Steuermannskunst zu Wasser, zu Land und in der Luft.
Dabei ist das Ziel, das entsprechende Fortbewegungsmittel sicher an eine gewünschte
Zielposition zu steuern. Dazu muss zunächst die momentane Position bestimmt und anschließend eine Route zum Zielpunkt ermittelt werden. Im Altertum war die Ortung
und die auf ihr beruhende Navigation elementar für die Seefahrt.[19] In früheren Zeiten
wurden fast ausschließlich optische Methoden benutzt, indem die Gestirne als Bezugspunkte benutzt wurden. Die optische Sicht als Voraussetzung ist allerdings nicht immer
gegeben, wenn z.B. Wolken oder Nebel die Sicht behindern. Im 20. Jahrhundert kamen funktechnische Einrichtungen für die Ortung und Navigation hinzu. Da nun keine
optische Sicht mehr benötigt wurde, waren diese Methoden wesentlich einfacher und
schneller zu handhaben. Mit dem Beginn der Luftfahrt steigerten sich noch einmal die
Anforderungen, da nun Navigationssysteme mit hoher Genauigkeit und großer Reichweite benötigt wurden. Schließlich wurden satellitengestützte Ortungssysteme entwickelt.
So waren diese Systeme nicht mehr auf funktechnischen Bodenstationen angewiesen.
Zunächst wurden die Satelliten für militärische Zwecke entwickelt, wurden dann aber
für den zivilen Bereich freigegeben. Dies hat zum Vorteil, dass die Satelliten weltweit
genutzt werden können und eine hohe Genauigkeit ermöglichen. Eine Alternative dazu
stellt das Trägheitsnavigationssystem dar. Dabei wird die Position und Geschwindigkeit
ohne Bezug zur äußeren Umgebung bestimmt. Bei der integrierten Navigation werden
die verschiedenen Navigationsverfahren kombiniert, um so ein optimales Ergebnis für
die Ortsbestimmung zu erreichen.
Aufgaben bei der Navigation
Die Navigation ist eine der wichtigsten Fähigkeiten eines mobilen Roboters. Erst dadurch kann der Roboter Aufgaben ausführen, die sich auf einen bestimmten Ort in der
Umgebung beziehen. Nach [15] wird die Navigation aus den folgenden drei Kompetenzen
kombiniert:
11
2.2. GRUNDPRINZIPIEN DER NAVIGATION
• Selbstlokalisierung
• Routenplanung
• Kartenerstellung und Karteninterpretation (Kartenanwendung)
Die Selbstlokalisierung ist die Bestimmung der eigenen Position innerhalb eines Bezugsystems. Nur auf der Grundlage der Lokalisierung kann der Roboter den Weg zu
seiner angestrebten Zielposition finden. Bei der lokalen Lokalisierung ist die aktuelle Pose des Roboters innerhalb der Umgebung bekannt und bei einer Bewegung muss die Pose
kontinuierlich aktualisiert werden. Anhand von ständigen Messungen wird die neue Pose
validiert. Zum Beispiel mit Odometrie-Sensorik wird die Bewegung zunächst geschätzt
und mit der Lokalisierung die Position anschließend korrigiert. Dadurch wird verhindert,
dass sich die Fehler der Odometrie aufsummieren. Bei der globalen Lokalisierung muss
der Roboter mithilfe von signifikanten Merkmalen der Umgebung seine Position bestimmen. Die aktuelle Pose in der Umwelt ist zunächst nicht bekannt. Wurde die Position
gefunden kann mit der lokalen Lokalisierung fortgesetzt werden.
Die Routenplanung stellt eine Erweiterung zur Lokalisierung dar. Der Roboter muss
seine gegenwärtige Position und die angestrebte Position innerhalb desselben Bezugsystems bestimmen. Viele Algorithmen der Routenplanung basieren auf die Graphentheorie. Ein Graph G = (V,E) ist durch die Knotenmenge V und der Kantenmenge E
definiert.[14] Knoten und Kanten sind die Elemente der entsprechenden Mengen, wobei eine Kante die Verbindungen zwischen zwei Knoten darstellt. In gerichteten bzw.
orientierten Graphen besitzen die Kanten außerdem eine Richtung. Das bedeutet, dass
die Kante zwischen zwei Knoten nur in einer Richtung durchlaufen werden kann. Ein
Beispiel für einen Graphen ist ein U-Bahn Netz. Dabei stellt jede U-Bahn Station einen
Knoten und die Zugverbindungen zwischen zwei Stationen die Kanten dar. Um auch in
großen Graphen hinreichend schnell eine Verbindung zu finden, werden häufig Heuristiken eingesetzt. Dabei werden zuerst die nach aktuellem Wissensstand vielversprechendsten Knoten bei der Suche als erstes betrachtet.
Eine Karte ist eine Abbildung von Objekten aus der realen Welt in eine interne Repräsentation. Bei der Kartenerstellung werden Informationen über die erkundete Umgebung aufbereitet. Anschließend müssen die Karten bei der Navigation interpretiert
werden.
Anforderungen an den Pfad
Beim Fahren auf Straßen gibt die gewünschte Spur gleichzeitig auch den bevorzugten
Pfad für das Auto vor. Da es beim Fahren im Gelände keine Spuren gibt, sind die
Bewegungen des Fahrzeuges weniger eingeschränkt. Dennoch lässt sich mit den folgenden
Eigenschaften die Qualität eines gefundenen Pfades im Gelände bewerten:
12
2.3. STEUERUNGSARCHITEKTUREN AUTONOMER ROBOTER
• Gesamtlänges des Pfades
• Länge der Rückwärtsabschnitte
• Anzahl der Richtungswechsel
• Abstand zu Hindernissen
• Krümmung des Pfades
Bei der Pfadplanung wird in erster Linie versucht den kürzesten Weg zwischen zwei
Punkten zu finden. Allerdings muss der kürzeste Weg nicht immer der beste sein. So
zeichnet sich ein guter Fahrstil darin aus, dass keine längeren Rückwärtsabschnitte gefahren werden. Statt dessen ist es besser, wenn erst in der Nähe des Ziels rückwärts beim
Rangieren gefahren wird. Generell sollte auch eine große Anzahl von Richtungswechsel
vermieden werden. Dies kann man z.B. dadurch erreichen, indem die minimale Länge
eines Abschnittes begrenzt wird, der mindestens mit der gleichen Richtung gefahren
werden muss. Bei Beginn eines Einparkmanövers könnte diese Länge reduziert werden,
um besser rangieren zu können. So wäre es möglich auch engere Parklücke zu befahren.
Aus Sicherheitsgründen sollte stets versucht werden, den Abstand zu Hindernissen so
groß wie möglich zu halten. Bei kleineren Geschwindigkeiten oder beim Einparken kann
der Sicherheitsabstand ggf. verringert werden. Ein weiteres Kriterium ist die Krümmung
des Pfades. Für den Menschen ist es angenehmer und für das Auto schonender, wenn
beim Fahren die Kurven möglichst weich genommen werden.
2.3 Steuerungsarchitekturen autonomer Roboter
Im Folgenden werden kurz die wichtigsten Ansätze zur Realisierung der Autonomie in
mobilen Robotern beschrieben.[16]
Das einfachste Softwaredesign für autonome Roboter ist die reaktive Architektur. Dabei
wird das Verhalten des Roboters von einer Sammlung Stimulus-Response Regeln bestimmt. Die Sensoren liefern die Eingabedaten für jede dieser Regeln. Das resultierende
Verhalten ergibt sich aus der Kombination der Ausgaben dieser Regeln. Besonders vorteilhaft ist die Performance dieser Architektur. Da es keine Planungskomponente gibt
und demnach auch kein Weltmodell, kann der Roboter sofort auf Ereignisse reagieren.
Jedoch wird für ein optimales Verhalten meist eine längerfristige Strategie benötigt.
Den genau umgekehrten Ansatz geht die deliberative Architektur nach. Deliberativ bedeutet, dass alle Aktionen vorausschauend geplant werden. Dazu wird zunächst ein abstraktes internes Weltmodell aufgebaut. Dieses kann natürlich nie exakt der Realität
entsprechen und ist daher fehlerbehaftet. Zu Lasten der Reaktionsfähigkeit können nun
komplexe Missionen autonom durchgeführt werden (z.B. Fahren zu einem bestimmten
Ziel mit Hindernissen auf dem Weg). Eine weitere Konsequenz ist, dass alle Aktionen
seriell nacheinander ausgeführt werden. Um die Vorteile beider Ansätze zu kombinieren
13
2.4. ANNAHMEN ZUM FAHRZEUGMODELL
und die Nachteile auszugleichen, werden in der Praxis meist hybride Architekturen verwendet.
2.4 Annahmen zum Fahrzeugmodell
Bei der Physik von der Bewegung der Fahrzeuge wirken sehr viele verschiedene Faktoren
aufeinander ein. Um Teilaspekte davon möglichst realitätsnah und dennoch einfach zu
beschreiben, werden entsprechende Modelle verwendet. Durch einige Annahmen lässt
sich die Planung der Fahrzeugbewegung stark vereinfachen. Der Untergrund kann z.B.
die Bewegung des Fahrzeuges erheblich verändern, wenn er aufgrund von Vereisung
oder nassem Laub sehr glatt ist. Die Bremswege verlängern sich nun deutlich und auch
das Lenkverhalten kann sich durch die verringerte Bodenhaftung verändern. So wird
in dieser Arbeit von einem festen und haftenden Untergrund ausgegangen. Auch hohe Geschwindigkeiten werden beim Rangieren auf einem Parkplatz vermieden. Dadurch
können einige Auswirkungen wie zum Beispiel die Vergrößerung des Wendekreises vernachlässigt werden. Im Folgenden werden die Annahmen zum minimalen Wendekreis
und zur nicht-holonomen Natur des Autos kurz vorgestellt.
Minimaler Wendekreis
Ein einfaches und praktisches Modell zur Beschreibung des Lenkverhaltens stellt das
Einspurmodell dar.[9] Dabei ergibt sich der Lenkwinkel aus dem kinematischen- und
dem Eigenlenkwinkel. Bei einer geringen Querbeschleunigung ist der Eigenlenkwinkel
vernachlässigbar und es wirkt nur noch der kinematische Winkel. Dies ist bei einem
großen Radius und einer geringen Geschwindigkeit der Fall. Der kinematische Winkel δk
kann aus dem Radabstand l und dem Kurvenradius R wie folgt errechnet werden:
δk =
l
R
(2.1)
Nicht-holonome Natur des Autos
Für die Planung wird in dieser Arbeit von einer zweidimensionalen Landschaft ausgegangen. Der aktuelle Zustand des Fahrzeugs lässt sich mit der XY-Position und der absoluten
Orientierung beschreiben. Eine holonome Bewegung kennzeichnet sich dadurch, dass die
Position und die Orientierung voneinander unabhängig veränderbar sind. Gewöhnliche
Autos können sich aber aufgrund der Eigenschaften des Fahrwerks nicht holonom bewegen. Um die Orientierung zu ändern, muss sich das Auto gleichzeitig fortbewegen.
14
2.5. OROCOS REAL-TIME TOOLKIT
Ein weiterer Faktor dabei ist die Geschwindigkeit. Je höher die Geschwindigkeit, desto
größer werden auch die nicht-holonomen Einschränkungen. Das bedeutet beispielsweise,
dass der minimale abfahrbare Kurvenradius mit zunehmender Geschwindigkeit größer
wird.
2.5 Orocos Real-Time Toolkit
Das Open Robot Control Software (Orocos) Projekt ist eine Sammlung von insgesamt
vier Bibliotheken für die Entwicklung von Software für Roboter und anderen Maschinen.
Das Orocos Real-Time Toolki t (RTT) ist ein C++ Framework für die Implementierung
von echtzeitfähigen Steuerungssystemen. Dabei handelt es sich um freie Software. Die
mit diesem Framework erstellten Steuerungssysteme sind modulbasierend und demnach
hochgradig konfigurierbar. Um ein Orocos-Modul zu erstellen, muss eine Klasse konstruiert werden, die vom Orocos TaskContext abgeleitet wird. Über XML-Dateien können
die Module konfiguriert und miteinander verbunden werden (siehe 2.6). Dadurch ergibt
sich eine sehr hohe Flexibilität, welche für die Entwicklung von komplexen Systemen
wie z.B. autonome Fahrzeuge notwendig ist. So können z.B. relativ schnell unterschiedliche Sensoren verwendet werden. Aber auch in einer Simulationsumgebung können so
einzelne Module wie das Verhalten getestet werden, ohne ständig die reale Hardware
verwenden zu müssen.
Ein in der Ausführung befindliches bzw. zur Ausführung bereites Programm wird als Prozess bezeichnet. Multitasking-Betriebssysteme erlauben die Ausführung mehrerer Prozesse auf einem Prozessor (CPU). Der Prozessor bearbeitet jedes Programm nur für eine
sehr kurze Zeit und wechselt dann zum nächsten rechenbereiten Prozess. Dadurch entsteht der Eindruck (bei Verwendung von nur einer CPU), dass die Programme parallel
ausgeführt werden. Durch die parallele Programmierung kann die CPU effizienter ausgenutzt werden. Ein Prozess wird dabei in mehreren Threads untergliedert. Demnach
benötigen Threads weniger Kontextinformationen und ein Kontextwechsel kann schneller ausgeführt werden. Daher handelt es sich bei Threads um leichtgewichtige Prozesse. Jedes Orocos-Modul wird als ein Thread nebenläufig ausgeführt. Zur Initialisierung
wird die Methode startHook() ausgeführt. Danach wird die Methode updateHook() von
der Orocos Execution Engine periodisch zu einer konfigurierbaren Frequenz aufgerufen.
In dieser Methode werden die Eingabedaten eingelesen, die eigentliche Programmlogik ausgeführt und schließlich die Ausgabedaten an andere Module weitergereicht. Die
Aufräumarbeiten finden ggf. in der Methode stopHook() statt.
Die Orocos Component Library (OCL) liefert eine Sammlung von Komponenten wie den
TaskBrowser und die DeploymentComponent. Der TaskBrowser stellt eine Konsole zur
Verfügung, die es ermöglicht, die einzelnen Module zur Laufzeit zu untersuchen oder
zu manipulieren. Dazu gehört das Setzen von Attributen oder die Ausführung von Methoden. Damit die Methoden oder Attribute über den TaskBrowser sichtbar werden,
müssen sie über das Method Interface bzw. über dem Attributes oder dem Properties
15
2.6. SCHNITTSTELLEN ZUM ZONENVERHALTEN
Interface bekannt gemacht werden. (Weitere Informationen unter [25]). Attributes sind
Eigenschaften eines Moduls, die zur Laufzeit gesetzt werden können. Properties werden
zusätzlich persistiert, indem die Werte in eine XML-Datei gespeichert werden. Über eine XML-Konfigurationsdatei wird der DeploymentComponent mitgeteilt, welche Module
geladen und miteinander verbunden werden sollen. Es können auch Initialisierungen angestoßen werden. Dazu werden bestimmte Methoden der Module mit den entsprechenden
Parametern in der XML-Datei angegeben. Optional können die Module zusätzlich über
Peers miteinander verbunden werden. Peers ermöglichen im TaskBrowser die Navigation
zwischen den Modulen.
2.6 Schnittstellen zum Zonenverhalten
Das Zonenverhalten soll als Modul namens FreeFormNavigation in das vorhandene System integriert werden. Dazu erfolgt die Kommunikation zu den anderen Modulen über
sogenannte Ports. Demnach werden von Orocos über Ports die Schnittstellen zwischen
den Modulen realisiert. In der XML-Konfigurationsdatei können über Connections die
Ports zweier Module miteinander verbunden werden. Die Module sorgen dafür, dass die
Ports mit den entsprechenden Daten gefüllt werden. Abb. 2.2 zeigt die ein- und ausgehende Kommunikation zum FreeFormNavigation-Modul mit anderen Modulen und
den dazugehörigen Datenpaketen. Ein Modul namens EgoStateSnapshotGenerator liefert unter anderem die Informationen zu der aktuellen Position und Orientierung des
Fahrzeugs in absoluten Weltkoordinaten. Ein weiteres Modul stellt die Informationen zu
den Hindernissen zur Verfügung. In der Simulationsumgebung werden die Hindernisse
vom Simulator -Modul aus einer weiteren XML-Datei geladen. Beim realen Auto liefert
der Tracker auf Grundlage der verschiedenen Sensordaten die Hindernisobjekte. Das
MissionControl -Modul lädt die Checkpoints aus einer entsprechenden Datei. Weitere
Informationen vom Controller wie z.B. die gewünschte Geschwindigkeit könnten ebenfalls für das Zonenverhalten vom Interesse sein. Über Singleton-Klassen wird zusätzlich
auf die StateMachine oder dem RNDF-Graphen zugegriffen. Die StateMachine verwaltet
den momentanen Zustand des Autos wie z.B. den Fahrmodus, den permanenten Stop
oder das kontrollierte Abbremsen aufgrund eines Hindernisses. Der RNDF-Graph wird
unter anderem für die Informationen zur Zone oder für die Positionen der Checkpoints
benötigt (s. 2.7).
Mit diesen entsprechenden Eingabedaten wird vom Zonenverhalten ein Pfad generiert.
Dieser Pfad muss anschließend zu einem Plan konvertiert werden. Dabei handelt es sich
um ein Objekt, das vom Controller verarbeitet werden kann, um schließlich die Steuerbefehle an die Aktoren des Autos zu senden. Weiterhin werden verschiedene Objekte an
das DisplayFreeFormNavigation-Modul über die Ports weitergereicht, um den generierten Plan sowie weitere Informationen rundum die Pfadplanung zu visualisieren.
16
2.7. STRASSENNETZ UND ZONEN
Abbildung 2.2: Ein- und ausgehende Kommunikation zum FreeFormNavigation-Modul
2.7 Straßennetz und Zonen
Während der DARPA Urban Challenge mussten die Teams Missionen über ein definiertes Straßennetz absolvieren. Zur Definition des Straßennetzes wurden Route Network
Definition Files (RNDF) verwendet. Im RNDF sind Streckenabschnitte, Wegpunkte,
aber auch Zonen mit entsprechenden Parkplätzen definiert. In dem Mission Data File (MDF) sind unter anderem Sequenzen von abzufahrenden Punkten enthalten. Eine
Spezifikation zum RNDF und MDF findet man unter [8].
Ein Straßennetz wird im RNDF durch eine Vielzahl von zusammenhängenden Straßensegmenten gebildet. Jedes Segment kann wiederum aus einer oder mehreren Spuren
bestehen, deren Breite jeweils angegeben werden kann. Auf den Spuren befinden sich
Wegpunkte, die immer in der Mitte der Spur platziert werden. Allerdings bildet diese Sequenz von Wegpunkten nicht zwingend den optimalen Pfad, da sich z.B. möglicherweise
parkende Autos am Wegesrand befinden oder aber auch andere Hindernisse vorhanden
sein können. Wegpunkte können zusätzlich als Checkpoints markiert werden.
Neben den Straßensegmenten können RNDFs auch Zonen beschreiben. Dabei handelt es
sich um Gebiete, in denen sich die Fahrzeuge frei bewegen können. Verkehrsregeln werden
für das Vehalten in der Zone zwar nicht definiert, aber mögliche Kollisionen sollten
natürlich dennoch frühzeitig erkannt werden. Der Umriss der Zone wird durch beliebig
viele Punkte in fester Reihenfolge aufgespannt. Einige dieser Punkte können zusätzlich
17
2.7. STRASSENNETZ UND ZONEN
als Zufahrts- bzw. Ausgangspunkte markiert werden und dienen als Verbindung mit dem
Straßennetz. In einer Zone können sich statische sowie bewegte Hindernisse befinden und
es ist nicht garantiert, dass die Zone überall abfahrbar ist. In diesem Fall muss ggf. eine
Neuplanung stattfinden.
Abbildung 2.3: Mission in einer Zone[8]
Weiterhin können im RNDF-Format auch Parkplätze definiert werden. Dabei wird jeder
Parkplatz durch zwei Punkte beschrieben. Durch diese zwei Punkte ist die Richtung und
Länge des Parkplatzes vorgegeben, wobei sich die Punkte in der Mitte des Parkplatzes
befinden. Zusätzlich kann auch die Breite angegeben werden. Das vorgeschriebene Verhalten beim Befahren eines Parkplatzes besteht darin, dass zunächst über den ersten
Punkt gefahren wird bis schließlich der zweite Punkt mit der Vorderachse erreicht wird.
Anschließend fährt das Auto wieder rückwärts aus der Parklücke und zum nächsten
Checkpoint. Abb. 2.3 skizziert ein Szenario für das Befahren einer Zone mit einem entsprechenden Parkmanöver. Das Auto erreicht über das Straßensegment A den Eingang
der Zone, navigiert sich frei zum gewünschten Parkplatz und verlässt die Zone schließlich
wieder über das Straßensegment C, um zum nächsten Checkpoint der Mission zu fahren.
In dem MDF wird eine Sequenz von Checkpoints angegeben, die in fester Reihenfolge
vom Auto abgefahren werden sollen. Jedes MDF bezieht sich auf ein konkretes RNDF.
Aber es können durchaus mehrere MDFs für ein und denselben RNDF erstellt werden. Ein Checkpoint gilt als erreicht, wenn ihn das Auto mit der richtigen Richtung
18
2.7. STRASSENNETZ UND ZONEN
überfährt. Zudem können Checkpoints doppelt in einer Mission vorkommen bzw. müssen
nicht zwingend verwendet werden. Der letzte Checkpoint der Mission dient als Ziellinie,
hinter der das Auto zum Stillstand kommen muss. Außerdem kann im MDF für jedes
Straßensegment eine Mindest- und Maximalgeschwindigkeit in ganzzahligen Werten der
Einheit Meilen pro Stunde angegeben werden. Sind beide Werte identisch, so muss das
Fahrzeug eine bestimmte Geschwindigkeit beibehalten bzw. bei dem Wert null gelten
keine Geschwindigkeitsvorgaben.
19
3
Realisierung
Dieses Kapitel erläutert, wie die Konzepte aus dem vorherigen Kapitel im Projekt AutoNOMOS umgesetzt wurden. Das Zonenverhalten wurde als ein eigenes Modul realisiert
und könnte in bestimmten Situationen anstelle des Verhaltens im Straßenverkehr aktiviert werden. Es wird darauf eingegangen, wie der im Rahmen dieser Arbeit entwickelte
Code aufgebaut ist und welche Funktionalitäten realisiert worden sind. Ein besonderes Augenmerk wurde dabei der Performance und der effizienten Speicherverwendung
gewidmet.
Im Abschnitt 3.1 wird zunächst der Aufbau des FreeFormNavigation-Moduls umrissen.
Anschließend wird die Funktionsweise des Pfadplanungsalgorithmus detailliert erläutert
(3.2) und auf die einzelnen Details zur Pfadplanung eingegangen (3.3). Unter 3.4 werden
die Eigenschaften von Heuristiken erklärt und die nicht-holome Heuristik ohne Verwendung von Hindernissen sowie die holonome Heuristik mit Beachtung von Hindernissen veranschaulicht. Des Weiteren werden die Aspekte zum Richtungswechsel und
Rückwärtsfahren (3.5) sowie die Konvertierung des Pfades zum Plan betrachtet (3.6).
Zudem werden im Abschnitt 3.7 das Fahren von Missionen und die Besonderheiten
beim Einparkmanöver geschildert. Ebenfalls wird das Modul zur Visualisierung des Zonenverhaltens vorgestellt (3.8). Unter 3.9 ist eine Anleitung zur Verwendung des Moduls
angegeben. Abschließend werden unter 3.10 einige Maßnahmen für Performanceoptimierungen zusammengetragen.
3.1 Aufbau des FreeFormNavigation Moduls
Das Zonenverhalten wurde als ein Orocos-Modul implementiert und läuft in einem eigenen Thread. Das Modul wird von der Execution Engine zyklisch mit einer Frequenz von
zwanzig Hertz aufgerufen. Mit jedem Aufruf werden die Ein- und Ausgabedaten aktua-
20
3.1. AUFBAU DES FREEFORMNAVIGATION MODULS
Abbildung 3.1: Übersicht aller Pakete und Klassen
lisiert. Abbildung 3.1 zeigt eine Übersicht aller Pakete und deren Klassen des Moduls
für das Zonenverhalten namens FreeFormNavigation. Die gleichnamige Klasse bildet den
Einstiegspunkt des Moduls und ist gleichzeitig die Schnittstelle zu den anderen Modulen.
Die Klassen zu dem Datenmodell, mit dem während der Planung gearbeitet wird, befinden sich im Paket model. Die Klasse StateNode beschreibt einen Knoten auf einem zweidimensionalen Grid. Beim Grid handelt es sich veranschaulicht um ein Gitter, das über
ein Gebiet gelegt wird und so den kontinuierlichen Planungsraum diskretisiert. DirStateNode erweitert die Knoten um die Angabe der Richtung und den damit verbundenen
zusätzlichen Attributen wie z.B. für das Rückwärtsfahren. Die Klasse PlanningArea verwaltet alle globalen Informationen zur Zone (Details siehe 3.3). Knoten in der gleichen
XY-Position auf dem Grid, aber mit unterschiedlichen Orientierungen gehören zu einer
Zelle. Die gemeinsamen Eigenschaften aller Punkte in einer Zelle werden in der Klasse LocationInfo gespeichert. Die Klasse LocationInfoGrid verwaltet dabei alle Objekte
der Klasse LocationInfo. Über die Klasse CarData werden die Daten zum Fahrzeug wie
zum Beispiel der Radius des minimalen Wendekreises oder die Position der Vorderachse
zur Verfügung gestellt. Der ObstacleChecker dient dazu Positionen oder Strecken auf
Hindernisse zu überprüfen (siehe 3.3).
Im Paket pathgenerator findet die eigentliche Pfadplanung statt. Die Template-Klasse
AbstractGrid ist eine Datenstruktur zur Speicherung der expandierten Knoten. Die Klasse kann sowohl Knoten mit als auch ohne Richtung bei entsprechender Parametrisierung
21
3.1. AUFBAU DES FREEFORMNAVIGATION MODULS
verwalten. Der AbstractPathGenerator enthält allgemeine Datenstrukturen und Methoden für den A*-Algorithmus. Sowohl der eigentliche Pfadplaner (AStarPathGenerator )
als auch die holonome Heuristik mit Beachtung von Hindernissen (UseObstaclesIgnoreNonHolonomic) erben von dieser Klasse. Hierzu gehören z.B. die Klasse OpenList,
eine Prioritätswarteschlange oder die Klasse PriorityQueueElement. Die Klasse OpenList speichert, ob ein Knoten noch untersucht werden muss, dieser bereits betrachtet
wurde oder aber noch gar nicht während der Suche erreicht wurde. Die Klasse PriorityQueueElement wurde aus Performancegründen eingeführt (siehe 3.10). Objekte vom
Typ PriorityQueueElement werden anstatt Objekte der Klasse StateNode in der Prioritätswarteschlange als Elemente verwendet. Ein PriorityQueueElement speichert lediglich die Id zu einem Knoten und überlädt den < Operator, so dass die Elemente nach
den günstigsten Gesamtkosten sortiert werden. Schließlich wird mit dem AStarPathGenerator der erweiterte A*-Algorithmus implementiert. Hier wird ein Start- und ein
Zielknoten mit einer bestimmten Orientierung übergeben und ein Pfad in Form von
zusammenhängenden Knoten zwischen diesen beiden Knoten generiert, sofern dieser
existiert (ausführliche Beschreibung unter 3.2).
Zum Paket plangenerator gehören die Klassen PlanGenerator, PathToPlanConverter
und PlanOptimizer (siehe 3.6). In der Klasse PlanGenerator werden aus den manuellen
Eingaben oder den Checkpoints des MDF zunächst zur aktuellen Position des Fahrzeuges
sowie zur gewünschten Zielposition die Start- und Zielknoten generiert. Dann wird die
Planung des Pfades aufgerufen. Der generierte Pfad wird anschließend mithilfe der Klasse
PathToPlanConverter in ein für den Controller abfahrbaren Plan konvertiert. Zusätzlich
können mit dem PlanOptimizer weitere Optimierungen am Pfad vorgenommen werden.
In dem Paket heuristic befinden sich die verschiedenen Heuristiken für die A*-Suche, auf
die über die Klasse Heuristic zugegriffen werden können (3.4). Eine einfache Heuristik
ist dabei der euklidische Abstand zwischen zwei Punkten. Eine weitere Heuristik wird
mit der Klasse UseObstacleIgnoreNonHolonomic implementiert (3.4.2). Dabei handelt
es sich um eine zweidimensionale A*-Suche ohne Beachtung der Orientierungen und
der nicht-holonomen Randbedingungen des Fahrzeuges, aber mit Verwendung von Hindernissen. Die Klasse NonHolonomicWithoutObstacles ist eine Heuristik, die die nichtholonomen Randbedingen und Orientierungen beachtet, aber die Hindernisse außer Acht
lässt (3.4.1).
Das Paket mission wird beim Abfahren von Missionen verwendet (s. 3.7). ParkingArea
kapselt dabei die Informationen zum Parkplatz. Der MissionHandler liest die Daten
aus dem MDF aus und behandelt den aktuellen Status der Mission wie z.B. Setzen
des nächsten Checkpoints beim Erreichen des aktuellen Ziels oder Überspringen eines
Checkpoints, wenn er aufgrund von Hindernissen nicht erreichbar ist.
Das Visualisierungsmodul DisplayFreeFormNavigation befindet sich im Paket display.
Dabei handelt es sich um ein weiteres Orocos-Modul. Dieses Modul kann optional innerhalb der Simulationsumgebung gestartet werden. Visualisiert wird der Plan für den
Controller sowie die Daten des LocationInfoGrids (s. 3.8).
22
3.2. PFADPLANUNGSALGORITHMUS
3.2 Pfadplanungsalgorithmus
Im Folgenden wird der umgesetzte Algortithmus zur Pfadplanung vorgestellt. Zunächst
wird die Funktionweise des A*-Algorithmus vorgestellt und anschließend dessen Erweiterung um kontinuierliche Koordinaten.
3.2.1 A*-Algorithmus
Der A*-Algorithmus bezeichnet einen Suchalgorithmus für den kürzesten Pfad in einem
Graphen mit gewichteten und nicht-negativen Kanten.[21] Außerdem werden bei der Suche Heuristiken verwendet. Dabei handelt es sich um Schätzfunktionen für die minimale
Entfernung eines Knotens zum Zielknoten. Die Wahl der Heuristik ist maßgebend für
die Effektivität der Suche. Die für das Zonenverhalten verwendeten Heuristiken werden
unter 3.4 ausführlich beschrieben. Die Heuristiken dürfen dabei den Weg nicht höher als
die realen Kosten abschätzen, da ansonsten die Gefahr besteht, dass die richtigen Knoten nicht expandiert werden. In diesem Fall kann auch nicht mehr garantiert werden,
dass der kürzeste Weg gefunden wird. Die Kosten entsprechen dabei der Bewertung eines
Zustandes. Je schneller von einem Zustand in den gewüschten Zielzustand übergegangen
werden kann, desto besser ist die Bewertung und dementsprechend geringer die Kosten.
Daher wird der Zielzustand immer mit den Kosten null bewertet.
Eine Funktion G(n) liefert die aktuellen Kosten vom Startknoten zu einem Knoten n.
Die Kosten setzen sich zunächst aus der Entfernung zusammen. Es könnten aber auf
unterschiedlichem Gelände auch verschiedene Gewichtungen für die Entfernung verwendet werden. Die Heuristiken realisieren die Funktion H(n), die die minimalen Kosten
zum Zielknoten abschätzen. Schließlich gibt es noch die Gesamtkostenfunktion F(n)
= G(n) + H(n). Im Anhang unter 6.1 befindet sich der zugehörige Pseudocode zum
A*Algorithmus aus [13].
Für den A*-Algorithmus wird eine OpenList und eine ClosedList benötigt. Die OpenList enthält alle Punkte, die noch untersucht werden müssen. Die ClosedList verwaltet
dementsprechend alle Punkte, die bereits expandiert und somit auch untersucht wurden.
Die Pfadplanung erfolgt vom Startknoten ausgehend zum Zielknoten. Der Startknoten
wird initial auf die OpenList gesetzt. Nun wird der Knoten aus der OpenList mit den
geringsten Gesamtkosten F(n) gewählt und auf die ClosedList verschoben. Danach werden alle Nachbarn des Knotens untersucht. Ist dieser aufgrund von Hindernissen nicht
erreichbar oder bereits auf der ClosedList enthalten, so wird er nicht weiter betrachtet.
Wenn der Nachbarknoten noch nicht auf der OpenList gesetzt wurde, so wird er eingefügt. Nun muss überprüft werden, ob ein kürzerer Pfad zu diesem Knoten gefunden
wurde. Dies ist der Fall, wenn G(n) des Vorgängerknotens n plus den Kosten der Kante
zum Nachbarknoten n+1 sowie den geschätzen Kosten H(n+1) kleiner sind, als der bisherige Wert der Gesamtkosten F(n+1) des Nachbarknotens. Dann müssen die bisherigen
Kosten G(n+1) und dementsprechend auch die Gesamtkosten F(n+1) aktualisiert wer-
23
3.2. PFADPLANUNGSALGORITHMUS
Abbildung 3.2: Pfadplanung mit dem A*-Algorithmus
den und der aktuell expandierte Knoten n wird nun als Vorgängerknoten gesetzt. Dieser
Vorgang wird wiederholt bis der Zielknoten auf die ClosedList gesetzt wird. In diesem
Fall wurde ein entsprechender Pfad gefunden. Wenn allerdings vorher die OpenList bei
der Suche leer wird, wurden alle Knoten betrachtet und es existiert kein Weg.
Der A*-Algorithmus sucht alle erreichbaren Knoten ab, bis ein Pfad gefunden wurde.
Existiert kein Pfad, so wurden auch alle erreichbaren Knoten untersucht und der Algorithmus ist terminiert. Daher wird garantiert, dass immer ein Pfad gefunden wird, sofern
er existiert. Daher wird der A*-Algorithmus als vollständig bezeichnet.
Weiterhin wird immer ein optimaler Pfad zwischen zwei Knoten gefunden. Wobei ein
optimaler Pfad von der Art der Gewichtsfunktion abhängt. So kann der optimale Pfad
die kürzeste, schnellste oder einfachste Verbindung sein. Die Heuristik darf dabei nicht
überschätzt werden. Jeder andere optimale und vollständiger Algorithmus, der die selbe
Heuristik verwendet, muss mindestens genauso viele Knoten untersuchen. Daher wird
A* auch als optimal effizient bezeichnet.
Abb. 3.2 zeigt ein Beispiel für einen Pfad, der mit dem A*-Algorithmus gefunden wurde.
Mit diesem Beispiel werden auch einige Nachteile bei der Suche mit dem A*-Algorithmus
in seiner Grundform deutlich. Die Suche wird auf einem diskreten Grid ausgeführt. Die
Punkte auf dem Grid werden durch gerade Strecken miteinander verbunden. Dadurch
entstehen scharfe Ecken und Kurven, die nur im Zickzack gefahren werden können.
24
3.2. PFADPLANUNGSALGORITHMUS
Abbildung 3.3: Übergänge bei Änderung der Orientierung gegen dem Uhrzeigersinn
Außerdem werden die nicht-holonomen Randbedingungen mißachtet. Das Auto könnte
den Pfad bestenfalls nur annähernd abfahren. Da die A*-Suche auch verhältnismäßig
rechenintensiv ist, kann das Grid nicht beliebig verkleinert werden.
3.2.2 Verwendung von kontinuierlichen Koordinaten
Aufgrund der zuvor beschriebenen Nachteile wurde für das Zonenverhalten die A*-Suche
basierend auf einem Grid mit kontinuierlichen Koordinaten erweitert. Jeder Knoten
besteht aus einer kontinuierlichen XY-Position und einer Orientierung mit Zuordnung
zu einer Zelle. Dadurch ergibt sich ein dreidimensionaler Planungsraum. Die Kosten
einer Zelle werden demnach nicht mehr mit dem Mittelpunkt assoziiert, sondern mit
den Kosten einer kontinuierlichen Koordinate innerhalb der Zelle. Dies entspricht dem
Hybrid A*-Ansatz (siehe 2.1). Durch die Verwendung von kontinuierlichen Koordinaten,
können nun die nicht-holonomen Randbedingungen des Fahrzeuges beachtet werden. Es
entstehen weichere Pfade, die nun vom Fahrzeug abgefahren werden können.
Mit der Klasse TansitionMap werden alle möglichen Übergänge vorberechnet. Mit einem Parameter PlanningArea::NUM OF DIRECTIONS kann festgelegt werden, mit wie
vielen Orientierungen geplant werden soll. Für die Berechnung der Übergänge wird der
Wendekreis in der vorher festgelegten Anzahl der Orientierungen geteilt. Dabei handelt
es sich um den Kreis mit dem Radius, der bei maximalen Lenkeinschlag abgefahren
werden kann. Pro absoluter Orientierung (hinsichtlich der Weltkoordinaten) des Fahrzeuges werden, die in der Abb. 3.4 dargestellten möglichen Übergänge, vorberechnet.
Dabei wird die Symmetrie in Vorwärts- und Rückwärtsrichtung genutzt. Abb. 3.3 zeigt
ein Beispiel dafür, wie die Übergänge jeweils aussehen, wenn gegen den Uhrzeigersinn
25
3.3. DETAILS ZUR PFADPLANUNG
gefahren wird sowie wenn acht Richtungen verwendet werden. Die jeweilige Nummer
codiert dabei eine entsprechende Orientierung. Um zum Beispiel von der Orientierung
null in eins wechseln zu können, muss das Auto mindestens Mx und My in absoluten
Weltkoordinaten zurücklegen. Genau nach diesem Prinzip wird der Abstand zum Nachbarknoten gewählt, wenn sich der Wert der Orientierung um eins ändert. Pro Schritt
kann sich dabei die Orientierung maximal um eins ändern. Damit immer Knoten gleicher
Länge expandiert werden, ergibt sich der Abstand zwischen den Knoten ohne Änderung
der Orientierung aus der Länge eines Kreissegments des Wendekreises. Unter 3.3 wird
beschrieben, wie die Knoten expandiert werden.
3.3 Details zur Pfadplanung
In diesem Abschnitt werden einige Teilaspekte bei der realisierten Pfadplanung besprochen. Dazu gehört zunächst die Zielgenerierung und wie die Informationen zu den Knoten
organisiert sind. Es folgt eine Beschreibung wie die Knoten während der Suche expandiert werden, welche Rolle die Hindernisse spielen und wie schließlich die Rekonstruktion
des Pfades erfolgt.
Zielgenerierung
Die gewünschten Koordinaten für das Ziel können entweder aus dem MDF ermittelt
oder manuell über den TaskBrowser mit einer entsprechenden Methode eingegeben werden. Für die Pfadplanung sind weitere Aufbereitungen der Koordinaten notwendig. Im
ersten Schritt müssen die Koordinaten mit Richtung von den relativen Angaben von der
aktuellen Position und Orientierung des Fahrzeugs in die absoluten Weltkoordinaten
übersetzt werden.
Der Parameter PathToPlanConverter::REACH TARGET FORWARD dient dazu festzulegen, ob das Ziel vorwärts oder rückwärts erreicht werden soll. Je nachdem wird dann
für die Pfadplanung ein weiteres Ziel vor bzw. hinter den eigentlichen Zielkoordinaten
generiert. Das letzte Plansegment vor dem Ziel besteht generell aus einem geraden Pfad
ohne Kurven.
Planungszone
Die Klasse PlanningArea enthält alle Informationen zur Planungszone und deren Parameter. Es wird ein zweidimensionales Grid (LocationInfoGrid ) verwendet, um gemeinsame Informationen zu Knoten an der gleichen Position mit unterschiedlichen Orientierungen zu verwalten. Dazu gehört, ob die Position von einem Hindernis belegt oder
26
3.3. DETAILS ZUR PFADPLANUNG
Abbildung 3.4: Expandieren eines Knotens
aufgrund von Hindernissen nicht erreichbar ist.
Als Parameter kann zur Laufzeit die Größe des Grids festgelegt werden. Dieser kann sich
z.B. beim Befahren einer neuen Zone ändern. Außerdem ist die Anzahl der Richtungen
pro Knoten und der Abstand zwischen den Knoten entsprechend konfigurierbar.
Expandieren der Knoten
Das Element mit den geringsten Kosten wird als nächstes Element aus der OpenList genommen und expandiert. Dazu werden zunächst zu dem aktuellen Knoten die Nachbarknoten ermittelt. Abbildung 3.4 zeigt wie ein Knoten maximal mit drei Knoten vorwärts
und weiteren drei Knoten bei Rückwärtsfahrt expandiert werden kann.
Nicht immer werden alle der dargestellten Knoten expandiert. So darf sich der Nachbarknoten nicht auf der ClosedList oder innerhalb des Sicherheitsabstand eines Hindernisses
befinden. Knoten können generell nur in Rückwärtsrichtung expandiert werden, wenn
die Rückwärtsfahrt erlaubt wird. Außerdem muss sich der Knoten ggf. innerhalb eines
Mindestabstandes zum Ziel befinden. Weitere besondere Einschränkungen gelten beim
Richtungswechsel (siehe 3.5).
Hindernisse
Neben den nicht-holonomen Randbedingen ist die Berücksichtigung von Hindernissen eine weitere Schwierigkeit bei der Pfadplanung. Dazu müssen die Sensoren die entsprechenden Daten von der Welt liefern, welche anschließend weiter aufbereitet werden müssen.
Die Hindernisse sind daher erst zur Laufzeit bekannt und es können demnach bei den
Heuristiken keine entsprechenden Vorberechnungen stattfinden. Die Kameras und La-
27
3.3. DETAILS ZUR PFADPLANUNG
serscanner liefern zunächst die Rohdaten. In weiteren Modulen werden diese Rohdaten
zu Hindernissen getrackt und für das Zonenverhalten können bereits die aufbereiteten
Objekte genutzt werden. Zu jedem Hindernis wird der Mittelpunkt und der Radius der
Bounding Sphere zur Verfügung gestellt. Bei einer Bounding Sphere handelt es sich
um eine Kugel, deren Mittelpunkt möglichst mit dem Mittelpunkt des zu umschließenden Objektes übereinstimmen sollte, um dieses optimal zu überdecken. Eine Bounding
Sphere ist eindeutig durch ihren Mittelpunkt und ihrem Radius festgelegt. Im Planungsmodul kann ein Sicherheitsabstand zu den Hindernissen festgelegt werden. Die Knoten
innerhalb des Sicherheitsabstandes werden nicht expandiert. Da sich die Knoten auf
dem Mittelpunkt des Autos beziehen, bedeutet dies, dass nur der Plan sich nicht innerhalb des Sicherheitsabstandes befinden kann. Die Umrisse des Autos können hingegen
durchaus in den Sicherheitsabstand hineinragen. Daher sollte der Sicherheitsabstand
ausreichend groß gewählt werden. Das ist mindestens eine halbe Autobreite plus den
Ungenauigkeiten, welche ggf. beim Abfahren des Plans entstehen können.
In der Simulationsumgebung sind bereits immer alle Hindernisse bekannt, was zu Erleichterungen bei der Planung führt. Im realen Szenario könnten aber auch Hindernisse
durch andere verdeckt werden. Das Auto würde das neue Hindernis also erst erkennen,
wenn ein anderes umfahren wird. Ebenso ist es denkbar, dass sich ein Objekt zunächst
im toten Winkel der Sensoren befindet und erst später registriert wird. Der Plan müsste
jeweils auf diese Änderungen angepasst werden. In diesem Fall müssten die betroffenen
Teile des Pfades aktualisiert oder komplett neu geplant werden.
Für die Überprüfung auf Hindernisse werden verschiedene Methoden durch die Klasse
ObstacleChecker zur Verfügung gestellt und genutzt. Die Methode isInObstacle überprüft,
ob sich eine Koordinate innerhalb des Radius der Bounding Sphere von einem der
bekannten Hindernisse plus Sicherheitsabstand befindet. Dazu wird überprüft, ob der
Abstand der Koordinate zum Mittelpunkt der jeweiligen Bounding Sphere kleiner ist
als der zugehörige Radius mit dem Sicherheitsabstand. Mit einer weiteren Methode
checkObstaclePresentBetweenPoints kann überprüft werden, ob sich ein Hindernis zwischen zwei Punkte befindet. Dabei wird mit den beiden Koordinaten eine Geradengleichung aufgestellt und mit dem Radius und dem Mittelpunkt der jeweiligen Bounding
Sphere entsprechend eine Kreisgleichung. Werden nun ein oder zwei Schnittpunkte von
der Gerade mit einem der Kreise ermittelt, so befindet sich ein Hindernis zwischen den
beiden Koordinaten.
Im Folgenden werden nur statische Hindernisse betrachtet. Im Ausblick wird beschrieben, wie der Umgang mit bewegten Hindernissen aussehen könnte.
Rekonstruktion des Pfades
Wurde ein Pfad gefunden, muss anschließend der Weg wieder rekonstruiert werden.
Dazu wurde zu jedem Knoten der Vorgänger gespeichert und der Pfad kann daher
zurückverfolgt werden. Anschließend wird überprüft, ob der jeweilige Abschnitt zwi-
28
3.4. HEURISTIKEN FÜR DEN KÜRZESTEN WEG
Abbildung 3.5: Rekonstruktion des Pfades
schen zwei Punkten rückwärts gefahren werden soll. Dazu wird zunächst der Abstand
zwischen den beiden Knoten (K1 und K2) berechnet. Anschließend wird jeweils der
Punkt in Vorwärts- und Rückwärtsrichtung (Pv und Pr) vom ersten Knoten K1 mit diesem Abstand berechnet. Ist nun der Abstand von Pv zu K2 kleiner als der Abstand Pr
und K2, so handelt es sich um eine Vorwärtsbewegung. Ansonsten wird rückwärts gefahren. In der Skizze 3.5 handelt es sich demnach um eine Rückwärtsbewegung. Dies wird
entsprechend im Knoten markiert und bei der Generierung des Plans für den Controller
können mit dieser Informationen die Rückwärtsabschnitte gesetzt werden.
3.4 Heuristiken für den kürzesten Weg
Für die Pfadplanung wird ein informiertes bzw. ein heuristisches Suchverfahren benutzt.
Dies wird durch die Verwendung einer heuristischen Funktion realisiert. Die Knoten werden demnach nicht beliebig expandiert, sondern die Auswahl des nächsten Knotens erfolgt anhand der Funktionswerte der entsprechenden Heuristiken. Eine Heuristik schätzt
die Kosten für den Übergang von einem Zustand in einen anderen. Bei der Pfadplanung
liefert die Heuristik einen Wert für die Länge des abzufahrenden Weges von einem Roboterstandpunkt zum Ziel. Die Effektivität des Suchalgorithmus hängt stark von der
Qualität der verwendeten Heuristik ab. Eine gute Heuristik kann die Rechenzeit und
den Speicherbedarf erheblich reduzieren.
Die Zulässigkeit einer Heuristik ist gegeben, wenn die Kosten für einen Knoten nie
überschätzt werden. Also muss der abgeschätzte Wert im Intervall zwischen null und
den tatsächlichen Kosten liegen. Demnach muss der Zielknoten immer mit null Kosten
bewertet werden. Ein einfaches Beispiel für eine zulässige Heuristik ist die Verwendung
29
3.4. HEURISTIKEN FÜR DEN KÜRZESTEN WEG
der Luftlinie für den minimalen Weg zwischen zwei Punkten. Diese Heuristik kann nie
überschätzen, da dieser Weg in jedem Fall mindestens zurückgelegt werden muss.
Ein weiteres Kriterium ist die Monotonie. Eine monotone Heuristik ist auch immer
zulässig. Es handelt sich hierbei also um eine stärkere Eigenschaft als die Zulässigkeit.
Dabei muss die folgende Bedingung gelten:
h(k) ≤ c(k, k 0 ) + h(k 0 )
(3.1)
Die Kosten des Vorgängerknotens k müssen kleiner oder gleich der Kosten des Nachfolgeknotens k’ plus den tatsächlichen Kosten für den Weg von k nach k’ sein. Wird diese
Eigenschaft nicht erfüllt, ist nicht notwendigerweise der kürzeste Weg bekannt. Daher
kann es vorkommen, dass einzelne Knoten mehrfach expandiert werden. In diesem Fall
darf keine ClosedList verwendet werden.
Im Folgenden werden die für die Planung verwendeten Heuristiken vorgestellt.
3.4.1 Nicht-Holonom ohne Hindernisse
Diese Heuristik beachtet die nicht-holonome Natur des Autos. Hindernisse werden dabei
aber nicht verwendet. Gegeben ist eine Start- und eine Zielposition jeweils mit einer
bestimmten Richtung. Nun soll die Länge des kürzesten Weges zwischen diesen Punkten abgeschätzt werden. Dabei werden an den Start- und Zielpositionen jeweils zwei
Wendekreise mit dem minimalen Wenderadius angelegt.
Jeder Wendekreis hat eine Richtung im oder gegen den Uhrzeigersinn. Die möglichen
Übergänge zwischen den beiden Wendekreisen an der Startposition und den Wendekreisen an der Zielposition wird jeweils durch Tangenten zwischen den Kreisen realisiert.
Es werden nur die Tangenten mit der richtigen Richtung verwendet. Ein möglicher Weg
setzt sich also aus drei Teilen zusammen: Es wird zunächst ein Teil des Wendekreises
an der Startposition bis zum ExitPoint gefahren. Dann folgt eine Geradeausfahrt bis
zum EntryPoint auf einem der Wendekreise an der Zielposition. Nun muss noch auf
dem Wendekreis gefahren werden bis schließlich die Zielposition mit entsprechender Orientierung erreicht ist. Aus diesem Modell ergeben sich für die Heuristik vier mögliche
Kandidaten für den kürzesten Weg (siehe Abbildung 3.6). Für alle vier Möglichkeiten
wird die Länge berechnet und schließlich der kleinste Wert zurückgegeben.
Da alle Informationen für die Berechnung der Heuristikwerte schon vor der Laufzeit
bekannt sind, können hier die Werte vorberechnet werden. Dabei muss allerdings der
maximal verfügbare Speicher berücksichtigt werden. Um Speicherplatz zu sparen, kann
die Symmetrie zwischen den Punkten genutzt werden.
30
3.4. HEURISTIKEN FÜR DEN KÜRZESTEN WEG
Abbildung 3.6: Wendekreise an den Start- und Zielpunkten
Vorberechnung der Heuristikwerte
Unter [20] wird die Verwendung einer Heuristic Look-Up Table (HLUT) beschrieben.
Auch für die nicht-holonome Heuristik ohne Hindernisse wurden die Werte teilweise vorberechnet und über eine Look-Up Tabelle zur Verfügung gestellt. Über die Konstante
PRECALCULATE VALUES kann eingestellt werden, ob die Werte der Heuristik vorberechnet werden sollen oder ob die Berechnung zur Laufzeit stattfindet. Da die Vorberechnung der Werte verhältnismäßig viel Zeit in Anspruch nimmt, werden die berechneten
Werte in eine Datei geschrieben. Beim nächsten Start des Moduls wird dann zunächst
überprüft, ob die Datei mit den vorberechneten Heuristikwerten vorhanden ist. Dann
werden alle Werte direkt aus der Datei geladen, andernfalls wird die entsprechende Datei erzeugt. Die Heuristikwerte kürzerer Distanzen werden bei der Pfadplanung häufiger
benutzt als für längere Distanzen. Daher werden zur Reduzierung des Speicherbedarfs
nur die Werte für kürzere Distanzen vorgeladen. Die Heuristikwerte für zwei Punkte mit
großem Abstand werden weiterhin zur Laufzeit berechnet. Die vorberechneten Werte
beziehen sich allerdings jeweils auf einem Punkt des Gitters. Dadurch entstehen Ungenauigkeiten gegenüber den zur Laufzeit berechneten Werten, da hier die genaue Position
verwendet wird. Je kleiner das Gitter gewählt wird, desto kleiner sind also auch die Fehler.
31
3.4. HEURISTIKEN FÜR DEN KÜRZESTEN WEG
Abbildung 3.7: Expandierte Knoten mit dem euklidischen Abstand
Die Stärke dieser Heuristik wird im Vergleich zur Verwendung des euklidischen Abstandes besonders bei kurzen Distanzen deutlich. Abb. 3.7 zeigt das Ergebnis der Planung
zu einer Position zehn Meter vorwärts mit einer 180 Grad-Drehung. Die Anzahl der expandierten Knoten beträgt 63.319, wobei die OpenList eine maximale Größe von 11.369
Knoten erreicht hat. Im Gegensatz dazu werden bei Verwendung der nicht-holonomen
Heuristik ohne Hindernisse deutlich weniger Knoten expandiert (siehe Abb. 3.8). Die
Anzahl beträgt nun lediglich 146 mit einer maximalen Größe der OpenList von 97. Der
generierte Pfad ist bei beiden Varianten identisch.
3.4.2 Holonom mit Hindernissen
Diese Heuristik ignoriert die nicht-holonome Natur des Autos, jedoch werden Hindernisse berücksichtigt. Aufgrund der Annahme einer holonomen Bewegung kann jeder Nachbarknoten expandiert werden, solange dieser hindernisfrei ist. Da die Orientierung des
Fahrzeuges nicht von der Heuristik beachtet wird, erfolgt die Planung auf einem zweidimensionalen Grid. Der Vorteil dieser Heuristik ist, dass schnell Sackgassen entdeckt
werden können.
Vor der eigentlichen Planung kann mit der Heuristik schnell getestet werden, ob ein Ziel
innerhalb der Planungszone überhaupt erreichbar ist oder von Hindernissen blockiert
wird. In diesem Fall werden dabei alle erreichbaren Knoten expandiert und es wird
32
3.5. RICHTUNGSWECHSEL UND RÜCKWÄRTSFAHREN
Abbildung 3.8: Expandierte Knoten mit der nicht-holomonen Heuristik
kein entsprechender Pfad gefunden. Alle nicht expandierten Knoten werden nun als
unerreichbar markiert und es wird ein neues Ziel gewählt.
Realisiert wird die Heuristik mit einer einfachen A*-Suche. Liegt ein Nachbarknoten in
einem Hindernis bzw. innerhalb des Sicherheitsabstandes, so wird dieser Knoten nicht
expandiert. Bei der Konfiguration eines großen Abstandes zwischen den Knoten, kann
außerdem überprüft werden, ob zwischen den Knoten ein Hindernis liegt. Dies ist aber
bei einer relativ kleinen Gittergröße nicht notwendig. Da die Information über die Lage
der Hindernisse erst zur Laufzeit zur Verfügung stehen, können die Werte für diese
Heuristik nicht vorberechnet werden.
3.5 Richtungswechsel und Rückwärtsfahren
Die Rückwärtsabschnitte des Pfades werden speziell markiert (s. 3.6) und die Richtung
wird invertiert. So hat der Controller die entsprechenden Informationen, um an den
jeweiligen Punkten in den Rückwärtsgang zu schalten und diese Abschnitte anschließend
rückwärts abzufahren.
Bei einem Wechsel vom Vorwärts- auf den Rüchwärtsgang und umgekehrt können Spitzen im Plan entstehen. Das bedeutet, dass die ein- und ausgehende Kante zu einem
Punkt, an dem der Gangwechsel stattfindet, sehr eng zusammenliegen können. Dabei
kann das Problem entstehen, dass das Auto schon abstoppt bevor die Spitze erreicht wurde, weil sich der Controller bereits auf die ausgehende Kante projiziert. Daher gelten hier
besondere Anforderungen und der Controller wurde entsprechend angepasst. Alternativ
ist es mit dem Parameter PathToPlanConverter::USE PLAN PARTS konfigurierbar, ob
33
3.5. RICHTUNGSWECHSEL UND RÜCKWÄRTSFAHREN
Abbildung 3.9: Richtungswechsel
nur jeweils Teile des Plans bis zum Gangwechsel an den Controller übergeben werden sollen. Dabei wird wie zuvor zunächst der gesamte Pfad geplant. Ist der erste Teil des Plans
abgefahren, so wird der nächste Abschnitt an den Controller gereicht. Dabei können aber
auch möglicherweise sehr kurze Teilpläne entstehen, die der Controller aufgrund einer
erwarteten Mindestlänge nicht abfahren kann. Es kann aber auch konfiguriert werden,
wie viele Segmente mindestens ohne Gangwechsel gefahren werden sollen.
Um zu gewährleisten, dass beim Wechsel der Fahrtrichtung der Plan abfahrbar bleibt,
sind weitere Anpassungen in der Planung notwendig. Bei der durch den Wechsel der
Fahrtrichtung entstehenden Spitze im Plan, wird eine Gerade mit konfigurierbarer Länge
hinzugefügt. Das ermöglicht dem Auto beim Richtungswechsel auf dem geplanten Pfad
zu bleiben.
Für die Konfiguration des Richtungswechsels werden zwei Zählervariablen (siehe SameDirCounter und StraightForwardCounter in der Abb. 3.9) verwendet. Der erste Zähler
registriert die Anzahl der Segmente, die zusammenhängend vorwärts bzw. rückwärts
gefahren wurden. Änderungen in der Orientierung an sich spielen dabei keine Rolle. Der
zweite Zähler summiert die Segmente auf, die in derselben Orientierung und Richtung
34
3.6. KONVERTIERUNG DES PFADES ZUM PLAN
aufeinander folgen. Mit einem Parameter kann die Anzahl der aufeinanderfolgenden Segmente konfiguriert werden, die mindestens notwendig sind, um einen Richtungswechsel
einzuleiten. Wurde die entsprechende Anzahl an Knoten mit derselben Orientierung (und
Richtung) expandiert, kann der Vorgängerknoten erneut expandiert werden. Intern wird
dabei allerdings ein neuer Knoten mit dem Status turnMode erzeugt. Ist ein Knoten im
turnMode, so erhält dieser einen Sonderstatus beim weiteren Expandieren. Die jeweiligen
Vorgängerknoten werden nun kopiert und dabei der Zähler für dieselben Orientierungen
rückwärts gezählt. Der turnMode bleibt solange erhalten bis der Zähler den Wert null erreicht, dann wird auch der erste Zähler wieder auf null zurückgesetzt. In diesem Knoten
kann nun in jeder beliebigen Richtung weitergefahren werden. Der nächste expandierte
Knoten verliert demnach anschließend den Status turnMode.
3.6 Konvertierung des Pfades zum Plan
Die Pfadplanung ermittelt eine Liste von Punkten mit den XY-Positionen sowie mit der
jeweiligen Orientierung des Fahrzeugs. Die Aufgabe des PlanGenerators besteht darin,
den gefundenen Pfad in einen für den Controller abfahrbaren Plan zu konvertieren.
Metadaten
Der Plan besteht aus drei abstrakten übereinandergelegten Schichten. Bei der ersten
Schicht handelt es sich um den Fahrspline, welcher die geplanten Bewegungen des Autos
beschreibt. Dort werden jeweils die Positionen und die Richtungen mit einem zugehörigen
Parameter gesetzt. Der Controller generiert durch diese Punkte dann den entsprechenden Spline. Die Änderung des Wertes der Parameter zwischen zwei Punkten entspricht
dabei der Länge des Splines zwischen diesen beiden Punkten. Die zweite Schicht ist der
EdgeTrack für die Abbildung des Straßennetzes. Hier werden die dazugehörigen Kanten
des RNDF-Graphen mitgegeben. Dadurch kann der Controller z.B. die Geschwindigkeitsbegrenzungen der jeweiligen Kante beachten. Schließlich handelt es sich bei dem
ActionTrack um die dritte Schicht, um verschiedene Aktionen auf dem Plan zu markieren. So wird die Kommunikation zwischen dem Verhalten und dem Controller realisiert.
Wichtige Aktionen für das Zonenverhalten sind zunächst der Start- und Zielpunkt. Der
Zielpunkt muss angegeben werden, da ansonsten der Controller vor dem Ende des Plans
stoppen würde, weil im Straßenverhalten eine Mindestlänge des Plans erwartet wird.
Weiterhin wird dem Controller mitgeteilt, dass sich der Plan in einer Zone befindet. Für
das Rangieren müssen außerdem die Abschnitte markiert werden, die rückwärts vom
Controller abgefahren werden sollen. Die Rückwärtsabschnitte werden bei der Rekonstruktion des Pfades ermittelt (s. 3.3).
35
3.6. KONVERTIERUNG DES PFADES ZUM PLAN
Abbildung 3.10: Planoptimierung
Segmente am Planende
Die Pfadplanung generiert nur einen Weg bis zu einem Punkt kurz vor bzw. hinter den
eigentlichen Zielkoordinaten (siehe 3.3). Das letzte Ende des Plans wird anschließend
vom PathToPlanConverter angefügt. Dabei wird überprüft, ob sich zwischen dem aktuell letzten Punkt des Pfades und dem eigentlichen Ziel ein Hindernis befindet. Ist
das der Fall, wird dieser Teil nicht hinzugefügt und eine entsprechende Meldung ausgegeben. Außerdem kann ein Richtungswechsel vom letzten Punkt des Pfades zu diesem
letzten generierten Segment vorliegen. In diesem Fall wird vom PathToPlanConverter
eine weitere Gerade (wie beim Richtungswechsel 3.5 beschrieben) hinzugefügt, um diesen
Richtungswechsel abfahrbar zu machen. Auch hier erfolgt eine Überprüfung des Weges
zwischen den Punkten auf Hindernisse.
Planoptimierung
Die Optimierung erfolgt durch den PlanOptimizer in mehreren Schritten. Im ersten
Schritt wird der Pfad nach zusammenhängenden Punkten mit gleicher Richtung abgesucht. Ändert sich beim nachfolgenden Punkt nicht die Richtung, so wird dieser aus
dem Pfad gelöscht. Im nächsten Optimierungsschritt wird im Pfad nach Abschnitten
gesucht, in denen die Punkte zwischen zwei Richtungen toggeln. Ändert sich die Orientierung mehrmals in einer Richtung, so wird dieser Teil übernommen. Wenn sich aber
in einem Abschnitt die Orientierungen nur minimal ändern, so wird dieser Abschnitt
geglättet. Durch diese Optimierungen wird ein Schlingern beim Geradeausfahren verhindert. Außerdem wurden aus dem Pfad alle unötigen Zwischenpunkte gelöscht.
Abb. 3.10 zeigt ein Beispiel für eine solche Planoptimierung. Links ist der Plan vor
36
3.7. FAHREN VON MISSIONEN UND EINPARKMANÖVER
der Optimierung, rechts nach der Optimierung dargestellt. Vorher wird bei mehreren
hintereinanderliegenden Knoten am Ende des Plans die Richtung gewechselt. Dadurch
wird ein leichtes Schlingern erkennbar. Durch die Optimierung wurde das Schlingern
entfernt und der Plan entsprechend geglättet.
3.7 Fahren von Missionen und Einparkmanöver
Das FreeFormNavigation-Modul stellt eine Methode driveMission zur Verfügung, die
über dem TaskBrowser aufgerufen werden kann. Beim Aufruf wechselt das Modul in
den Missionsmodus, bei dem nacheinander die Checkpoints aus dem MDF angefahren
werden. Die Klasse MissionHandler liefert dabei immer den nächsten anzufahrenden
Checkpoint aus dem MDF und überprüft, ob der aktuelle Checkpoint erreicht wurde.
Die Planung erfolgt jeweils bis zum nächsten Checkpoint.
Abbildung 3.11: Vorwärts- und Rückwärtseinparkmanöver
37
3.8. VISUALISIERUNG
Wird ein Checkpoint von einem Hindernis blockiert, so wird dieser übersprungen und der
nächste aus dem MDF gewählt. Die Klasse ParkingArea enthält die Informationen zur
Zone aus dem RNDF. Dazu gehört der Mittelpunkt und die Dimension der Bounding
Box der Zone. Mit diesen Daten kann beim Befahren einer Zone die entsprechende
Planungszone dynamisch zur Laufzeit aufgespannt werden.
In der Abb. 3.11 wird jeweils ein Vorwärts- und ein Rückwärtsparkmanöver dargestellt.
Mit dem Parameter PathToPlanConverter::REACH TARGET FORWARD kann eingestellt werden, ob die Zielposition vorwärts oder rückwärts erreicht werden soll. Bereits
beim Einfahren in die Parklücke erreicht das Auto die entsprechende Zielorientierung.
Das letzte Stück in der Parklücke wird demnach geradeaus gefahren. Aus den Abbildungen wird auch deutlich, dass bei Manövern mit Rückwärtsabschnitten deutlich mehr
Knoten expandiert werden. Mit einem Parameter der Klasse AStarPathGenerator kann
dabei eingestellt werden, ab welcher Entfernung zum Ziel die Rückwärtsfahrt bei der Planung erlaubt wird. Dadurch kann vermieden werden, dass das Fahrzeug frühzeitig in den
Rückwärtsgang wechselt und so längere Strecken rückwärts fährt. Dies kann aufgrund
der Suche nach dem kürzesten Weg durchaus vorkommen.
3.8 Visualisierung
Zur Visualisierung der Planung in der Simulation dient das Modul DisplayFreeFormNavigation. Dabei handelt es sich um ein weiteres Orocos-Modul, welches parallel in einem
eigenen Thread ausgeführt wird. Das Modul kann zur Laufzeit mit einem entsprechend
zugewiesenen Tastenkürzel in der XML-Konfigurationsdatei aktiviert bzw. deaktiviert
werden. Dabei wird die Planungszone und der eigentliche Plan als Eingabe übergeben.
Bild 3.12 zeigt das aktive Visualisierungsmodul in der Simulationsumgebung. Die grünen
Punkte entsprechen dabei expandierte und erreichbare Knoten. Wobei die Knoten mit
unterschiedlichen Richtungen expandiert sein können. Von Hindernissen bedeckte Knoten und Knoten innerhalb des Sicherheitsabstandes sind rot markiert. Wurde erkannt,
dass der Weg zu einem Knoten aufgrund von Hindernissen versperrt wird, so werden
diese orange dargestellt. Neben den initialisierten Knoten wird auch der Fahrspline visualisiert. Die vom Plan benutzten Knoten werden durch gelbe Punkte und das Ziel
durch einen weißen Punkt markiert.
3.9 Verwendung des Moduls
Über eine XML-Konfigurationsdatei kann das Modul in Kombination mit den anderen Modulen verwendet werden (siehe 2.6). Die entsprechenden Module werden von der
DeploymentComponent geladen und periodisch ausgeführt. Das FreeFormNavigationModul stellt Methoden zur Verfügung, die manuell aufgerufen werden können, um Pfa-
38
3.9. VERWENDUNG DES MODULS
Abbildung 3.12: Visualisierung in der Simulation
de zu bestimmten Positionen zu planen. Über den TaskBrowser können diese Methoden
während der Ausführung aufgerufen werden. Mit der Methode driveToPosition kann zu
einer bestimmten Position mit einer bestimmten Orientierung ein Pfad geplant werden.
Der Mittelpunkt des Weltkoordinatensystems wird dabei auf die aktuelle Fahrzeugposition gelegt. Beim Aufruf müssen drei Paramter übergeben werden. Dabei handelt es sich
um die Anzahl der Meter in absoluten Weltkoordinaten in Richtung Osten und Norden
sowie um einen ganzzahligen Wert für die Zielorientierung. Die Zielorientierung ist ein
Wert zwischen null und dem Parameter PlanningArea::NUM OF DIRECTIONS, wobei
von Richtung Osten ausgehend gegen den Uhrzeigersinn gezählt wird.
Ein Alternative dazu stellt die Methode driveToRelativPosition dar. Auch hier wird der
Mittelpunkt des Weltkoordinatensystems auf die aktuelle Fahrzeugposition gelegt und es
müssen drei Parameter für die gewünschte Zielposition übergeben werden. Dazu gehört
die Anzahl der Meter vorwärts geradeaus und die Anzahl der Meter nach links jeweils von
der aktuellen Fahrzeugrichtung ausgehend. Für eine Zielposition nach hinten bzw. nach
rechts ausgehend der aktuellen Position müssen entsprechend negative Werte angegeben
werden. Für die Zielorientierung kann ein Wert zwischen minus 180 und plus 180 Grad
verwendet werden, wobei ein positiver Wert eine Änderung der aktuellen Orientierung
nach links sowie ein negativer Wert nach rechts entspricht.
Mit der Methode driveMission wird der Missionsmodus aktiviert und es werden gemäß
des geladenen MDFs die Checkpoints nacheinander abgefahren (siehe 3.7). Dazu wird
immer nur bis zum aktuellen Checkpoint geplant. Die Methode configPlanningArea konfiguriert die aktuelle Planungszone, in der sich das Auto befindet. Der Parameter Di-
39
3.10. PERFORMANCEOPTIMIERUNGEN
mension gibt dabei in der Einheit Meter an, wie groß die Kanten der aufgespannten
Planungszone sind. Zusätzlich muss die X und Y Position in absoluten Weltkoordinaten für den Mittelpunkt der Planungszone angegeben werden. Über das Modulattribut
UseReversePlanning kann ein- und ausgeschalten werden, ob Rückwärtsfahren generell
erlaubt wird.
3.10 Performanceoptimierungen
Besonders große Auswirkungen hatte die Verwendung von konstanten Referenzen bei der
Übergabe von Parametern beim Aufruf von Methoden. Wird kein const verwendet, so
werden Kopien der Objekte, die als Parameter beim Methodenaufruf übergeben werden,
angelegt. Mit Verwendung einer konstanten Referenz geschieht dies nicht. Hier wird mit
dem originalen Objekt gearbeitet unter der Einschränkung, dass das übergebene Objekt
nicht verändert werden darf. Wird dies dennoch versucht, gibt bereits der Compiler eine
entsprechende Meldung aus. Gleiches gilt für Rückgabewerte von Methoden. Demnach
kann oftmals bei Getter- und Setter Methoden diese Technik eingesetzt werden (siehe
[26] Tipp 20: Übergeben Sie Objekte lieber als Verweis auf const statt als Wert).
Weitere Vorteile bringt es, wenn die Zuweisung der Datenelemente beim Erstellen eines
Objektes mit einer Elementinitialisierungsliste stattfindet, anstatt die Werte im Rumpf
eines Konstruktor zuzuweisen. Beide Varianten führen zum selben Endergebnis. Allerdings werden bei der zuweisungsbasierten Version zunächst die Standardkonstruktoren
aufgerufen. Die standardmäßig konstruierten Werte werden anschließend bei der Zuweisung durch neue Werte ersetzt (siehe [26] Tipp 4: Initialisieren Sie Objekte vor ihrer Verwendung). Dieses Problem kann durch die Verwendung einer Elementinitialisierungsliste
vermieden werden. Die Argumente werden hier direkt als Konstruktorargument für die
verschiedenen Datenelemente verwendet. Nun wird also lediglich der Kopierkonstruktor
verwendet, anstatt zunächst den Standardkonstruktor und anschließend den Kopierzuweisungsoperator aufzurufen. Auch mit dieser Technik konnte die Performance merklich
verbessert werden. Unter [26] findet man ein Buch mit vielen weiteren nützlichen Tipps
zu dem Thema.
Für effektive Berechnungen mit zweidimensionalen Koordinaten wurde die Klasse SimplePoint eingeführt. Ein Objekt der Klasse besitzt nur die zwei Attribute für eine X und
eine Y Koordinate. Diese Objekte werden für die kontinuierlichen Positionen und Richtungen auf dem Grid verwendet. Zusätzlich wurden einige Operatoren überladen, wie
z.B. die Addition, Subtraktion oder Multiplikation mit einer anderen Koordinate oder
die Normalisierung des zweidimensionalen Vektors. Da die Klasse sehr schlank aufgebaut
ist, konnten hier gegenüber ähnliche Datentypen (z.B. Matrix mit zwei Elementen aus
der C++ Bibliothek Eigen) erhebliche Geschwindigkeitsverbesserungen erzielt werden.
40
3.10. PERFORMANCEOPTIMIERUNGEN
In der OpenList werden alle Knoten gespeichert, die noch untersucht werden müssen.
Dafür wurde der Datentyp priority queue aus der C++ Standard-Bibliothek verwendet.
Durch das Überladen des Vergleichsoperators < wird die Prioritätswarteschlange automatisch nach der Priorität der enthaltenen Elemente sortiert, sobald neue Elemente
hinzugefügt bzw. entfernt werden oder sich die Priorität eines Elementes geändert hat.
In diesem Fall handelt es sich bei der Priorität um die Gesamtkosten eines Knotens
(bisheriger Weg und die geschätzten Kosten zum Ziel). Da die Objekte der Klasse StateNode viele Informationen enthalten, kann die Sortierung der Elemente aufgrund vieler
Speicherzugriffe entsprechend viel Zeit beanspruchen. Daher wurde statt StateNode die
Klasse PriorityQueueElement verwendet. Diese enthält nur noch eine ID zu einem Knoten und der überladene Vergleichsoperator greift über die ID auf die entsprechenden
Kosten zu. Die Zeit für die Umsortierungen konnte so etwa auf ein Drittel reduziert
werden.
Bei Beginn der Planung eines Pfades wird die Aktualisierung des Visualisierungsmoduls
deaktiviert. So steht mehr Rechenleistung für das Zonenverhaltenmodul während der
Planung eines Pfades zur Verfügung. Nachdem ein Plan generiert wurde, erfolgt wieder
die regelmäßige Aktualisierung der Visualisierung.
41
4
Analyse und Test des Moduls
4.1 Einsatz von Werkzeugen zur Analyse
Um den Quelltext hinsichtlich der Performance zu untersuchen, wurde Valgrind eingesetzt (Webseite unter [24]). Valgrind ist eine Sammlung von Werkzeugen zur Analyse
der Software in Hinsicht auf Fehler oder Performanceproblemen. Mit dem Valgrind-Tool
Callgrind können umfangreiche Statistiken über die Ausführungszeiten des Programms
erstellt werden. Gemessen wird dabei nicht die eigentliche Ausführungszeit, sondern die
Anzahl der CPU-Takte. Daher sind die Ergebnisse von unterschiedlichen Systemen miteinander vergleichbar. Zur Erstellung der Daten wird das zu untersuchende Programm
über Valgrind gestartet. Dieser Vorgang kann allerdings verhältnismäßig zeitintensiv
sein, da die Ausführung des Programms während des Profilings erheblich verlangsamt
wird. Die Profilerdaten können mit einem weiteren Tool zur Visualisierung namens KCachegrind weiter untersucht werden. Abbildung 4.1 zeigt ein Screenshot von KCachegrind
mit entsprechenden Profilerdaten. So wird z.B. zu jeder Methode im Kostenprofil der
prozentuale Rechenanteil angezeigt. Über einen Aufrufgraphen kann man schnell zu den
performance-kritischen Passagen im Quelltext navigieren.
4.2 Simulationsumgebung
Da Tests am realen Fahrzeug sehr zeitintensiv und teuer sind, wird zur Entwicklung der
Steuerungssoftware eine Simulationsumgebung benötigt. Mithilfe einer Simulationsumgebung kann schnell getestet werden, ob die entwickelte Software für die reale Hardware
einsatzbereit ist bzw. wo die aktuellen Probleme liegen. Innerhalb des AutoNOMOS
Projektes gibt es eine 3D-Testumgebung, in der statische sowie dynamische Hindernis-
42
4.3. TESTFAHRZEUGE DER FREIEN UNIVERSITÄT BERLIN
Abbildung 4.1: Visualisierungstool KCacheGrind
se simuliert werden können. Dadurch ist es z.B. möglich Situation im Straßenverkehr
nachzustellen.
Über eine XML-Datei wird eine Testkonfiguration zusammengestellt und die Module werden entsprechend miteinander verbunden. Anschließend kann das Zusammenspiel
der verschiedenen Module in der Simulationsumgebung ausgeführt werden. Um ein TestSzenario zu erstellen, wird ein RNDF für das Straßennetz und ein MDF für die Missionsparameter benötigt. Außerdem können statische sowie bewegte Hindernisse aus einer
weiteren XML-Datei geladen werden.
Auch bei der Entwicklung des FreeFormNavigation-Moduls wurde die Simulationsumgebung genutzt, um verschiedene Szenarien der Pfadplanung zu testen und Fehler aufzuspüren. Dazu wurden entsprechende Testkonfiguration zusammengestellt. Die Schnittstellen sind dabei die gleichen, wie bei der Konfiguration mit der realen Hardware.
4.3 Testfahrzeuge der Freien Universität Berlin
In der Arbeitsgruppe Künstliche Intelligenz der Freien Universität Berlin wird mit zwei
Prototypen autonomer bzw. semi-autonomer Fahrzeuge geforscht. Abb. 4.2 zeigt die beiden Fahrzeuge während einer Vorführung auf dem stillgelegten Flughafen Berlin Tempelhof. Beim ersten Fahrzeug Spirit of Berlin (SpoB) links im Bild handelt es sich um einen
Dodge Grand Caravan Baujahr 2000, der mit Sensoren, Computern und zusätzlichen Aktoren ausgestattet wurde. Bei den hinzugefügten Aktoren handelt es sich um Motoren
43
4.3. TESTFAHRZEUGE DER FREIEN UNIVERSITÄT BERLIN
Abbildung 4.2: Die Testfahrzeuge SpoB und MiG im Einsatz
für die Steuerung der Lenkrad- und Gaspedalstellung. Dieses System wurde ursprünglich
entwickelt, um eine behindertengerechte Nutzung von Autos zu ermöglichen. Dadurch
wird aber auch die Kommunikation zwischen dem Bordrechner und der Aktoren möglich.
So kann das Auto fahrerlos gesteuert werden. Ein solches Fahren oder Steuern von Fahrzeugen ohne mechanische Kraftübertragungen zu den Stellelementen, wie Gaspedal oder
Lenkrad wird als Drive-by-Wire bezeichnet. Das zweite Fahrzeug (rechts) ist ein modifizierter VW Passat namens Made in Germany (MiG). Auch hier wird die Drive-by-Wire
Technologie verwendet, allerdings kann hier direkt über den CAN-Bus auf die entsprechenden Stellelemente zugegriffen werden.
Die Bedingungen für die Planung beim echten Fahrzeug unterscheiden sich vor allem
darin, dass die Hindernisse nicht wie in der Simulationsumgebung schon vorher alle
bekannt sind. Es sind immer nur die von den Sensoren getrackten Hindernisse sichtbar. So
können zum Beispiel Situationen entstehen, in denen neue Hindernisse auftauchen (siehe
3.3). Daher müssen in der realen Welt ggf. häufiger Anpassungen am Plan durchgeführt
werden.
Nach verschiedenen Tests in der Simulationsumgebung, wurde das Modul anschließend
erfolgreich am realen Fahrzeug getestet. Dabei wurde die XML-Konfigurationsdatei so
angepasst, dass die echte Hardware verwendet wird. Mit dem Modul konnten Pfade geplant werden, die anschließend vom Testfahrzeug MiG abgefahren wurden. Dabei stellte
sich heraus, dass sehr scharfe Kurven mit dem Fahrzeug sogar besser als in der Simulationsumgebung abgefahren werden konnten.
44
5
Alternative Ansätze
In diesem Kapitel werden zwei alternative Algorithmen für die Pfadplanung diskutiert.
Dabei wird darauf eingegangen, welche Vor- und Nachteile sich im Vergleich zur zuvor
beschriebenen und realisierten Lösung ergeben.
5.1 Anytime Dynamic A*
Der Anytime Dynamic A* -Algorithmus ist wie die herkömmliche A*-Suche auf einem
Graphen basierend (siehe Artikel unter [22]). Der Pseudocode aus [22] befindet sich
im Anhang unter dem Abschnitt 6.3. Mit diesem Algorithmus ist es möglich, zunächst
suboptimale Lösungen in einer begrenzten Zeit zu finden. Anschließend wird die Qualität
der bestehenden Lösung allmählich verbessert, je nachdem wie viel Zeit für die Suche zur
Verfügung steht. Bei jedem Schritt werden die Ergebnisse aus den letzten Berechnungen
wiederverwendet. Auch auf Änderungen in der Umgebung kann bis zu einem gewissen
Grad reagiert werden, ohne komplett neu planen zu müssen. So kann zum Beispiel ein
Hindernis auf dem bisher gefundenen Weg auftauchen. Dann wird basierend auf der
ursprünglichen Lösung der Pfad inkrementell repariert bis schließlich ein neuer Pfad
gefunden wird.
Die Abb. 5.1 skizziert ein einfaches Beispiel für die Navigation eines Roboters mit dem
Anytime Dynamic A* -Algorithmus. Der Roboter befindet sich anfangs in der rechten
unteren Zelle. Zunächst wird ein suboptimaler Weg zur oberen linken Zelle gefunden
(ganz links). Anschließend bewegt sich der Roboter um eine Zelle weiter, währenddessen
nach einer besseren Lösung gesucht wird (mitte). Der Parameter beeinflusst dabei die
Qualität des gefundenen Pfades. Je höher der Wert von , desto schneller wird ein Pfad
gefunden, gleichzeitig verschlechtert sich aber auch möglicherweise das Ergebnis. Der
Wert des Parameters wird bei jedem weiteren Schritt verkleinert und so die Qualität des
45
5.2. RAPIDLY-EXPLORING RANDOM TREES
Abbildung 5.1: Beispiel: Pfadplanung mit Anytime Dynamic A* [22]
Pfades verbessert. Nachdem der Roboter noch eine weitere Zelle zurückgelegt hat, öffnet
sich eine Lücke in der Wand (rechts). Obwohl sich das Modell von der Welt geändert
hat, muss nicht komplett neu geplant werden. Die neue Information wird verwendet,
um die bisherige Lösung schrittweise zu verbessern bis schließlich eine optimale Lösung
gefunden wurde.
5.2 Rapidly-Exploring Random Trees
Beim Rapidly-Exploring Random Tree (RRT) handelt es sich um ein weiteres Konzept
für eine Datenstruktur und Algorithmus zur Pfadplanung. Der Pseudocode aus [23] befindet sich im Anhang unter 6.2. Dabei wird ein Suchbaum schrittweise konstruiert,
der von einem gegebenen Startpunkt zufallsgenerierte Pfade durch den freien Raum abbildet. Im ersten Schritt wird ein zufälliger Punkt P in einem N-dimensionalen Raum
gewählt. Dann wird der Knoten K1 im aktuellen Baum gesucht, der sich am nächsten zu
P befindet. Von K1 wird anschließend ein neuer Punkt K2 um eine konstante Distanz in
Richtung P erstellt. Nun muss überprüft werden, ob die Erweiterung vom bestehenden
Knoten K1 zum neuen Knoten K2 gültig ist. Dazu darf zwischen den beiden Knoten kein
Hindernis existieren. Ist kein Hindernis vorhanden, so wird der bestehende Baum um
den Knoten K2 expandiert. Mit einer konfigurierbaren Wahrscheinlichkeit wird anstatt
des zufälligen Punktes, in dessen Richtung expandiert wird, das Ziel selbst verwendet.
So wird die Expansion des Baumes zwischendurch in Richtung Ziel begünstigt. Dieser Vorgang wird zu einer beliebig festgelegten Anzahl an Iterationen wiederholt. Die
Abb. 5.2 zeigt ein Beispiel für die Entwicklung eines RRT bei unterschiedlicher Anzahl
von Iterationen.
46
5.3. VERGLEICH ZUR IMPLEMENTIERTEN LÖSUNG
Abbildung 5.2: Beispiel für die Expansion eines RRTs [23]
Um schnellere Ergebnisse zu erzielen, kann ein RRT jeweils vom Start- und Zielpunkt
expandiert werden. Wenn sich die beiden Bäume treffen, können sie zusammengefasst
werden. Aufgrund der nicht-holonomen Randbedingungen muss der Winkel zwischen
den beiden Ästen beim Treffpunkt in einem bestimmten Wertebereich liegen.
5.3 Vergleich zur implementierten Lösung
Bei der implementierten Lösung muss bei Änderungen in der Umwelt der aktuelle Plan
verworfen werden und eine komplette Neuplanung ist erforderlich. Dies ist der Fall,
wenn plötzlich Hindernisse in der Nähe des geplanten Pfades auftauchen. Die Stärken
des Anytime Dynamic A* -Algorithmus liegen im Vergleich darin, dass er die aktuelle
Lösung auch in solchen Situationen nicht komplett verwerfen muss, sondern es besteht
die Möglichkeit die Lösung schrittweise zu reparieren. Auch wenn Hindernisse verschwinden, kann das genutzt werden, um ggf. einen besseren Pfad ohne komplette Neuplanung
zu finden. Ein weiterer Vorteil des Anytime Dynamic A* -Algorithmus ist die mögliche
Vorgabe einer Zeitscheibe für eine Lösung. Diese Eigenschaft ist besonders für die Garantie der Rechtzeitigkeit in Echtzeitsystemen wichtig. Die Lösung ist möglicherweise
allerdings nur suboptimal. Wenn aber noch Zeit vorhanden ist, kann die Lösung entsprechend verbessert werden.
Bei dem Rapidly-Exploring Random Tree-Algorithmus handelt es sich um einen sehr
performanten zufallsbasierten Suchalgorithmus. Allerdings besteht nicht die Möglichkeit
den Pfad bei Änderungen in der Umwelt zu reparieren und eine Neuplanung ist erforderlich. Die Stärken liegen weiterhin bei der Planung in höherdimensionalen Suchräumen
sowie bei der Umsetzung der nicht-holonomen Randbedingungen. Allerdings nimmt z.B.
durch Hinzufügen der Rückwärtsfahrt die Komplexität bei der Implementierung erheblich zu und kann sich ggf. negativ auf die Performance auswirken.
Viele Teilprobleme bleiben bei der Implementierung eines Zonenverhaltens auch bei den
unterschiedlichen Ansätzen für die Pfadplanung erhalten. So ist die Verwendung der
47
5.3. VERGLEICH ZUR IMPLEMENTIERTEN LÖSUNG
vorgestellten Heuristiken auch bei den beiden alternativen Ansätzen denkbar, die Konvertierung des Pfades zum Plan bleibt identisch sowie das Missionshandling. Unterschiede ergeben sich aber ggf. beim Datenmodell (Paket model ) und bei den verwendeten
Datenstrukturen (Paket pathgenerator ).
48
6
Zusammenfassung und Ausblick
Mit dieser Arbeit wurde ein Konzept für ein Zonenverhalten autonomer Fahrzeuge erstellt und als ein Orocos Modul implementiert. Für die Beschleunigung bei Suche nach
einem Pfad, werden Heuristiken für die Reduzierung des Suchraumes eingesetzt. Statische Hindernisse werden beachtet und so Kollisionen bei der Planung vermieden. Für
Rangiermanöver kann Rückwärtsfahren als zusätzliche Dimension in die Planung eingebunden werden. Der generiert Pfad wird zu einem Plan konvertiert und optimiert, so
dass er von dem Controller abgefahren werden kann. Das Modul wurde in verschiedenen Szenarien in der Simulatonsumgebung und am Testfahrzeug getestet. Zudem wurde
ein weiteres Modul für die Visualisierung der expandierten Knoten und des geplanten
Pfades in der Simulationsumgebung entwickelt. Das FreeFormNavigation Modul kann
mit einer XML-Konfigurationsdatei in Kombination mit anderen Modulen verwendet
werden. Die Kommunikation mit den anderen Modulen erfolgt über die bestehenden
Schnittstellen. Es werden Methoden zur Verfügung gestellt, mit denen entweder manuell
über den TaskBrowser Pfade zu einer bestimmten Zielposition und -orientierung geplant
werden können oder ein Missionsmodus aktiviert werden kann, bei dem das Fahrzeug die
Checkpoints aus einem MDF nacheinander abfährt. Außerdem ist es möglich die Größe
und Position der Planungszone dynamisch zur Laufzeit zu konfigurieren.
In bestimmten Situationen ist es vorgesehen vom bereits vorhandenen Straßenverkehrsverhalten in das Zonenverhalten des FreeFormNavigation Moduls zu wechseln. Dadurch
ist es notwendig beide Module in einer gemeinsamen Konfiguration zu nutzen. Ein
möglicher Einsprungspunkt für das Zonenverhalten ist, wenn ein Eingangspunkt einer
Zone gemäß der Definition des RNDF erreicht wird und durch diese Zone geplant werden muss. Aber auch beim Auftreten so genannter Error Recovery Scenarios könnte
ein Wechsel zum Zonenverhalten stattfinden. Bei einer durch Stau blockierten Kreuzung
zum Beispiel ist eine weitere Planung mit dem Straßenverhalten nicht mehr möglich. Hier
kann selbständig eine Zone in der unmittelbaren Umgebung des Fahrzeuges aufgespannt
werden, durch das das Zonenverhalten das Fahrzeug navigiert bis wieder ein Straßen-
49
segment erreicht wird. Dann kann das Straßenverhalten wieder die weitere Navigation
übernehmen.
Um mögliche Kollisionen frühzeitig zu erkennen, könnte eine Vorwärtssimulation des
eigenen Fahrzeuges und aller bewegten Objekte verwendet werden. Dazu müssten die
Änderungen der Positionen und Orientierungen der entsprechenden Objekte analysiert
und die zukünftigen Bewegungen mit diesen Daten abgeschätzt werden. Die Zeit würde
dann als zusätzliche Dimension in die Planung einfließen. Demnach würde sich aber auch
die Komplexität der Planung erheblich steigern und weitere Problematiken bezüglich
der Performance ergeben. Als entsprechendes Verhalten könnten dann z.B. Pausen im
Plan eingebaut werden, um ein anderes Auto vorbeifahren zu lassen. Oder es könnten
bestimmte Gebiete bei der Planung ausgeschlossen bzw. schlecht bewertet werden, in denen es möglicherweise in Zukunft zu Überschneidungen der Pfade mit anderen Objekten
kommen wird.
Auf Grundlage der implementierten Lösung können auch andere Ansätze für die Pfadplanung umgesetzt werden, da viele Teilprobleme bei der Implementierung des Zonenverhaltens sehr ähnlich sind. Dazu gehören z.B. der Anytime Dynamic A* -Algorithmus
und die Rapidly-Exploring Random Trees, die im Kapitel 5 vorgestellt wurden. Durch die
Verwendung der alternativen Ansätzen kann ggf. die Performance des Zonenverhaltens
besonders in Gebieten mit vielen Hindernissen noch einmal verbessert werden.
50
Literaturverzeichnis
[1] Stanley: The Robot that Won the DARPA Grand Challenge, 2006
[2] Junior: The Stanford Entry in the Urban Challenge, 2008
[3] Autonomous Driving in Urban Environments: Boss and the Urban Challenge, 2008
[4] Maxim Likhachev, Dave Ferguson: Planning Long Dynamically-Feasible Maneuvers for Autonomous Vehicles, 2009
[5] Dmitri Dolgov, Sebastian Thrun, Michael Montemerlo, James Diebel: Practical
Search Techniques in Path Planning for Autonomous Driving, 2008
[6] Dave Ferguson and Anthony Stentz: Field D*: An interpolation-based path planner
and replanner, 2005
[7] Pieter Abbeel, Dmitri Dolgov, Andrew Y. Ng, Sebastian Thrun: Apprenticeship
Learning for Motion Planning with Application to Parking Lot Navigation, 2008
[8] Urban Challenge - Route Network Definition File (RNDF) and Mission Data File
(MDF) Formats, 2007
[9] Manfred Mitschke und Henning Wallentowitz: Dynamik der Kraftfahrzeuge,
Springer-Verlag 2004
[10] Dieter Zöbel: Echtzeitsysteme: Grundlagen der Planung, Springer-Verlag Berlin
Heidelberg 2008
[11] Heinz Wörn, Uwe Brinkschulte: Echtzeitsysteme, Springer-Verlag Berlin Heidelberg, 2005
[12] Ataeddin Ghassemi-Tabrizi: Realzeit-Programmierung, Springer-Verlag Berlin Heidelberg, 2000
[13] G. Görz, C.-R. Rollinger, J. Schneeberger: Handbuch der Künstlichen Intelligenz,
Oldenbourg Wissenschaftsverlag GmbH 2003
51
Literaturverzeichnis
[14] Th. H. Cormen, Ch. E. Leiserson, R. Rivest, C. Stein: Algorithmen - Eine
Einführung, Oldenbourg Wissenschaftsverlag GmbH 2007
[15] Ulrich Nehmzow: Mobile Roboter - Eine praktische Einführung, Springer-Verlag
2002
[16] Roland Stenzel: Steuerungsarchitektur für autonome mobile Roboter,
Rheinisch-Westfälische Technische Hochschule Aachen, Fakultät für Mathematik,
Informatik und Naturwissenschaften, 2002, http://darwin.bth.rwth-aachen.
de/opus3/volltexte/2002/408/pdf/Stenzel_Roland.pdf, Abruf: März 2011
[17] Markus Maurer, Christoph Stiller : Fahrerassistenzsysteme mit maschineller Wahrnehmung, Springer-Verlag Berlin 2009
[18] Hermann Winner,Stephan Hakuli,Gabriele Wolf: Handbuch Fahrerassistenzsysteme: Grundlagen, Komponenten und Systeme für aktive Sicherheit und Komfort,
Vieweg+Teubner 2009
[19] Werner Mansfeld: Satellitenortung und Navigation: Grundlagen und Anwendung
globaler Satellitennavigationssysteme, Friedr. Vieweg & Sohn Verlag/ GWV Fachverlage GmbH, Wiesbaden, 2004
[20] Ross A. Knepper and Alonzo Kelly: High Performance State Lattice Planning
Using Heuristic Look-Up Tables, 2006
[21] P. E. Hart, N. J. Nilsson, B. Raphael: A Formal Basis for the Heuristic Determination of Minimum Cost Paths, IEEE Transactions on Systems Science and
Cybernetics SSC4 (2), pp. 100–107, 1968.
[22] Maxim Likhachev , Dave Ferguson , Geoff Gordon , Anthony Stentz , and Sebastian
Thrun : Anytime Dynamic A*: An Anytime, Replanning Algorithm, 2005
[23] Steven M. LaValle: Rapidly-Exploring Random Trees: A New Tool for Path Planning, 1998
[24] Valgrind Homepage http://valgrind.org/, Abruf: März 2011
[25] Dokumentationen zum Orocos Real-Time Toolkit, http://www.orocos.org/rtt/
manuals, Abruf: März 2011
[26] Scott Meyers: Effektiv C++ programmieren, 2008
52
Abbildungsverzeichnis
1.1
Übersicht der Hardware vom Testfahrzeug MiG . . . . . . . . . . . . . .
5
2.1
2.2
2.3
Vergleich verschiedener Algorithmen [5] . . . . . . . . . . . . . . . . . . .
Ein- und ausgehende Kommunikation zum FreeFormNavigation-Modul .
Mission in einer Zone[8] . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
17
18
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
Übersicht aller Pakete und Klassen . . . . . . . . . . . . . . . . . .
Pfadplanung mit dem A*-Algorithmus . . . . . . . . . . . . . . . .
Übergänge bei Änderung der Orientierung gegen dem Uhrzeigersinn
Expandieren eines Knotens . . . . . . . . . . . . . . . . . . . . . . .
Rekonstruktion des Pfades . . . . . . . . . . . . . . . . . . . . . . .
Wendekreise an den Start- und Zielpunkten . . . . . . . . . . . . .
Expandierte Knoten mit dem euklidischen Abstand . . . . . . . . .
Expandierte Knoten mit der nicht-holomonen Heuristik . . . . . . .
Richtungswechsel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vorwärts- und Rückwärtseinparkmanöver . . . . . . . . . . . . . .
Visualisierung in der Simulation . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
21
24
25
27
29
31
32
33
34
36
37
39
4.1
4.2
Visualisierungstool KCacheGrind . . . . . . . . . . . . . . . . . . . . . .
Die Testfahrzeuge SpoB und MiG im Einsatz . . . . . . . . . . . . . . . .
43
44
5.1
5.2
Beispiel: Pfadplanung mit Anytime Dynamic A* [22] . . . . . . . . . . .
Beispiel für die Expansion eines RRTs [23] . . . . . . . . . . . . . . . . .
46
47
6.1
6.2
6.3
6.4
Pseudocode
Pseudocode
Pseudocode
Pseudocode
55
56
57
58
A*-Algorithmus [13] . . . . . . . . . . . . . . . . . .
RRT-Algorithmus [23] . . . . . . . . . . . . . . . .
Anytime Dynamic A*: Haupt-Funktion [22] . . . . .
Anytime Dynamic A*: ComputeOrImprovePath [22]
53
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abkürzungsverzeichnis
ABS
ACC
CAN-Bus
CPU
DARPA
ESC
FAS
GPS
HLUT
IMU
LIDAR
MDF
MiG
OCL
Orocos
RRT
RTT
RNDF
SpoB
WLAN
XML
Antiblockiersystem
Adaptive Cruise Control
Controller Area Network
Central Prozessing Unit
Defense Advanced Research Projects Agency
Electronic Stability Control
Fahrerassistenzsysteme
Global Positioning System
Heuristic Look-Up Table
Inertial Measurement Unit
Light Detection And Ranging
Mission Data File
Made in Germany
Orocos Component Library
Open Robot Control Software
Rapidly-exploring Random Tree
Orocos Real-Time Toolkit
Route Network Difinition File
Spirit of Berlin
Wireless Local Area Network
Extensible Markup Language
54
Anhang
6.1 A*-Algorithmus
Abbildung 6.1: Pseudocode A*-Algorithmus [13]
55
6.2. RRT-ALGORITHMUS
6.2 RRT-Algorithmus
Abbildung 6.2: Pseudocode RRT-Algorithmus [23]
56
6.3. ANYTIME DYNAMIC A*-ALGORITHMUS
6.3 Anytime Dynamic A*-Algorithmus
Abbildung 6.3: Pseudocode Anytime Dynamic A*: Haupt-Funktion [22]
57
6.3. ANYTIME DYNAMIC A*-ALGORITHMUS
Abbildung 6.4: Pseudocode Anytime Dynamic A*: ComputeOrImprovePath [22]
58