 |
Smart Minotaur
|
|
Smart Minotaur
|
Die Aufgabe des Roboters ist es ein Labyrinth zu karthographieren. Der Roboter verfügt über einen Differentialantrieb und kann seine Umgebung mithilfe von Ultraschallsensoren wahrnehmen. Sensoren und Antrieb werden über einen Lego NXT Brick angesteuert.
Zusätzlich wurde auf dem Roboter ein Beagle Bone Black montiert. Dieses bietet mehr Rechenleistung und eine flexiblere Programmierung als der Brick, auf welchem lediglich in der beschränkten Programmiersprache NXC gearbeitet werden kann. Außerdem wird das BBB benötigt um zusätzliche die Maussensoren über den SPI-Bus anzusprechen. Diese Maussensoren werden verwendet, um die zurückgelegte Strecke des Roboters zu messen und somit dessen Odometrie zu verbessern.
Als Programmiersprache wird in dem kompletten Projekt C++ verwendet. Außerdem wird das Framework Robot Operative System (ROS) in der Version hydro verwendet. Mit diesem Framework wird die Kommunikationen einzelner Komponenten und Programme in einem verteilten System stark abstrahiert und dadurch vereinfacht. Außerdem bietet es viele Funktionen und Programme zur Navigation und Lokalisierung von Robotern. Die Hauptaufgabe von ROS in diesem Projekt ist die Interprozesskommunikation über das WLAN (siehe Kommunikation). In einem der Ansätze wird außerdem auch der ROS Navigation Stack verwendet, um den Roboter zu navigieren (siehe Belegtheitsgitter Ansatz).
In diesem Teil des Wikis wird der Roboter des Projekts und dessen Implementierung näher beleuchtet. Da die Maussensoren nicht in den Roboter implementiert wurden, sollte zu diesem Thema die Seite Maussensoren herangezogen werden.
Das Projekt ist in verschiedene ROS-Packages unterteilt, sodass zu jeder Zeit immer nur die wirklich benötigten Packages kompiliert werden können. Dies ist vor allem in Hinblick auf die lange Kompilierdauer auf dem Beagle Bone nützlich. Die einzelnen ROS-Packages werden im folgenden Abschnitt Packages kurz beschrieben. Für weitere Informationen können die Code Dokumentation und die genannten Abschnitte und Wikiseiten herangezogen werden.
In diesen ROS-Packages sind verschiedene ROS-Nodes enthalten, die alle miteinander über das ROS-Kommunikationsystem kommunizieren. Die Art und Richtung der Kommunikation wird in dem Abschnitt Kommunikation erläutert.
| Packagename | Beschreibung |
|---|---|
| minotaur_common | Dieses Package beinhaltet grundlegende Strukturen und Funktionen, die von allen anderen Packages verwendet werden. Darunter sind verschiedene Funktionen zur Umrechnung von Maßeinheiten, Funktionen für das Auslesen von Parametern vom ROS-Param-Server, Funktionen zur Kommunikation über ROS und Definitionen für ROS-Topics. Durch dieses Package wird vor allem Codeduplikationen vorgebeugt. Das Package muss immer im Zusammenhang mit jedem anderen Package kompiliert werden. |
| minotaur_common_qt | Auch bei diesem Package handelt es sich um ein allgemeines Package, das praktische Funktionen und Strukturen anbietet. Dabei ist dieses Package speziell für Aufgaben im Zusammenhang mit Qt zuständig. Da solche Funktionen beispielsweise auf dem Beagle Bone nicht benötigt werden, haben diese eine seperates Package erhalten. Die meisten Qt nutzenden Packages verwenden auch dieses Package. |
| robot_control | Dieses Package umfasst die Implementierung des PID-Reglers für die Motoren, das Auslesen der Ultraschallsensoren und das Verarbeiten von ROS-Messages, um den Brick anzusteuern. Außerdem wird hier die ROS-Node RobotControl bereitgestellt, welche die Kommunikationsgrundlage aller anderen Packages darstellt. Mehr dazu in dem Abschnitt RobotControl. |
| pid_monitor | In diesem Package wird eine GUI-Applikation realisiert, mit der sich das Verhalten des PID-Reglers in Form von Graphen betrachten lässt. Der Roboter kann außerdem ferngesteuert werden. So können dessen Einschwing- und Ausgleichverhalten beobachtet werden. Neben den Motoren bietet die Applikation auch die Möglichkeit, Hindernisse mit den Ultraschallsensoren wahrzunehmen. Mehr dazu im Abschnitt GUI Tools. |
| minotaur_map | Das Package minotaur_map realisiert den ersten Ansatz dieses Projektes. Es beinhaltet Funktionen und Strukturen um Belegtheitsgitter zu erzeugen und durch diese hindurch zu navigieren. Außerdem nutzt es die ROS Navigation Stack Schnittstelle, um den Roboter anzusteuern. Mehr Informationen dazu finden sich im Abschnitt Ansätze. |
| map_monitor | Bei map_monitor handelt es sich um ein Package, das eine GUI-Applikation für das Belegtheitsgitter realisiert. Der Roboter kann angesteuert werden, während eine Karte live mitgezeichnet wird. Mit diesem Tool kann also die Qualität der Karte und auch das Verhalten des Erstellungsalgorithmus beobachtet und bewertet werden. Mehr Informationen finden sich im Abschnitt GUI Tools. |
| minotaur_maze | In dem Package minotaur_maze wird der zweite Ansatz dieses Projektes realisiert. Es enthält Strukturen und Funktionen, um den Roboter in einem graphenähnlichen Labyrinth zu bewegen und eine Karte dieses Graphen zu erstellen. Mehr dazu im Abschnitt Ansätze. |
| mouse_monitor_pc | Mouse Monitor PC wird auf einem Desktop-Rechner ausgeführt und empfängt über WLAN die PLN2033 Sensor-Daten vom BBB. Messwerte und Sensor-Konfiguration werde graphisch dargestellt sowie Funktionen zum Debuggen. Basierend auf den Messwerten wird die Position/Ausrichtung sowie der zurückgelegte Pfad des Roboters berechnet und dargestellt. Zusätzlich können die Sensoren mithilfe graphischer Oberfläche kalibriert werden. |
| mouse_monitor_beagle | Dieses Package beinhaltet das BBB Gegenstück zu Mouse Monitor PC. Es ist zuständig für das Ansteuern des PLN2033 Sensors. Dafür wird die pln_minotaur Bibliothek verwendet. Zusätzlich bietet das Package verschiedene ROS Services zur Kommunikation über WLAN an. |
| minotaur_teleop | Das Package minotaur_teleop enthält ROS-Nodes, um den Roboter remote mit einem Gamepad zu steuern. Dies kann beispielsweise benutzt werden, um den Roboter in Kombination mit dem GUI-Tool map_monitor. |
Das folgende Diagramm zeigt die Kommunikationsstruktur in diesem Projekt.
Die zentrale ROS-Node RobotControl wird in dem Abschnitt RobotControl genauer betrachtet. Mit ihr kann der Roboter über das ROS Kommunikationssystem angesteuert werden. Movebase ist eine ROS interne Node. Sie ist zuständig für die grundlegende Kommunikation innerhalb des ROS Navigation Stack. Daher wird sie auch nur von Applikationen benötigt, die den ROS Navigation Stack benutzen, ansonsten muss diese Node nicht gestartet werden. moveInMaze ist die ROS-Node, die den Graphen Ansatz realisiert. Um diese Node zu benutzen muss RobotControl gestartet sein.
Auf dem Desktop Computer laufen sämtliche GUI Applikationen. Diese kommunizieren über das ROS Kommunikationssystem mit der RobotControl Node. Außerdem läuft dort auch die remote-control Node joy_teleop. Mit dieser kann der Roboter mithilfe eines Gamepads ferngesteuert werden. Die Verbindung zwischen BBB und PC findet per WLAN statt.
Das Beagle Bone kommuniziert neben dem PC auch mit lokal vorhandenen Geräten. Der Lego NXT Brick ist über USB an das BBB angeschlossen. An den Brick sind wiederum die Motoren und Ultraschallsensoren des Roboters angeschlossen. Somit kann das Beagle Bone nur indirekt über den Brick auf die Aktoren und Sensoren des Roboters zugreifen. Neben dem Brick nutzt das BBB einen SPI-Bus, um die angeschlossenen Maussensoren anzusteuern. Diese wurden im Rahmen diese Projektes jedoch noch nicht implementiert, da sich die Maussensoren noch in einem Prototypenstatus befinden.
Das Projekt umfasst viele einzelne ROS-Nodes (Applikationen). Dabei handelt es sich um ineinandergreifende Anwendungen, die über das ROS-Kommunikationssystem zusammenarbeiten. Einige davon dienen ausschließlich Debuggingzwecken und sind zumeist graphischer Natur. Ihre Funktionsweise und das korrekte Starten dieser Anwendungen (beispielsweise zur remote Steuerung des Roboters) wird in den folgenden Abschnitten näher beleuchtet.
NXTControl ist eine Bibliothek um den Lego NXT Brick über USB anzusteuern. Da diese Bibliothek eine Eigenentwicklung ist wird sie auf der folgenden Seite detaillierter beschrieben.
RobotControl ist die zentrale ROS-Node des Projektes. Sie wird in dem Package robot_control realisiert.
Die Node übernimmt das Umrechnen von Geschwindigkeit und Winkelgeschwindigkeit auf Geschwindigkeiten der einzelnen Motoren. Außerdem regelt sie über einen PID-Regler die Geschwindigkeiten der Motoren getrennt. Zur Regelung werden außerdem die Geschwindigkeiten der Motoren ausgelesen und wiederrum in Geschwindigkeit und Winkelgeschwindigkeit umgerechnet. Die angeschlossenen Ultraschallsensoren werden in regelmäßigen Intervallen ausgelesen.
Weiterhin nimmt RobotControl ROS-Messages entgegen, mit denen die Geschwindigkeiten des Roboters gesetzt werden können. Die von den Motoren gemessenen Geschwindigkeiten werden wiederum in regelmäßigen Abständen an eine ROS-Topic gesendet. Dabei werden für diese Nachrichten die Standard-ROS-Topics für den ROS Navigation Stack verwendet, sodass der Roboter vollständig kompatibel zu dem ROS Navigation Stack ist. Dies bedeutet, dass Odometriedaten an die Topic /odom geschickt und Geschwindigkeitsbefehle von der Topic /cmd_vel entgegen genommen werden.
Die Ultraschallsensoren können über eigene Topics und Messages angesteuert werden. So kann mit einer Message an die Topic /add_ultrasonic der Node mitgeteilt werden, dass sich an dem angegebenen Port ein Ultraschallsensor befindet und dieser nun auch ausgelesen werden soll. Dabei verwendet RobotControl ein internes Mapping von Sensor-IDs auf Sensorports, sodass bei den Sensormessungen immer klar ist welche Messung von welchem Sensor kommt. Die ID wird beim Hinzufügen des Sensors über eine ROS-Message zurückgegeben. Mehr Topics und deren Funktion können der Datei MinotaurTopics.hpp und der Code Dokumentation entnommen werden.
Eine weitere komfortable Funktion von RobotControl ist, dass sämtliche Einstellungen des PID-Reglers, Dimensionen des Roboters und angeschlossene Sensoren über den ROS-Param-Server geladen werden können. Diese Daten können alternativ auch über ROS-Messages eingestellt werden. Dabei werden die Einstellungen auf dem ROS-Param-Server unter dem Namespace minotaur hinterlegt. Danach folgt der Name der Einstellungen und darunter die einzelnen Parameter. Die ganze Struktur kann aus der Datei models.yaml in dem Package minotaur_common entnommen werden. Beim Start der RobotControl Node schaut diese nach dem Parameter CurrentModel. Ist dieser vorhanden wird dessen Inhalt als Name der initialen Einstellungen behandelt und die Node lädt diese Einstellungen.
Damit übernimmt diese ROS-Node die komplette Ansteuerung des Brick und abstrahiert diese auf ROS-Messages. Somit muss lediglich diese Node auf dem Beagle Bone Black ausgeführt werden. Alle anderen Nodes können ebenfalls auf dem BBB oder aber auch auf einem anderen Computer im selben Netzwerk ausgeführt werden.
Während dieses Projektes wurde es notwendig grafische Anwendungen zu entwickeln, um bestimmte Systemteile zu debuggen und deren Verhalten zu beobachten. Alle Anwendungen wurden mit Qt4 und der Erweiterung QWT geschrieben. QWT bietet grafische Komponenten wie Graphen, wodurch das Analysieren von Daten vereinfacht wird. Alle in diesem Projekt entwickelten grafischen Anwendungen werden auf der folgenden Seite näher beschrieben:
Im Rahmen dieses Projektes wurden mehrere Lösungsansätze zum Lösen des Labyrinths verfolgt.
Im ersten Ansatz wurde ein Belegtheitsgitter angefertigt und der Roboter sollte sich anhand dieser Karte und mithilfe des ROS Navigation Stacks durch das Labyrinth bewegen.
Im zweiten Ansatz wurde der Roboter direkt angesteuert. Das Labyrinth wurde als Graph betracht und in Zellen gleicher Größe unterteilt.
Da die Odometrie der Lego NXT Motoren nicht sehr gut ist und vor allem bei Drehungen des Roboter oft Fehler verursachen, da die Reifen durchdrehen, sollten Maussensoren genutzt werden, um die Odometrie zu verbessern. Wie bereits erwähnt wurden die Maussensoren aufgrund ihres Prototypenstatus nicht in den Roboter implementiert. Mehr Informationen dazu finden sich auf der Seite Maussensoren.
Im Verlauf des Projektes sind mehrere Probleme aufgetreten, deren Lösung bis zum derzeiten Zeitpunkt noch ausstehen.
Die Ultraschallsensoren des NXT registrieren in scheinbar zufälligen Abständen Fehlmessungen, die jenseits einer Fehlertoleranz liegen. Dabei handelt es sich um Fehlmessungen im Bereich von +-20cm. Diese könnten theoretisch durch einen Medianfilter ausgeglichen werden, was in diesem Projekt auch versucht wurde. Tritt jedoch so eine Fehlmessung auf, liefert der Sensor für die nächsten 4 bis 8 Messungen denselben falschen Wert. Dadurch kann auch der Medianfilter diesen Fehler nicht mehr ausgleichen.
Es liegt der Verdacht nahe, dass der Sensor die folgenden Male den gleichen Sensorwert liefert, weil er keine weitere Messung unternommen hat. Jedoch wird bei der Messung kein Zeitstempel hinterlegt, wodurch sich nicht unterscheiden lässt, ob es sich um die gleiche Messung oder nur zufällig um den gleichen Wert bei einer weiteren Messung handelt.
Ein Vergrößern des Medianfilters oder eine Verlängern des Abtastintervalls führt zu einer Reduktion der Wirkung des Fehlers. Der größere Medianfilter filtert den Fehler entweder ganz weg oder der Fehler tritt nur einen kurzen Moment auf. Jedoch ist die Reaktionszeit des Roboter durch den großen Filter extremst verlängert und zumeist unzureichend. Der Roboter kann dann nicht auf Umgebungsänderungen wie das Auftauchen einer Wand reagieren. Dasselbe gilt auch für ein verlängertes Abtastintervall. Es führt zu weniger Messungen mit derselben Fehlmessung. Damit wird auch bestätigt, dass immer wieder derselbe Messwert aus der gleichen Messungen geliefert wird. Die Reaktionszeit des Roboters sinkt jedoch auch in diesem Fall in einen unzureichenden Bereich.
Die Ansteuerung der Ultraschallsensoren geschieht durch das Direct Command Interface des Brick, wodurch kein dediziertes Programm auf dem Brick laufen muss. Durch die Abstraktion des Bricks in Hinsicht auf das Auslesen des Sensors, ist es auch nicht möglich direkt auf die Hardware des Sensors zuzugreifen. Daher konnte der Sensor auch nicht direkt, sondern nur über das Direct Command Interface ausgelesen werden.
Aufgrund des großen Messfehlers und der wiederauftretenden Messwerte ist eine Navigation in einem Labyrinth für den Roboter kaum möglich.
Dadruch, dass sämtliche Fehler bei der Arbeit mit den Maussensoren erst gegen Ende des Projekts gelöst wurden, konnten diese nicht mehr an den Roboter montiert und die entsprechende Software implementiert werden. Daher bleibt weiterhin das Problem bestehen, dass die Navigation und Lokalisierung des Roboters unzureichend ist. Die Auswirkung der Maussensoren auf die Odometrie des Roboters konnte im Rahmen dieses Projekts nicht mehr festgestellt werden.
1.8.1.2 
