Roboter mit ROS. Murat Calis
id="u1359131f-dc68-4f2c-b9a6-becf5ec7ee01">
1.2.4ROS-Master
Im Mittelpunkt steht der Master, welchen wir zuvor schon mal mit roscore gestartet hatten. Standardmäßig läuft dieser auf TCP-Port 11311 und wartet auf XMLRPC-Nachrichten von anderen ROS-Knoten, den Nodes. Die genaue Adresse der Ressource erfährt man mit:
echo $ROS_MASTER_URI
ROS-Variablen beginnen mit der Zeichenfolge ROS und können in der .bashrc überschrieben oder gesetzt werden. Ein ROS-Master auf einem entfernten Rechner lässt sich so einfach einrichten wie das Setzen der Variable $ROS_MASTER_URI. In der .bashrc könnte zum Beispiel folgende Export-Variable stehen:
export $ROS_MASTER_URI=http://192.168.2.123:11311
Startet nun ein Node, wird zuerst der Wert von $ROS_MASTER_URI abgefragt. Dann wird per XML/RPC eine Verbindung mit dem Master aufgebaut, um diesem bekanntzugeben, was man publizieren oder abonnieren möchte – nach dem publish/subscribe-Prinzip. Mit einem ping zwischen dem Node und dem Master sollte man vorab sicherstellen, dass es keine Verbindungsprobleme gibt. Wurde zuvor kein ROS-Master mit roscore oder roslaunch gestartet, bricht der Startprozess mit der Fehlermeldung ab, dass kein ROS-Master gefunden oder gestartet wurde.
Im Grunde ist der Master ein XML/RPC-Namensdienst, der allen Nodes die nötigen Informationen liefert, damit diese sich untereinander mit den richtigen Nodes über TCP/IP verbinden, um deren Nachrichten zu erhalten. Die Kopplung loser Programme bzw. Nodes durch den Master, damit diese Nachrichten untereinander austauschen können, ist ein wesentliches Merkmal von ROS.
Abb. 1–4ROS-Kommunikationskonzept (XML/RPC & TCP/IP)
In Abbildung 1–4 sehen wir zwei Nodes und einen Master. Verfolgen wir die Schritte 1 bis 3, wird deutlich, dass der Master stets eine kurzfristige Vermittlerrolle einnimmt. Der Master verkuppelt lediglich zwei Nodes miteinander und lässt diese Daten unter sich austauschen. Die Nodes sind lose verbunden, was so viel bedeutet wie, es kann ein Node jederzeit beendet werden und ein neuer Node kann jederzeit Nachrichten von anderen publizierenden Nodes abonnieren, ohne dass das Gesamtsystem beeinträchtigt wird.
Wird der Node FaceDetector beendet oder stürzt dieser ab, hat das keine Auswirkungen auf den Master und auch keine auf den Camera-Node. Startet der FaceDetector nach einer Weile wieder, wird die Verbindung wiederhergestellt und Daten werden übertragen, als wäre nichts gewesen.
Fällt der Node Camera aus oder wird dieser beendet, gibt es lediglich eine Warnung, aber keine Fehlermeldung und der FaceDetector-Node bricht deshalb auch nicht zusammen oder wird beendet, stattdessen wird gewartet, bis der Camera-Node wiederbelebt wird und Daten an das »image«-Topic ausgibt.
Dieses Merkmal macht ROS so beliebt. Es kann immer mal etwas ausfallen und trotzdem bleibt das Gesamtsystem stabil. Dezentrale Software-Module erleichtern darüber hinaus die Arbeit im Team. Jeder konzentriert sich auf seinen Teilbereich – ein Programm-Modul im Gesamtsystem.
Mit roscore startet ein ROS-Master.
Ein weiterer Aufruf von roscore führt zu einem Fehler, da es unter der verwendeten IP-Adresse nur einen Master geben kann.
Andere ROS-Computer können sich einem ROS-Master anschließen, indem Sie die ROS_MASTER_URI und ROS_MASTER_IP setzen.
1.2.5ROS-Nodes
Ein Node ist eine Instanz eines ausführbaren Programms. Das bedeutet, dass man ein und dasselbe Programm mehrmals gleichzeitig starten kann, indem man unterschiedliche Namen beim Aufruf verwendet.
Programme innerhalb des ROS-Systems werden nicht wie gewöhnliche Systemprogramme oder Anwendungen aufgerufen. Stattdessen wird ein Startprogramm namens rosrun verwendet, um das Programm zu einem vollwertigen Node zu machen. Wir haben zuvor gelernt, dass der ROS-Master sämtliche Ports öffnet und Sockets bereitstellt, damit ein Node erreichbar ist und mit anderen Nodes kommunizieren kann. Wir werden also nie Sockets programmieren oder Ports öffnen müssen, denn das übernimmt ROS für uns.
Im folgenden Befehl wird mit rosrun aus dem Paket rqt_image_view das gleichnamige Programm rqt_image_view gestartet. Im darauffolgenden Befehl ist ein Beispiel mit dem Parameter __name. Der letzte Befehl zeigt die nötigen Informationen eines Node an. Wenn man Nachrichten von einem Node erhalten oder umgekehrt Nachrichten an ein Node senden möchte, dann stehen in den Informationen die Nachrichtendefinitionen, die von den jeweiligen Themen (topics) verwendet werden.
rosrun rqt_image_view rqt_image_view
rosrun rviz rviz __name:=mein_test_name
rosnode info mein_test_name
In Linux kann man die Konsole dazu bewegen, nach einer Tastatur-Eingabe alles auszugeben, was im Kontext möglich ist. Wenn man »rosrun rqt_« eingibt, aber nicht weiß, wie es weiter geht, einfach zweimal hintereinander die
Sobald der mit rosrun gestartete Node läuft, kann man mit dem Befehl rosnode list prüfen, welchen Node-Namen die Programm-Instanz erhalten hat. Weitere Möglichkeiten gibt die Konsole mit rosnode und zwei aufeinanderfolgenden Tabulator-Eingaben aus.
Der Befehl rosrun sucht in allen Verzeichnissen, die in der Variable $CMAKE_PREFIX_PATH enthalten sind, nach ausführbaren Programmen.
Unsere Programme werden wir jedoch nicht einzeln per rosrun starten, sondern später mit roslaunch in einer Starter-Datei bündeln. Schließlich werden wir viele kleine Programme, die wir nun als Nodes bezeichnen, zu einem großen Cortex verknüpfen.
Sobald wir beginnen, eigene Nodes zu programmieren, werden diese hauptsächlich Topics, Services, Service-Clients, Action-Clients, Action-Services implementieren. Somit generieren wir Schnittstellen für andere Nodes. Dabei beschränkt die Wahl einer der soeben genannten Funktionen nicht die anderen. Wir können also Topics, Services und Actions gleichzeitig und mehrfach vorkommend in einem Node implementieren.
1.2.6ROS-Topics
Damit ein Node mit anderen Nodes kommunizieren kann, publiziert oder abonniert dieser ein oder mehrere Topics. Topics sind Themen-Bezeichnungen, unter denen es fortwährend Nachrichten (engl. Messages) zu senden oder empfangen gibt. Will ein Node zur Gesichtserkennung Nachrichten von einer Kamera erhalten, so abonniert dieser Node für die Gesichtserkennung ein entsprechendes Topic – zum Beispiel »/ camera/image_raw«. Nachdem ein Topic abonniert wurde, fließen Nachrichten vom publizierenden zum abonnierenden Node, also in nur eine Richtung.
Abb. 1–5Ein Publisher, ein Topic und ein Subscriber
Die in der obigen Abbildung dargestellte 1:1-Kommunikationsform kann auch in Form einer 1:n- oder n:n-Kommunikation vorkommen. Wenn ein Topic für mehr als nur einen Abonnenten interessant ist, lesen mehrere Subscriber denselben Nachrichtenkanal. Darüber hinaus kann ein Subscriber beliebig viele Topics abonnieren,