Читать книгу Roboter mit ROS - Murat Calis - Страница 21

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.