Einführung in das Robot Operating System
Seite 2: Bauteile
Die Bauteile des Systems
Die grundlegenden Konzepte für das Verständnis der Funktionsweise von ROS heißen Node, Master, Message, Topic und Service. Ein Node ist ein Softwareprozess, der Daten mit anderen Nodes über Messages austauscht. Eine Message wird zum Transport von Daten verwendet und besteht aus typisierten Einträgen – ähnlich einer C-Struktur. Topic bezeichnet einen Datenbus mit einem eindeutigen Namen, über den Messages ausgetauscht werden und der für unidirektionale Kommunikation zum Einsatz kommt. Da ROS auf Peer-to-Peer-Kommunikation basiert, ist zum Auffinden der Kommunikationspartner zur Laufzeit eine Vermittlungsstelle erforderlich. Diese Aufgabe erfüllt der Master. Die Implementierung der bidirektionalen Kommunikation erfolgt über Services.
Knoten und Kanten
Unter einem Node versteht man einen Prozess, der Berechnungen ausführt. In einem typischen Szenario laufen mehrere Nodes parallel, um die an das System gestellten Anforderungen zu erfüllen. Die Bezeichnung stammt aus der Darstellung aller laufenden Prozesse als Knoten sowie der zwischen den Prozessen ausgetauschten Informationen als Kanten eines gerichteten Graphen.
Jeder Node wird durch einen Graph Resource Name eindeutig identifiziert. Die Namen der in Abbbildung 1 dargestellten Knoten lauten /point_publisher_node und /point_subscriber_node. Die Pfeile der Kanten geben die Flussrichtung an. Daten werden immer von einem Knoten publiziert (Quelle) und von keinem, einem oder mehreren Knoten (Senken) abonniert. Jeder Kante ist ein eindeutiger Name zugeordnet, der den Inhalt der übertragenen Informationen identifiziert und das Topic darstellt. Die Knoten in Abbildung 1 publizieren beziehungsweise abonnieren Informationen unter dem Topic /point. Das Werkzeug rosnode zeigt mit folgendem Code alle im System gestarteten Nodes:
$ rosnode list
/point_publisher_node
/point_subscriber_node
/rosout
Folgendes Listing zeigt detaillierte Informationen
zu einem Knoten:
$ rosnode info /point_publisher_node
--------------------------------------------------------
Node [/point_publisher_node]
Publications:
* /rosout [rosgraph_msgs/Log]
* /point [geometry_msgs/Point]
Subscriptions: None
Services:
* /point_publisher_node/get_loggers
* /point_publisher_node/set_logger_level
...
Aus dem zweiten Codeauszug ist ersichtlich, dass der Node /point_publisher_node Daten unter den Topics /rosout und /point publiziert. Bei /rosout handelt es sich um den standardmäßigen Logging-Mechanismus von ROS. Daher zeigt ihn die mit rqt_graph erstellte Ansicht im Default-Zustand nicht an. Der Node abonniert keine Themen, bietet aber zwei Services an, die für das Setzen und Auslesen des Logging-Levels verwendet werden und in ROS bei jedem Knoten automatisch vorhanden sind.
Das Werkzeug rosrun startet die Nodes. Der erste Parameter gibt den Paketnamen an und der zweite den zu startenden Knoten. Danach können Entwickler beliebig viele weitere Parameter anführen, die das Tool an den Knoten zur weiteren Verwendung durchreicht:
$ rosrun rosintro point_publisher_node
Bei einer hohen Anzahl von Parametern ist deren Eingabe bei jedem Neustart eines Knotens mühsam, zeitaufwendig und fehlerträchtig. Des Weiteren startet der Befehl immer nur einen Node. Diese Nachteile können Entwickler durch den Einsatz sogenannter Launch-Dateien beheben. Sie verwenden XML und beschreiben, welche Nodes das System mit welchen Parametern starten soll. Folgender Code startet "point_publisher_node" ohne Angabe weiterer Parameter:
<launch>
<node pkg="rosintro" type="point_publisher_node"
name="point_publisher_node" output="screen"/>
</launch>
Ein Überblick über alle möglichen Parameterkonfigurationen ist im ROS-Wiki zu finden. Zum Ausführen von Launch-Dateien kommt das Werkzeug roslaunch zum Einsatz:
$ roslaunch rosintro point_publisher_node.launch
Meister der Verwaltung
Nutzer starten den Master mit dem Werkzeug roscore. Die Ausführung muss vor dem Start des ersten Knoten erfolgen. Bei Verwendung von roslaunch zum Start eines oder mehrerer Knoten erfolgt der Start des Masters automatisch, sofern er nicht bereits läuft.
Der Master hat folgende Aufgaben:
- Er speichert, welche Nodes welche Themen publizieren beziehungsweise abonnieren.
- Er verwaltet die zur Verfügung gestellten Services.
- Er stellt Dienste für die Auffindung der Kommunikationspartner der Knoten zur Laufzeit zur Verfügung.
Das zuvor gezeigte Beispiel dient als Grundlage, den zweiten Punkt zu erläutern. Darin gibt es zwei Nodes: ein point_publisher_node und ein point_subscriber_node. Damit letzterer die Punktdaten des ersten empfangen kann, müssen folgende Abläufe stattfinden:
- Der point_publisher_node informiert den Master, dass er Punktdaten unter dem Topic /point publizieren möchte (s. Abb. 2). Da noch kein Node das Topic abbonniert hat, erfolgt zunächst keine Datenübertragung.
- Der point_subscriber_node informiert den Master, dass er unter dem Thema /point veröffentlichte Punktdaten abonnieren möchte.
- Da nun sowohl ein Node existiert, der Daten unter dem Topic /point publiziert, als auch einer, der Daten zum Thema /point abonniert, informiert der Master die beiden Knoten über die Existenz des jeweils anderen, und der Datentransfer kann beginnen.
