Implementierung eines Algorithmus zur LIDAR-basierten Exploration mit einer mobilen Roboterplattform
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Implementierung eines Algorithmus zur
LIDAR-basierten Exploration mit einer mobilen
Roboterplattform
Thanaancheyan Thavapalan
Bachelorarbeit
Martikelnummer 00089452
Fakultät Elektro- und Informationstechnik
Studiengang Elektro- und Informationstechnik
Erstprüfer Prof. Dr. Christian Pfitzner
Zweitprüfer Prof. Dr. Johann Schweiger
Ausgabedatum 25.11.2020
Abgabedatum 15.01.2021Danksagung
Hiermit möchte ich mich bei allen herzlich bedanken, die mich während der Verfassung meiner Bachelor-
arbeit unterstützt und motiviert haben und dabei auch die nötige Geduld mit mir hatten:
Besonderer Dank geht an Herrn Professor Dr. Christian Pfitzner, der mich sehr motiviert hat, mich
mit dieser Thematik zu beschäftigen. Darüber hinaus hatte er immer die nötige Zeit und Ruhe, wenn
es zu Schwierigkeiten kam, bei denen ich nicht mehr weitergekommen bin. Außerdem betreute er
nicht nur diese Bachelorarbeit, sondern unterstützte mich mit konstruktiver Kritik und hilfreichen
Verbesserungsvorschlägen bei der Erstellung dieser Arbeit.
Bei Herrn Professor Dr. Johann Schweiger möchte ich mich bedanken, der mir den Roboter zur Verfügung
gestellt hat und der sich bereit erklärte, mein Zweitkorrektor zu sein.
Bei meinen Freunden und bei meiner Familie möchte ich mich für die Hilfe und die Geduld bedanken.
Thanaancheyan Thavapalan
2Erklärung
Hiermit erkläre ich, dass ich die vorliegende Bachelorarbeit selbstständig verfasst habe. Dabei wurden
keine anderen als die angegebenen Quellen oder Hilfsmittel benutzt. Wörtliche und sinngemäße Zitate
wurden als solche gekennzeichnet.
Ingolstadt, den 15.01.2021 Thanaancheyan Thavapalan
3Abkürzungsverzeichnis
Formelzeichen:
Abkürzung Bedeutung Einheit
d Distanz m
DC Gleichstrom V
λ Wellenlänge nm
o Orientierung mit den Rotationswinkeln φ, θ und ψ
p Punkt im dreidimensionalen Raum mit x,y und z
P Punktwolke
q Quaternion mit einem Realteil w und drei Imaginärteilen i, j und k
R 3x3 Rotationsmatrix
s Standort mit Punkt p und Orientierung o
t Translationsvektor
T Transformationsmatrix
t Zeit s
4Abkürzungen:
Abkürzung Bedeutung
D Dimension
GUI Graphical User Interface
LIDAR Light Detection And Ranging
PNG Portable Network Graphics
ROS Robot Operation System
SLAM Simultaneous Localization And Mapping
TCP / IP Transmission Control Protocol / Internet Protocol
TF TransForm (ROS-Paket)
USB Universal Serial Bus
(W-)LAN (Wireless-) Local Area Network
XML Extensible Markup Language
YAML YAML Ain’t Markup Language
5Inhaltsverzeichnis
1 Einleitung 8
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Konvention dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Grundlagen 11
2.1 Mobile Robotik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Mathematische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Punkte und Orientierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Koordinatensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Lokalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Problemdynamik und -unsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Umweltwissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Kartierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Pfadplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1 Dijkstra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2 A-Star . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.1 ROS-Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.2 ROS-Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.3 ROS-Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.4 ROS-Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5 ROS-Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.6 ROS-Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.7 ROS-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.8 ROS-Launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Verwendete ROS-Pakete 22
3.1 Transformationsbäume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 STDR-Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 STDR-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 STDR-Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 STDR-Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Gmapping und Hector SLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Navigation Stack und Move Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Sensorquellen und -transformationen . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Robotersteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Karten Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.4 Die 2D-Kostenkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6Inhaltsverzeichnis
3.4.5 Robotersteuerung (Base Local Planner) . . . . . . . . . . . . . . . . . . . . . . 27
4 Implementierung des thi exploration node 28
4.1 Aufbau einer Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Berechnung der Nachbarpixel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Frontierpixel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Pixelarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Gruppieren der Frontiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 Koordinatentransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 Orientierung eines Pixels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Auswahl eines Zielfrontiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 Experimente und Ergebnisse 36
5.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Vorbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2 Start einer Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.3 Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Realer Roboter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.2 Vorkonfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.3 Start des Roboters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.4 Testen des Roboters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Ausblick 48
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Anhang 50
7.1 Verwendete Programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2 Anlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
71 Einleitung
1.1 Motivation
In seiner Historie ist der Mensch stets durch seine Neugier geprägt. Dabei erkundet er aktiv unbekannte
Gebiete und sammelt Informationen über die explorierte Umgebung. Aus diesen Informationen wird
dann eine Karte erstellt, damit eine spätere Orientierung wieder möglich ist und sichergestellt wird,
dass die Informationen über das Gebiet gespeichert sind. Die Karten enthalten dann charakteristische
Bezugspunkte, wie z.B. Wege, Vegetation und Hindernisse. Im Laufe der Zeit wurden diese Karten
verbessert, wie z.B. mit den Höhenprofilen eines Bergs. Wenn nun ein mobiler Roboter mithilfe der
erstellten Karten navigieren soll, muss die Karte davor aktualisiert worden sein. Ansonsten ist der
Roboter nicht imstande fehlerfrei zu navigieren. Jedoch möchte der Mensch auch, dass eine mobile
Roboterplattform selbstständig unbekannte Umgebungen exploriert, weil die Umgebung gefährlich sein
könnte oder weil es für den Menschen schwierig werden kann, gewisse Umgebungen zu erkunden. Bei
einer solchen Exploration hat ein mobiler Roboter die Möglichkeit sich von den genannten Begrenzungen
zu befreien. Für einen mobilen Roboter bedeutet eine Exploration, sich durch eine unbekannte Umgebung
zu bewegen, während eine Karte erstellt wird, die für eine spätere Navigation verwendet werden kann.
Bei einer Exploration ist es immer wichtig zu wissen, welche Informationen es über die Umgebung
gibt und wohin navigiert werden soll, um möglichst viele und neue Informationen zu erhalten. Eine
gute Explorationsstrategie ist es, eine Karte zu erstellen, die möglichst viel aus der Umgebung in einer
vernünftigen Zeit abspeichern kann. Ein Ansatz für eine Explorationsstrategie ist die Erkennung der
sogenannten frontiers.
Frontier Exploration
Die sogenannte frontier Exploration basiert auf der Erkennung der Grenzen zwischen bekanntem und
unexploriertem Gebiet. Diese Grenzen werden als sogenannte frontiers bezeichnet. Der zentrale Ansatz
der frontier basierten Exploration ist es, sich zur Grenze zwischen bekanntem und unbekanntem Gebiet
zu bewegen, um die meisten Informationen über die neue Umgebung zu erhalten. Wenn eine mobile
Roboterplattform zu einem frontier fährt, dann kann die Plattform den unexplorierten Bereich erfassen
und die neuen Informationen seiner aktuellen Karte hinzufügen. Das Ergebnis dieser Explorationsstrategie
ist es, dass die erfasste Umgebung vergrößert wird und die Grenzen zwischen bekanntem und unbekanntem
Gebiet nach hinten verschoben werden. Wenn sich der mobile Roboter stets zu den nachfolgenden frontiers
bewegt, kann er sein Wissen über die Umwelt stets erweitern. So kann eine mobile Roboterplattform
unter der Verwendung der frontier Exploration jedes zugängliche Gebiet erkunden.
1.2 Konvention dieser Arbeit
Im Rahmen dieser Arbeit wird eine eigene Formatierung verwendet. Die runden Klammern mit einer Zahl
(0.1) verweisen auf eine Abbildung, einen Abschnitt oder eine Tabelle. Die eckigen Klammern mit einer
Zahl [0] verweisen auf eine Quelle im Literaturverzeichnis. Ein fettgedruckter Großbuchstabe M stellt eine
81 Einleitung
Matrix dar und ein fettgedruckter Kleinbuchstabe v stellt einen Vektor dar. So werden auch englische
Fachbegriffe innerhalb eines Satzes benutzt, da es sich bei den Begriffen zum Teil, um Eigennamen
handelt. Darüber hinaus sind der implementierte Quellcode sowie die erstellten Dateien, die im Git-
Repository zur Verfügung gestellt werden, in englischer Sprache kommentiert. Bei den physikalischen
Größen und Formeln gelten die SI-Basiseinheiten, wenn keine andere Einheit angegeben wurde.
1.3 Ziel der Arbeit
Kartierung
Lokalisierung Laserdaten Laserscanner
(Gmapping/Hector SLAM) Sick nanoScan3
Karte
Roboter
Exploration (C++-Datei: ( STDR-Simulator/
thi exploration node) Pioneer 3-AT )
Zielkoordinate Geschwindigkeit
Pfadplanung
/Bewegungssteuerung
(Move Base)
Abbildung 1.1: Klassendiagramm Exploration
Zunächst soll eine Simulation mit einem Roboter, an dem ein Laserscanner montiert ist, starten. Der
Laserscanner liefert wiederum Laserdaten an die Kartierung, die wiederum eine Karte erstellt und den
Roboter mit dem Laserscanner in dieser Karte lokalisiert. Diese Karte wird in einer Explorationsdatei
verarbeitet und es soll eine Zielkoordinate festgelegt werden, die der Roboter anfahren soll. Damit diese
Zielkoordinate angefahren werden kann, wird sie an die Pfadplanung und Bewegungssteuerung geschickt.
Die Pfadplanung ist für die Navigation des Roboters verantwortlich. Für eine Bewegungsteuerung wird
dann ein Geschwindigkeitsvektor an die Simulation geschickt. Damit geht dieser Regelzyklus, der in der
Abbildung 1.1 dargestellt wird, wieder von vorne los. Das Hauptziel dieser Arbeit ist es, dass mithilfe des
implementierten Programms eine mobile Roboterplattform selbstständig exploriert.
1.4 Aufbau der Arbeit
Die Bachelorarbeit ist folgendermaßen gegliedert:
• Kapitel 2 gibt einen Überblick über die Grundlagen, die für das Verständnis der Arbeit hilfreich
sind.
91 Einleitung
• Kapitel 3 erklärt den Aufbau und die Funktionsweise der verwendeten Softwarepakete innerhalb
von ROS.
• Kapitel 4 erklärt die Funktionsweise des Programms, das im Rahmen dieser Arbeit implementiert
wurde.
• Kapitel 5 beinhaltet die Simulationen, die durchgeführt wurden, und die Durchführung eines ersten
Tests an einem Roboter.
• Kapitel 6 fasst nochmal die wesentlichen Aspekte der Arbeit zusammen und stellt einen Ausblick
dar.
102 Grundlagen
Dieses Kapitel enthält die Grundlagen, die für das Verständnis dieser Arbeit relevant sind.
2.1 Mobile Robotik
Die mobile Robotik ist eines der bedeutendsten Teilgebiete der allgemeinen Robotik. So befindet sich
beispielsweise ein Roboterarm in der Industrierobotik bei der Fertigung eines Automobils stationär in einem
strukturierten Umfeld und erledigt meistens immer dieselbe Aufgabe. Im Gegensatz dazu soll sich eine
mobile Roboterplattform in einer unexplorierten Umgebung bewegen können und eigenständig Aufgaben
erfüllen. Dabei müssen bei der Planung der Bewegungen unterschiedliche Faktoren, wie beispielsweise die
Batterielaufzeit und Bodenbeschaffenheit, berücksichtigt werden. Damit ein mobiler Roboter mit seiner
Umgebung interagieren kann, werden verschiedene Sensoren verwendet. In den folgenden Abschnitten
werden die wichtigsten Themengebiete der mobilen Robotik genauer erläutert.
2.2 Mathematische Grundlagen
2.2.1 Punkte und Orientierungen
Damit sich ein mobiler Roboter in seiner Umgebung orientieren kann, werden Koordinatensysteme
definiert und verwendet. Ein Punkt im dreidimensionalen Koordinatensystem wird mithilfe eines Vektors
p = (px py pz )T definiert. Dabei beschreibt dieser Vektor die relative Position des Punktes vom
Koordinatenursprung. Eine beliebige Anzahl von Punkten wird als eine Punktewolke P bezeichnet.
Da in der Literatur (z.B. [1], [2] und [3]) als auch in ROS (siehe Kapitel 2.7) ein rechtshändiges
Koordinatensystem verwendet wird, wird für diese Arbeit ebenfalls ein solches Koordinatensystem
festgelegt, das mit den Achsen x, y und z aufgespannt wird. Dabei zeigt die positive x-Achse in
die Richtung des Roboterantriebs. Vom Mittelpunkt des Roboters liegt die positive y-Achse in der
Fahrtrichtung links. Die Höhe wird durch die positive z-Achse definiert. Darüber hinaus können in der
mobilen Robotik mithilfe der Eulerwinkel Drehungen realisiert und Orientierungen festgelegt werden. Die
Winkel φ, θ und ψ geben jeweils eine Rotation um die x-, y- und z-Achse an.
2.2.2 Koordinatensysteme
Weil an einem mobilen Roboter meist verschiedene Sensoren und Aktoren angebracht sind, die wie-
derum unterschiedliche Koordinatensysteme verwenden, müssen die Systeme aufeinander abgestimmt
werden, damit der Roboter auch fehlerfrei funktioniert. Im folgenden Abschnitt werden die wesentlichen
Koordinatensysteme zusammengefasst:
112 Grundlagen
Roboterkoordinatensystem
Der Ausgangspunkt des Roboterkoordinatensystems liegt in der Mitte des Roboters. Es bildet die
Grundlage für alle Aktor- und Sensorkoordinatensysteme, die an einem mobilen Robotor befestigt sind.
Sensorkoordinatensystem
Da jeder Sensor sein eigenes Koordinatensystem benutzt, muss eine Anpassung erfolgen. Wenn sich
beispielsweise ein Laserscanner etwas hinter dem Zentrum des mobilen Roboters befindet, dann muss
dem Datensatz ein Offset hinzugefügt werden. Dieser berücksichtigt, dass der vorderste Punkt des
Roboters sich näher am Hindernis befindet als der Laserscanner, und somit wird gewährleistet, dass
der Roboter vorzeitig einem Hindernis ausweicht. Des Weiteren muss beachtet werden, dass es sowohl
dreidimensionale Sensoren, wie z.B. Laserscanner, als auch zweidimensionale Sensoren, wie z.B. Kameras,
gibt. Bei zweidimensionalen Sensoren fällt eine Achse weg.
Aktorkoordinatensystem
Ähnlich wie bei den Sensoren besitzt auch jeder Aktor eines mobilen Roboters ein Koordinatensystem.
Ein Beispiel für ein Aktorkoordinatensystem ist ein Rad, das durchgehend rotieren muss. Auch bei den
Aktoren muss eine Anpassung erfolgen, damit sie rechtzeitig reagieren können, wie z.B. beim Ausweichen
von Hindernissen.
Weltkoordinatensystem
Das Weltkoordinatensystem hat seinen Ursprung an der Position, an dem der mobile Roboter hochgefahren
wurde. Für einen mobilen Roboter ist es essentiell diesen Standort zu kennen, da er sich in einer
unbekannten Umgebung zurechtfinden muss und da er den Ursprung als Orientierungspunkt für eine
Lokalisierung benutzt.
2.2.3 Transformationen
Es gibt zwei Möglichkeiten, eine Transformation eines Punktes durchzuführen:
Translation
Die Translation ist der simpelste Fall einer Transformation. Dabei wird auf einen Punkt p ein Translati-
onsvektor t aufaddiert und dabei entsteht wiederum ein neuer Punkt p’:
px + tx
p’ = py + ty (2.1)
pz + tz
122 Grundlagen
Rotation
Eine weitere Art der Transformation ist die Rotation. Sie wird benutzt, damit ein Punkt sich um eine
oder mehrere Achsen dreht, und sie wird durch eine allgemeine Rotationsmatrix definiert:
r11 r12 r13
R3x3 = r21 r22 r23 (2.2)
r31 r32 r33
1 0 0 cos(θ) 0 sin(θ)
Rx (ψ) = 0 cos(ψ) − sin(ψ) (2.3) Ry (θ) = 0 1 0 (2.4)
0 sin(ψ) cos(ψ) − sin(θ) 0 cos(θ)
cos(φ) − sin(φ) 0
Rz (φ) = sin(φ) cos(φ) 0 (2.5)
0 0 1
Wenn man alle drei Rotationsmatrizen multipliziert, erhält man eine neue Rotationsmatrix R3x3 =
Rx,y ,z (ψ, θ, φ), die eine gleichzeitige Rotation um alle drei Achsen ermöglicht:
cos(φ) cos(θ) cos(φ) sin(θ) sin(ψ) − sin(φ) cos(ψ) cos(φ) sin(θ) cos(ψ) + sin(φ) sin(ψ)
R3x3 = sin(φ) cos(θ) sin(φ) sin(θ) sin(ψ) + cos(φ) cos(ψ) sin(φ) sin(θ) cos(ψ) − cos(φ) sin(ψ)
− sin(θ) cos(θ) sin(ψ) cos(θ) cos(ψ)
(2.6)
Da es bei diesen Rotationsmatrizen zu Rundungsfehlern kommen kann, wird die Orthogonalität nicht mehr
gewährleistet. Um beliebig viele und fehlerfreie Rotationen durchführen zu können, werden Quaternionen
verwendet. Ein Quaternion q verhält sich ähnlich wie eine komplexe Zahl und hat auch einen Realteil w
und Imaginärteil i. Die Rechenregeln sind ebenfalls wie bei den komplexen Zahlen gleich. Jedoch besteht
der wesentliche Unterschied darin, dass ein Quaternion um zwei weitere Imaginärteile j, k erweitert
wird:
q = w + ix + jy + kz (2.7)
Dabei stellen die Imaginärteile i, j und k eine Rotation um die jeweiligen Achsen x,y und z dar. Der
Realteil w gibt den Radius der Drehung um die Achse an. Quaternionen werden beispielsweise für die
Orientierung eines mobilen Roboters in Move Base (Abschnitt 3.2) verwendet.
Zusammenfassung
Nun werden die beiden Transformationsarten mithilfe folgender Gleichung zusammengefasst:
p’ = R · p + t (2.8)
132 Grundlagen
Jedoch ist es in der Praxis schwierig diese Zusammenfassung auszudrücken, da es sich bei der Translation
nicht um eine Matrixmultiplikation handelt. Deswegen werden homogene Koordinaten verwendet, damit
eine einheitliche Repräsentation aller Transformationsarten gewährleistet werden kann. Dazu wird die
Rotationsmatrix R und der Translationsvektor t in eine Transformationsmatrix T hinzugefügt. Dabei wird
die Hauptdiagonale mit einer 1 ergänzt und die restliche untere Zeile mit einem Nullvektor befüllt:
R3x3 t
T= (2.9)
0 1
Dank der Transformationsmatrix können die Koordinaten eines Punktes mit geringem Aufwand in ein
anderes Koordinatensystem umgewandelt werden. Darüber hinaus wird der Translation eine 1 hinzugefügt,
um eine Translation ebenfalls mit einer einfachen Matrizenmultiplikation berechnen zu können:
px
py
p=
pz (2.10)
1
Durch die Erweiterung einer zusätzlichen Dimension können die Translation und die Rotation in eine
homogene Transformationsmatrix zusammengeführt werden:
px 0 r11 r12 r13 tx px
py 0 r21 r22 r23 ty py
pz 0 r31 r32 r33 tz · pz
= (2.11)
1 0 0 0 1 1
Nun können mithilfe der Position und der Orientierung ein Standort s des mobilen Roboters in einem
Koordinatensystem angegeben werden. Diese beinhaltet alle sechs Freiheitsgrade für einen Punkt p und
Orientierung o:
tx
ty
t tz
s= = (2.12)
o φ
θ
ψ
2.3 Navigation
Einer der wichtigsten Eigenschaften einer mobilen Roboterplattform ist es, in einer dynamischen Um-
gebung zu navigieren. Dafür muss die Betriebsfähigkeit des Roboters stets gewährleistet werden. Das
bedeutet, dass gefährliche Situationen wie beispielsweise Kollisionen zu verhindern sind und dass geeig-
nete Betriebsvoraussetzungen, wie z.B. Temperatur, Witterungsverhältnisse und Bodenbeschaffenheit,
beizubehalten sind. Wenn der mobile Roboter zusätzlich auch noch Aufgaben zu erfüllen hat, dann muss
er imstande sein, sich zu orientieren und schließlich zu navigieren. Der Begriff Navigation wird in der
mobilen Robotik vom Autor im Werk [4] folgendermaßen untergliedert:
1. Lokalisierung des Roboters (Kapitel 2.4)
142 Grundlagen
2. Erstellung einer Karte sowie deren Interpretation (Kapitel 2.5)
3. Planung von Routen (Kapitel 2.6)
Das Bezugssystem, welches letztendlich der Referenzpunkt für die Navigation ist, stellt einen wesentlichen
Bestandteil für jede der drei Navigationskomponenten dar. In dieser Arbeit wurde in Kapitel 2.2 das
rechtshändige Koordinatensystem als Bezugssystem festgelegt. Für alle drei genannten Vorgänge innerhalb
des Bezugssystem werden alle Standorte als kartesische Koordinaten dargestellt.
2.4 Lokalisierung
Eine Lokalisierung im Bereich der mobilen Robotik bedeutet, dass ein Robotersystem über die Kompetenz
verfügt, die Position eines wichtigen Merkmals innerhalb eines Bezugssystems zu ermitteln. Dabei
spielt die Selbstlokalisation des Roboters in der Navigation eine zentrale Rolle, da das Robotersystem
selbst immer wissen muss, wo es sich gerade befindet. Aus der Selbstlokalisierung resultiert stets die
gegenwärtige Position der mobilen Roboterplattform. Sowohl die aktuellen regionalen als auch vorher
aufgezeichnete Informationen können abgespeichert und für eine Lokalisierung verwendet werden. Damit
sich ein Roboter überhaupt lokalisieren kann, braucht er Sensoren, wie z.B einen Laserscanner. Für
verschiedene Aufgabenstellungen werden unterschiedliche Ansätze gewählt, um die bestmögliche Lösung
zu erzielen. Die Lokalisierung wird vom Autor im Werk [5] in unterschiedliche Kriterien untergliedert.
2.4.1 Problemdynamik und -unsicherheit
Die Grundschwierigkeit bei der Positionsbestimmung wird mit steigender Schwierigkeitsstufe in drei
Bereiche vom Autor [5] unterteilt:
In der einfachsten Stufe handelt es sich lediglich um eine Berichtigung, bei der ein bekannter Standort
nachvollzogen werden muss, sodass es ausschließlich einer Korrektur bedarf. Wenn jedoch die Anfangsbe-
dingungen nicht korrekt festgelegt wurden oder die Abweichungen durch unvorhergesehene Ereignisse zu
groß sind, kann eine adäquat funktionierende Lokalisierung nicht mehr gewährleistet werden. Die nächste
Stufe besteht aus einer globalen Lokalisierung, bei der ohne Informationen eine Selbstlokalisierung des
mobilen Robotersystems erfolgen muss. Die schwierigste Stufe ist die sogenannte Relokalisierung, bei
der eine fehlerhafte und gegenwärtige Position erkannt werden muss und der mobile Roboter sich neu
lokalisieren muss. Ein weiterer Faktor bei der Problemdynamik ist auch die Struktur der Umwelt. So
ist beispielsweise ein langer Gang für eine Lokalisierung von größerem Vorteil als eine Umgebung mit
Verzweigungen oder Schleifen.
2.4.2 Umweltwissen
Beim Umweltwissen gibt es zwei abhängige Dimensionen. Einerseits der Bekanntheitsgrad der Umwelt
und andererseits die Dynamik der Umweltveränderungen. Bei einer Umgebung mit hoher Dynamik ist
es vorteilhaft, wenn die Lokalisierung imstande ist, zwischen den veränderlichen und statischen Teilen
zu differenzieren. Der größte Teil der Lokalisierungsmethoden geht von einer statischen Umgebung aus
und berücksichtigt den dynamischen Anteil als eine zunehmende Unsicherheit oder als Fehlmessung der
Sensoren.
152 Grundlagen
2.5 Kartierung
Für eine erfolgreiche Lokalisierung führt ein mobiler Roboter eine Kartierung durch. In der Literatur
(wie z.B. in [4] und [6]) wird unter einer Kartierung verstanden, die Fähigkeit eines mobilen Roboters
eine Umweltkarte zu erstellen. In einer Umweltkarte wird die reale Umgebung eines Roboters auf ein
internes Bezugssystem repräsentiert. Zur Kartierung gehört nicht nur die Kompetenz, eine Karte zu
erstellen, sondern auch Informationen über erforschtes Gebiet abzuspeichern. Darüber hinaus muss ein
mobiler Roboter ebenfalls imstande sein, mit seiner erstellten Karte zu interagieren, wie z.B. Positionen
anzufahren, und diese dabei auch zu interpretieren, wie z.B. Hindernisse zu erkennen. Um eine solche
Karte zu erstellen, benutzt ein Roboter vielfältige Sensoren wie z.B. einen Laserscanner. Nun müssen die
verschiedenen Sensordaten, die unterschiedliche Informationen beinhalten, in eine geeignete Form gebracht
werden, um einerseits möglichst viele Informationen zu speichern und andererseits den Speicherbedarf
auf ein Minimum zu reduzieren. Dafür können in der mobilen Robotik zweidimensionale Gitterkarten
verwendet werden, in der Sensorinformationen in Gitterzellen abgespeichert werden.
2.6 Pfadplanung
Eine Planung von Routen stellt grundsätzlich eine Erweiterung der Lokalisierung dar, weil die mobile
Roboterplattform sowohl seine aktuelle Position als auch die gewünschte Zielposition innerhalb des
gleichen Bezugssystems bestimmen muss. Das Ziel der Pfadplanung besteht darin, die kürzeste Route zu
finden. Damit dieses Problem modelliert werden kann, wird ein Netzplan verwendet. Die verschiedenen
Koordinaten, die ein mobiler Roboter anfahren kann, werden als Knoten und ein Weg zwischen zwei
Koordinaten wird als Kante dargestellt. Die Eigenschaften eines Weges werden mithilfe eines Labels
an einer Kante beschrieben. Diese Eigenschaften können beispielsweise die Distanz, die Steigung oder
Hindernisse sein. Darüber hinaus müssen die Merkmale des mobilen Roboters, wie z.B. die Batterielaufzeit
oder die Maße, als Kriterien berücksichtigt werden. Üblicherweise gibt es mehrere Möglichkeiten, um
vom Start zum Ziel zu gelangen. Die Aufgabe der Pfadplanung ist es unter diesen Kriterien eine optimale
Route zu finden. Sobald eine Lösung gefunden wurde, kann es sein, dass diese nur für eine kurze Zeit
gültig ist, da sich die Bedingungen dynamisch ändern können. Deswegen müssen diese Informationen
immer wieder aktualisiert werden und somit auch die Routen neu berechnet werden. Die unterschiedlichen
Informationen (Distanz, Akkulaufzeit, etc.), die für das Routingverfahren relevant sind, werden in einem
Wert zusammengefasst. Je niedriger dieser Wert ist, desto kürzer ist der Weg. Mithilfe dieser Abstraktion
kann der Dijkstra-Algorithmus den kürzesten Weg berechnen.
2.6.1 Dijkstra
Der Dijkstra-Algorithmus wird anhand eines Beispiels (Abbildung 2.1) aus der Literatur [7] erklärt.
Initialisierung
Zu Beginn des Algorithmus werden die Knoten initialisiert, indem alle Knoten außer dem Startknoten
A als unbesucht gekennzeichnet werden. Jeder Knoten erhält einen Label, das die Pfadkosten vom
Startknoten zum aktuellen besuchten Knoten und den Vorgängerknoten auf dem Pfad beinhaltet. Die
Pfadkosten aller Knoten werden am Anfang auf unendlich gesetzt. Zusätzlich wird der Vorgänger jedes
Knotens auf Null gesetzt. Beim Startknoten jedoch werden die Pfadkosten auf Null gesetzt und Vorgänger
des Startknoten ist er selbst. Die folgenden Iterationsschritte sind in der Abbildung 2.2 dargestellt.
162 Grundlagen
1
A B 1
4 2
3 C
D
3 6
2
7 5
E F G
Abbildung 2.1: Dijkstra Initialisierung (Quelle: [7])
1. Iteration (grün)
Anschließend folgt der erste Iterationsschritt, bei dem die Pfadkosten zu den Nachbarknoten berechnet
werden. Die Nachbarknoten von A sind B, D und E. Nun wird für jede dieser Nachbarknoten ein Label mit
den Pfadkosten und den Namen des Vorgängerknotens erstellt. So erhält der Knoten D in diesem Beispiel
das Label (4,A), da sein Vorgänger A ist und die Pfadkosten 4 betragen. Da in einem Iterationsschritt
stets das Minimum der Pfadkosten gewählt wird und der Wert der Pfadkosten größer gleich Null sein
muss, kann das Minimum nur ein Nachbarknoten sein. In diesem Fall ist es der Knoten B, der als besucht
gekennzeichnet wird. Der Knoten A ist nun abgeschlossen.
2. Iteration (rot)
Ausgehend vom Knoten B wird im zweiten Iterationsschritt für die Knoten A und B jeweils der kürzeste
Pfad zu den Nachbarknoten C, D und E berechnet. Auch hier werden wieder die Minima der Pfadkosten
zu den Nachbarn ausgewählt. So erhält der Knoten D ein neues Label (3,B), da der kürzeste Weg von
A nach D über B führt und die Gesamtpfadkosten von 3 hat. Nun wird der Knoten C besucht, da er
insgesamt die kleinsten Kosten von 2 hat.
3. Iteration (hellblau)
Ausgehend von Knoten C werden die Nachbarn berechnet. Der Knoten C hat nur Knoten G als Nachbar.
Die Informationen werden nun aktualisiert. Als Nächstes kann entweder der Knoten D oder E besucht
werden, weil sie die gleichen Pfadkosten besitzen und kleiner sind als die Pfadkosten zu Knoten G. Nun
wird Knoten E besucht.
4. Iteration (orange)
Der Nachbar vom Knoten E ist Knoten F. Da die Pfadkosten zu F größer sind als zu Knoten D, wird
Knoten D nun besucht.
172 Grundlagen
5. Iteration (lila)
Die Nachbarn vom Knoten D sind F und G. Da der Knoten F noch nicht besucht wurde, wird noch
überprüft, ob sich kürzere Pfadkosten ergeben.
6. Iteration (schwarz)
Da sich keine kürzeren Pfadkosten ergeben, weiß der Knoten A, dass er den Zielknoten G über B und D
erreicht. Die abgeschlossen Iterationen des Startknotens A zum Zielnoten werden in der Abbildung 2.2
dargestellt.
1
A B 1
4 2
3 C
D
3 6
2
7 5
E F G
Abbildung 2.2: Dijkstra Iterationen
2.6.2 A-Star
Der A-Star-Algorithmus ist eine Erweiterung des Dijkstra-Algorithmus, da er eine zusätzliche Heuristik
verwendet. Dabei wird als Heuristik meistens die euklidische Distanz bzw. die Luftlinie zum Zielknoten
benutzt. Diese Größe muss bei der Berechnung der Kosten berücksichtigt werden. Darüber hinaus
ist der A-Star-Algorithmus mindestens genauso schnell wie der Dijkstra-Algorithmus, jedoch ist der
A-Star-Algorithmus meistens schneller als der Dijkstra-Algorithmus, wodurch Rechenzeit gespart werden
kann. Das Beispiel 2.1 wird nun um eine euklidische Distanz erweitert und es erfolgen die Iterationen,
wie in der Abbildung 2.3 dargestellt:
1. grün: Knoten B mit den geringsten Kosten (29)
2. orange: Knoten D mit den geringeren Kosten (32,5) als Knoten C (34)
3. braun: Knoten E mit den geringeren Kosten (34) als Knoten G über D (35,5)
4. rot: Knoten C mit den geringeren Kosten (40) als Knoten F über E (47)
5. lila: Knoten G über D mit den geringeren Kosten (35,5) als Knoten G über D (47)
Der A-Star-Algorithmus ist in diesem Beispiel um eine Iteration schneller als der Dijkstra-Algorithmus,
da nicht zwangsläufig jeder Knoten besucht werden muss.
182 Grundlagen
1
A B
h=17 h=11 1
4 2
C
3 D h=4
h=11 3 6
2
E 7 5
h=14 F F
h=6 h=0
Abbildung 2.3: Astar Iterationen
2.7 ROS
Das Robot Operating System (ROS) ist ein Robotik-Framework, welches für mobile Roboterplattformen
unterschiedliche Klassen und Programme zur Verfügung stellt, sodass für jeden Roboter nicht immer
wieder alles neu entwickelt werden muss. Die Hauptaufgabe von ROS ist es, zwischen den einzelnen
Programmbausteinen zu vermitteln, da die Programme über ein Nachrichtensystem, dem sogenannten
ROS-Master, miteinander kommunizieren. Der Vorteil dieser Architektur besteht darin, dass, wenn es in
einem Programm zu einem Fehler kommt, nicht zwangsläufig das gesamte ROS-System abstürzt. Hierbei
erfolgt die Übertagung von Nachrichten durch das TCP/IP Protokoll über LAN bzw. WLAN. Darüber
hinaus verwendet ROS das sogenannte publish- und subscribe-Prinzip. Es gibt also ROS-Programme, die
Nachrichten publizieren, und ROS-Programme, die Nachrichten abonnieren.
2.7.1 ROS-Package
Ein ROS-Package bildet den einfachsten Baustein innerhalb der ROS-Umgebung. In einem Package
können beispielsweise ROS-Knoten, Programme, Bibliotheken und Konfigurationsdateien enthalten sein.
Ein fertiges Package hat das Ziel, eine Funktion bzw. Aufgabe zu erfüllen. Dabei sollte es möglichst
übersichtlich und strukturiert aufgebaut sein, damit eine hohe Wiederverwendbarkeit bzw. Weiterent-
wicklung gewährleistet wird. Eine häufige Fehlerursache beim Erstellen von ROS-Packages ist es, dass
die CMakeLists.txt nicht konfiguriert wurde, während Dateien bereits definiert sind. Wenn beispiels-
weise ein Programm in der Programmiersprache C++ geschrieben wurde, muss in der CMakeLists.txt
folgender Befehl noch ergänzt werden: add executable (mein programm src/ paket name/mein.cpp).
ROS-Programme suchen immer zuerst nach der package.xml-Datei, um Abhängigkeiten aufzulösen oder
zur Laufzeit benötigte Programme zu starten.
2.7.2 ROS-Master
Der ROS-Master ist wie ein Vermittler, der allen ROS-Programmen die notwendigen Informationen
sendet, damit eine Verbindung zwischen den richtigen Knoten über TCP/IP hergestellt wird. Wenn ein
Knoten gestartet wird, wird zunächst die IP-Adresse des Masters abgefragt. Anschließend wird eine
Verbindung mit dem Master aufgebaut, um ihm mitzuteilen, ob ein Knoten publizieren oder abonnieren
möchte. Wenn davor noch kein Master mithilfe den Befehlen roscore oder roslaunch gestartet wurde,
192 Grundlagen
kommt es zu einem Fehler. Sobald die Knoten miteinander verbunden sind, können diese über den
Master untereinander Nachrichten austauschen. Die Knoten sind dann lose verbunden, d.h., dass ein
Knoten jederzeit beendet werden kann und ein neuer Knoten hinzugefügt werden kann, ohne dass das
Gesamtsystem beeinflusst wird.
2.7.3 ROS-Nodes
Ein Node ist eine Instanz eines ausführbaren Programms, d.h., dass ein Programm mehrmals gleichzeitig
gestartet werden kann, indem verschiedene Namen beim Aufruf verwendet werden. Die Programme
innerhalb der ROS-Architektur werden mithilfe des Startbefehls rosrun aufgerufen und werden beim
Start zu einem vollwertigen Knoten gemacht. Der ROS-Master sorgt dann dafür, dass ein Knoten
erreichbar ist und mit anderen Nodes kommunizieren kann. Sobald eigene Knoten programmiert werden,
können diese grundsätzlich Topics und Actions implementiert werden, welche gleichzeitig und mehrfach
in einem Knoten vorkommen können. Ein Beispiel für einen ROS-Node ist die implementierte Datei
thi exploration node.cpp (Kapitel 4).
2.7.4 ROS-Topics
Ein Kommunikationsvorgang zwischen Nodes läuft ab, indem ein Knoten ein oder beliebig viele Topics
abonnniert oder publiziert. Ein Topic ist ein Thema, unter dem es Nachrichten zu senden oder zu
empfangen gibt. Nachdem ein Topic abonniert wurde, entsteht ein Nachrichtenfluss vom publizierenden
zum abonnierenden Knoten. Ein Topic kann beispielsweise eine Karte sein.(Kapitel 3.3).
2.7.5 ROS-Messages
Die ROS-Messages sind Datenströme, die mindestens zwischen zwei Knoten ausgetauscht werden.
Sie werden in sogenannten msg-Dateien definiert. Diese Nachrichten können sowohl aus primitiven
Datentypen als auch aus Datenstrukturen bestehen. Der Datenfluss erfolgt nur unidirektional.
2.7.6 ROS-Action
Die ROS-Actions werden verwendet, um zeitintensive Aufgaben zu lösen. Dafür stellt das ROS-Framework
das actionlib-Paket zur Verfügung. Bei den Actions gibt es einen ActionServer und einen ActionClient.
Die Definition erfolgt in den sogennanten action-Dateien. Eine parallele Verarbeitung von verschiedenen
Anfragen ist möglich. Ein Beispiel für eine ROS-Action ist Move-Base (Kapitel 3.4). Actions bestehen
aus drei Teilen:
1. Goal: Ein ActionClient sendet ein Ziel an einen ActionServer. Ein Beispiel könnte eine Zielkoordinate
sein, die erreicht werden soll.
2. Result: Nachdem die Action beendet wurde, gibt der ActionServer dem ActionClient ein Ergebnis
zurück, ob z.B. die Zielkoordinate erreicht wurde.
3. Feedback: Der ActionServer gibt den Fortschritt der aktuellen Action an.
202 Grundlagen
2.7.7 ROS-Parameter
In ROS können unter Verwendung des Parameterservers Konfigurationen ausgelagert werden. Die
Parameter sind in YAML-Dateien definiert und befinden sich meistens im config-Ordner innerhalb eines
ROS-Pakets. Ein Knoten kann diese Parameter lesen, schreiben oder löschen. Der ROS-Master ist
für den Parameterserver zuständig. Da eine Abfrage von Parameterwerten zeitaufwendig ist, wird der
Parameterserver hauptsächlich für Werte verwendet, die sich nicht verändern. Die Parameter, die von
einem Knoten gesetzt werden, werden erst gelöscht, wenn der ROS-Master deaktiviert wurde. Eine
weitere Möglichkeit, Parameter abzuspeichern, sind launch-Dateien.
2.7.8 ROS-Launch
In einer launch-Datei können beliebig viele Knoten, die gestartet werden sollen, zusammengefasst werden.
Dies erleichtert die Arbeit mit mehreren Knoten und hilft den Überblick zu bewahren. Ein weiterer
Vorteil von launch-Dateien ist, dass auch andere launch-Dateien problemlos eingebunden werden können.
Darüber hinaus muss beim Ausführen einer launch-Datei lediglich ein Terminal offen sein, weil beim
Start einer launch-Datei automatisch ein ROS-Master gestartet wird. Diese Dateien befinden sich
normalerweise innerhalb eines ROS-Pakets im gleichnamigen Ordner und werden im XML-Format verfasst.
Es können Nodes, Parameter und weitere launch-Dateien definiert werden. Mithilfe von Funktionen
können auch Berechnungen und Namensauflösungen verwendet werden. Im ROS-Framework bilden
diese launch-Dateien einen wesentlichen Bestandteil, weil beliebig viele Knoten zusammengestellt und
organisiert werden können. Der Dateiname sollte so gewählt werden, dass die Funktionalität leicht zu
erkennen ist.
213 Verwendete ROS-Pakete
Im folgenden Kapitel werden die ROS-Pakete, die im Rahmen dieser Arbeit verwendet wurden, genauer
erklärt.
3.1 Transformationsbäume
Anhand eines Roboters mit einem Laserscanner werden die Transformationsbäume erläutert. Das erste
Koordinatensystem befindet sich im Mittelpunkt des Roboters und wird robot0 genannt. Das zweite
Koordinatensystem befindet sich im Zentrum des Laserscanners und wird robot0 laser 0 genannt. Nun
sollen die Laserdaten vom robot0 laser 0 benutzt werden, um Hindernissen aus der Umwelt auszuweichen.
Damit dies erfolgreich funktioniert, müssen die Laserdaten vom robot0 laser 0 in das Koordinatensystem
des robot0 transformiert werden. Dafür muss eine Beziehung zwischen robot0 laser 0 und robot0
Koordinatensystemen festgelegt werden. Der Laserscanner befindet sich beispielsweise 0,1 m vor und 0,3
m über dem Zentrum des Roboters. Wenn nun Daten des Lasers verarbeitet werden, muss eine Translation
vom robot0 laser 0 zum robot0 mithilfe des Offsetvektors t = (0, 1 0 − 0, 3)T durchgeführt werden.
Weil es bei vielen Koordinatensystemen schwierig ist, den Überblick zu behalten, können die Beziehungen
zwischen Koordinatensystemen mithilfe des ROS-Pakets TF definiert werden und dabei übernimmt
es die Transformation der Koordinatensysteme. In diesem Beispiel werden Koordinatensysteme robot0
und robot0 laser 0 einem sogenannten Transformationsbaum hinzugefügt. Dabei stellt jeder Knoten ein
Koordinatensystem und jede Kante eine Transformation zwischen zwei Knoten dar. TF benutzt diese
Baumstruktur und nimmt an, dass alle Kanten im Baum vom Elternknoten zum Kindknoten gerichtet
sind. Um eine Kante zu erstellen, muss entschieden werden, welcher Knoten den Elternknoten darstellt
und welche den Kindknoten. Hier wird robot0 als Elternknoten festgelegt, da das Roboterzentrum für
die Navigation wichtiger ist als das Zentrum des Lasers.
3.2 STDR-Simulator
Bevor am mobilen Roboter das implementierte Programm getestet werden kann, muss es zunächst in einer
Simulation funktionieren. Dazu muss die Simulation erst aufgebaut werden. Das hat den wesentlichen
Vorteil, dass die neu geschriebenen Veränderungen in der Implementierung ohne größeren Aufwand
und schnell getestet werden kann. Darüber hinaus wird mithilfe einer Simulation vermieden, dass der
Roboter z.B. durch Kollision Schaden nimmt, falls das Programm noch einen unentdeckten Fehler
enthält. Für den Aufbau der Simulation wird der STDR-Simulator verwendet, der bereits vorgefertigt in
ROS-Community zu finden ist. Der STDR Simulator basiert auf einer Server-Client Architektur. Jeder
Knoten des STDR-Simulators kann über die ROS-Schnittstellen kommunizieren. Darüber hinaus stellt
der Simulator eine GUI für eine Visualisierung zur Verfügung. Jedoch können alle Funktionen des Pakets
auch über die Kommandozeilenbefehle ausgeführt werden, ohne dass die GUI gestartet werden muss.
223 Verwendete ROS-Pakete
3.2.1 STDR-Server
Der STDR-Server besteht aus dem STDR-Server-Node und dem Map-Loader-Node:
STDR-Server-Node
Dieser Knoten ist für die Synchronisierung und Funktionalität des Simulators verantwortlich. Er liefert eine
statische Karte, welche die Umgebung repräsentiert und überwacht die aktiven Roboter. Darüber hinaus
stellt der Knoten verschiedene Befehle zur Verfügung, die für die Steuerung von Robotern verwendet
werden können.
Map-Loader-Node
Der Knoten verwendet den Kartenserver, der von ROS zur Verfügung gestellt wird, um eine Karte von
diesem Server in den Simulator zu laden. Diese Karte kann dann von anderen Paketen benutzt werden.
3.2.2 STDR-Robot
Dieses Paket ist für die Realisierung der Roboter, Laserscanner und eine Bewegungssteuerung verant-
wortlich. Um einen neuen Roboter in den Simulator zu laden, muss zunächst der STDR-Server gestartet
werden. Darüber hinaus können verschiedene Befehle aufgerufen werden. Außerdem benötigt ein Roboter
einen Transformationsbaum, damit er seine eigene Position und den Standort der Sensoren ermitteln
kann. Dabei ist für jeden Sensor ein eigenes Koordinatensystem zu definieren, um Namenskollisionen zu
vermeiden. Außerdem stellt jeder Roboter einen Transformationsbaum mit seiner aktuellen Position zur
Verfügung und der Name des Koordinatensystems wird automatisch zugewiesen, wie z.B robot0.
3.2.3 STDR-Ressourcen
Der Simulator ermöglicht eigene Roboter und Sensoren für den STDR-Simulator zu implementieren, die
dann vom STDR-Robot-Knoten verwendet werden, um mit der Simulation zu interagieren. Dafür können
sogenannte YAML-Dateien geschrieben werden. Es werden bereits Ressourcen bereitgestellt, die der
Simulator für seine Funktionalität benötigt. Die Ressourcen sind in Karten, Roboter- und Sensordateien
unterteilt. In einer YAML-Datei können dann die Eigenschaften parametriert werden. Jede Karte besteht
dabei aus einer PNG- und YAML-Datei. Eine PNG-Datei ist eine Bilddatei, die eine Umgebung darstellen
kann. Diese Dateien können beispielsweise über ein Bildbearbeitungsprogramm wie GIMP eigenständig
erstellt werden. Der STDR-Simulator stellt bereits sechs Karten zur Verfügung. Ein Roboter und ein
Sensor bestehen jeweils aus einer YAML-Datei. Jedoch kann ein Roboter mit seinen Sensoren auch in
einer Datei implementiert werden. In der Abbildung 3.1 wird der STDR-Simulator mit einem Roboter,
einem Laserscanner und einer verfügbaren Karte aus dem Simulator gezeigt.
233 Verwendete ROS-Pakete
Abbildung 3.1: STDR-Simulator
3.3 Gmapping und Hector SLAM
Die Anforderungen der Lokalisierung und Kartierung einer mobilen Roboterplattform, die jeweils in den
Kapiteln 2.4 und 2.5 erläutert werden, werden mithilfe des SLAM Verfahrens erfüllt. Dabei bedeutet
SLAM eine gleichzeitige Positionsbestimmung und Kartierung. D.h., dass ein mobiler Roboter mithilfe von
unterschiedlichen Sensoren eine Karte seiner unmittelbaren Umgebung erstellt und eine Selbstlokalisierung
durchführt ([6]). Darüber hinaus muss der Roboter imstande sein, Hindernissen auszuweichen und zu
navigieren. Wenn die aktuelle Position des Roboters mithilfe eines Sensors ermittelt wurde, kann daraus
eine Karte erstellt werden. Dabei werden die Positionen der Hindernisse zu seinem aktuellen Standort
gemessen und mithilfe seiner eigenen Position können schließlich die genauen Standorte der Hindernisse
bestimmt werden, die anschließend in der Karte markiert werden. Mit den Daten der Robotersensoren
soll ohne Vorkenntnisse über die Umgebung eine Karte erstellt werden und die Position sowie die
Orientierung ermittelt werden. Dafür stehen in ROS die Pakete Gmapping und Hector SLAM zur
Verfügung. Beide Pakete funktionieren sehr ähnlich. Die beiden Knoten nehmen die Laserdaten und
erstellen daraus zweidimensionale Gitterkarten, in der Zustände der einzelne Gitterzellen abgespeichert
werden. Dabei kann eine Gitterzelle die Zustände besetzt, unexploriert oder frei annehmen. Im Rahmen
dieser Arbeit wurde der Gmapping Knoten in der Simulation (Kapitel 5.1) verwendet, da er besser mit
der Simulationsumgebung funktionierte als Hector SLAM. Bei dem Test mit dem realen Roboter wurde
hingegen Hector SLAM verwendet, weil die Kartierung und Lokalisierung Gmapping nicht funktionierte.
3.4 Navigation Stack und Move Base
Das Navigation Stack ist ein fertiges ROS-Paket, das für die Navigation eines Roboters verantwortlich
ist. Die bestmögliche Leistung wird bei quadratischen oder kreisförmigen Robotern erzielt. Prinzipiell
funktioniert es bei allen Roboterformen, außer bei großen rechteckigen Formen. Damit das Navigation
Stack und Move Base optimal funktioniert, muss der Roboter so konfiguriert sein, wie in der Abbildung
3.2 dargestellt.
243 Verwendete ROS-Pakete
Sensortransformationen Kartenserver
global_planner global_costmap
Move Base Sensorquellen
local_planner local_costmap
Robotersteuerung
Abbildung 3.2: Navigation Stack und Move Base (Quelle: [8])
In der Abbildung 3.2 sind die weiß markierten Komponenten ein hauptsächlicher Bestandteil von Move
Base. Diese sind bereits implementiert und können für die Navigation verwendet werden. Die grauen
Komponenten sind optional und ebenfalls bereits implementiert. Die blauen Komponenten müssen für
jede Roboterplattform erstellt werden und sind Teil des Navigation Stacks. Die einzelnen Komponenten
werden im Folgenden beschrieben.
3.4.1 Sensorquellen und -transformationen
Damit ein Roboter mit diesem Paket navigieren kann, muss ROS und das Paket TF konfiguriert sein,
da ein lokaler Transformationsbaum verwendet wird. Dieser Transformationsbaum stellt der mobilen
Roboterplattform Informationen über die Transformationen zwischen den unterschiedlichen Koordinaten-
systemen zur Verfügung. Darüber hinaus muss ein Laserscanner eingebunden werden, der für Kartierung
und Lokalisierung verantwortlich ist. Für eine erfolgreiche Navigation werden brauchbare Sensordaten
benötigt. Dazu müssen die Sensoren ihre Daten über die jeweiligen ROS-Nachrichten publizieren.
3.4.2 Robotersteuerung
Mithilfe dieser Sensordaten werden Geschwindigkeitsbefehle an die mobile Roboterplattform gesendet
werden. Für die Ansteuerung eines Roboters werden ROS-Nachrichten verwendet, die x-, y- und θ-
Geschwindigkeiten beinhalten. Diese Geschwindigkeitsbefehle werden abonniert und in die jeweiligen
Motorbefehle eines Roboters konvertiert.
253 Verwendete ROS-Pakete
3.4.3 Karten Server
Der Karten Server ist für die Kartierung der Umgebung verantwortlich. Dafür wird wiederum ein anderes
ROS-Paket benötigt, das in Kapitel 3.3 beschrieben wurde.
3.4.4 Die 2D-Kostenkarte
Die 2D-Kostenkarte stellt eine konfigurierbare Kartenstruktur zur Verfügung, auf deren Basis entschieden
wird, wohin der Roboter navigieren soll. Sie stellt eine xy-Ebene dar. D.h., dass sich beispielsweise
ein Gegenstand, der auf einem Regal abgelegt wurde, in der gleichen Zelle befindet und dieselben
Kosten besitzt wie das Regal, obwohl sie sich in der z-Koordinate unterscheiden. Um Informationen über
Hindernisse in der Umgebung zu speichern, verwendet die Kostenkarte Sensordaten und gegebenenfalls
die Informationen von einer statischen Karte. Ferner kann jeder Sensor Hindernisse in einer Zellen
markieren und löschen. Die Kostenwerte hängen von der Distanz zu den besetzten Zellen ab. Es gibt
fünf Kostenwerte, die für eine mobile Roboterplattform relevant sind:
Lethal
Der Kostenwert bedeutet, dass sich ein Hindernis in der aktuellen Zelle befindet. Wenn die Distanz
zwischen dem Zentrum des Roboters und dieser Zelle Null ist, dann kam es zu einer Kollision zwischen
dem Roboter und dem Hindernis.
Inscribed
Dieser Kostenwert bedeutet, dass die Entfernung zwischen dem Roboterzentrum und der besetzten Zelle
kleiner als der Roboterradius ist.
Possibly circumscribed
Dieser Kostenwert ist ähnlich zu dem Inscribed-Kostenwert, außer dass der Roboterradius als Distanz be-
nutzt wird. Wenn sich das Roboterzentrum in einer besetzten Zelle befindet, das diesen Wert überschreitet,
dann hängt es von der Orientierung des Roboters ab, ob es zur Kollision kommt.
Freespace
Der Kostenwert ist Null und bedeutet, dass der Roboter dort problemlos hinfahren kann.
Unknown
Der Kostenwert bedeuten, dass es keine Informationen über diese Zelle gibt.
Basierend auf der 2D-Kostenkarte verwendet Move Base drei Kostenkarten, um Informationen zu
speichern:
263 Verwendete ROS-Pakete
Globale und lokale Kostenkarte
Die globale Kostenkarte wird für die globale Pfadplanung, d.h. das Erstellen eines langfristigen Plans
über die gesamte Umgebung, verwendet. Die lokale Kostenkarte wird für eine lokale Pfadplanung und zur
Vermeidung von Hindernissen in der unmittelbaren Umgebung des Roboters benutzt. In den Kostenkarten
werden dann verschiedene Eigenschaften der Karten definiert, wie z.B. welche Koordinatensysteme
verwendet werden sollen oder die Höhe, Breite und Auflösung.
Allgemeine Konfiguration
Es gibt eine allgemeine Kostenkarte, die für beide Karten zunächst konfiguriert werden muss. In der
allgemeinen Konfiguration werden dann die Eigenschaften des Roboters und der Sensoren festgelegt, die
für die Erstellung der Kostenkarte relevant sind, wie z.B. die Größe des Roboters oder ob ein Laserscanner
Hindernisse hinzufügen oder entfernen darf.
3.4.5 Robotersteuerung (Base Local Planner)
Der Base Local Planner stellt eine Steuerungseinheit zur Verfügung, die eine mobile Roboterplattform
in der Ebene fahren lässt. Diese Steuerungseinheit verbindet die Pfadplanung mit dem Roboter. Auf
dem Weg zu einer Zielposition erstellt die Planung um den Roboter eine Gitterkarte in der Größe der
lokalen Kostenkarte. Eine Gitterzelle beinhaltet die Kosten für das Durchqueren dieser Zelle. Dabei ist
der globale Pfad in diesem Bereich abgebildet. Das Ziel des globalen Wegs liegt meist außerhalb des
Bereichs der Gitterkarte. Diese Gitterkarte wird dann für eine Bewertung der jeweiligen kinematischen
Trajektorien benutzt. Bei der Erstellung einer Trajektorie für die Annäherung an das Ziel wird zunächst
das lokale Ziel gesucht. Das lokale Ziel ist dann der erste Pfadpunkt, der sich innerhalb der lokalen
Kostenkarte befindet und einen weiterführenden Pfadpunkt außerhalb der lokalen Kostenkarte besitzt.
Bei der Bewertung der kinematischen Trajektorien werden zunächst die Geschwindigkeiten in x-, y- und θ-
Richtung einzeln betrachtet. Unter Berücksichtigung der aktuellen Roboterposition werden die einzelnen
Geschwindigkeiten simuliert, d.h. es wird das Resultat überprüft, wenn der Roboter mit einer bestimmten
Geschwindigkeit für eine kurze Zeitspanne fährt. Anschließend wird jedes Ergebnis einer simulierten
Trajektorie anhand von den Kriterien Schnelligkeit, Distanzen zu Hindernissen, zum lokalen Ziel und zum
globalen Pfad bewertet. Unzulässige Trajektorien wie beispielsweise Kollisionen werden verworfen. Ein
Beispiel für die Erstellung solcher Trajektorien wird in Abbildung 3.3 dargestellt. Es wird die optimale
Trajektorie ausgewählt und die damit verbundenen Geschwindigkeiten an den Roboter gesendet. Dieser
Vorgang wird solange wiederholt, bis das Ziel erreicht ist.
Abbildung 3.3: Erstellung verschiedener Trajektorien (Quelle: [9])
274 Implementierung des thi exploration node
In diesem Kapitel wird die Funktionsweise des Programms erläutert, das im Rahmen dieser Arbeit
implementiert wurde.
4.1 Aufbau einer Karte
Zunächst abonniert bzw. empfängt dieser Knoten eine zweidimensionale Gitterkarte vom Laserscanner
bzw. vom SLAM-Algorithmus. Darüber hinaus bekommt das Programm den Kartenursprung, -breite,
-höhe und die Auflösung der Karte. Die Gitterkarte ist in einzelne Pixel unterteilt und jeder Pixel ist
in einem Vektor gespeichert. Außerdem wird ein Array mitgeliefert, in dem Informationen über ein
Pixel gespeichert sind. Über einen Index kann auf einen Pixel und seine Information zugegriffen werden.
Diese Informationen enthalten den Zustand eines Pixels. Ein Pixel kann entweder den Zustand besetzt,
der schwarz bzw. mit dem Wert 100 gekennzeichnet wird, oder frei, der weiß bzw. mit dem Wert
0 gekennzeichnet wird, oder unexploriert, der grau bzw. mit dem Wert -1 gekennzeichnet wird. Die
Abbildung 4.1 zeigt einen beispielhaften Aufbau einer solchen Gitterkarte.
Kartenbreite = 5
0 1 2 3 4
Kartenhöhe = 4
5 6 7 8 9
10 11 12 13 14
15 16 17 18 19
Abbildung 4.1: Aufbau einer Karte
4.2 Berechnung der Nachbarpixel
Ein Pixel kann bis zu acht Nachbarn besitzen, wie in Abbildung 4.2 dargestellt wird. Diese können
mithilfe der Kartenbreite folgendermaßen berechnet werden:
284 Implementierung des thi exploration node
• Rechts: Für die Berechnung des rechten Nachbarpixels, muss der aktuelle Pixelwert um eins erhöht
werden. Jedoch darf der Wert nur um eins erhöht werden, wenn sich der aktuelle Pixelwert nicht
in der letzten Spalte befindet.
• Links: Für die Berechnung des linken Nachbarpixels, wird der aktuelle Pixelwert um eins verringert.
Jedoch darf der Wert nur um eins verringert werden, wenn sich der aktuelle Pixelwert nicht in der
ersten Spalte befindet.
• Oben: Für die Berechnung des oberen Nachbarpixels, muss die Kartenbreite vom aktuellen Pixelwert
subtrahiert werden. Jedoch darf die Kartenbreite nur subtrahiert werden, wenn sich der aktuelle
Pixelwert nicht in der ersten Zeile befindet.
• Unten: Für die Berechnung des unteren Nachbarpixels, wird die Kartenbreite auf den aktuellen
Pixelwert addiert. Jedoch darf die Kartenbreite nur addiert werden, wenn sich der aktuelle Pixelwert
nicht in der letzten Zeile befindet.
• Links, oben: Für die Berechnung eines diagonalen Nachbarpixels, der sich links oben befindet, wird
die Kartenbreite um eins erhöht und dann vom aktuellen Pixelwert subtrahiert. Jedoch darf diese
Berechnung nur erfolgen, wenn sich der aktuelle Pixelwert weder in der ersten Zeile noch in der
ersten Spalte befindet.
• Rechts, oben: Für die Berechnung eines diagonalen Nachbarpixels, der sich rechts oben befindet,
wird die Kartenbreite um eins verringert und dann vom aktuellen Pixelwert subtrahiert. Jedoch
darf diese Berechnung nur erfolgen, wenn sich der aktuelle Pixelwert weder in der ersten Zeile noch
in der letzte Spalte befindet.
• Links, unten: Für die Berechnung eines diagonalen Nachbarpixels, der sich links unten befindet,
wird die Kartenbreite um eins verringert und dann auf den aktuellen Pixelwert aufsummiert. Jedoch
darf diese Berechnung nur erfolgen, wenn sich der aktuelle Pixelwert weder in der letzten Zeile
noch in der ersten Spalte befindet.
• Rechts, unten: Für die Berechnung eines diagonalen Nachbarpixels, der sich rechts unten befindet,
wird die Kartenbreite um eins erhöht und dann auf den aktuellen Pixelwert aufsummiert. Jedoch
darf diese Berechnung nur erfolgen, wenn sich der aktuelle Pixelwert weder in der letzten Zeile
noch in der letzten Spalte befindet.
links rechts
oben
oben oben
akt.
links rechts
Pixel
links rechts
unten
unten unten
Abbildung 4.2: Berechnung der Nachbarpixel
Ein Beispiel für die Berechnung des unteren Nachbarpixel sowie die Bedingung, dass der Pixel nicht in
der letzten Zeile sein darf, sieht dann folgendermaßen aus:
294 Implementierung des thi exploration node int unten = aktueller Pixel + Kartenbreite ; if ( unten
Sie können auch lesen
