ROS 2 Nodes, Topics, Services und Actions

Das Robot Operating System 2 (ROS 2) lässt unabhängig laufende Programme typisierte Daten tauschen. Kameratreiber, Motorsteuerung, Planer und Bedienoberfläche können getrennte Nodes sein, verbunden über den ROS-Graphen. Die wichtige Entwurfsentscheidung ist nicht nur der Nachrichtentyp; es ist, ob die Interaktion ein Strom, eine kurze Anfrage oder ein langlaufendes Ziel ist.

Diese Anleitung bleibt distributionsneutral. Kommandos und Kernkonzepte sind stabil, aber Installationsdetails und Paketversionen sollten der Dokumentation der ROS-2-Version folgen, die du wirklich nutzt.

Modelliere eine Verantwortung pro Node

Eine Node ist ein Teilnehmer im ROS-Graphen. Gute Nodegrenzen folgen Verantwortungen: Ein Lidartreiber publiziert Scans, eine Odometrie-Node schätzt Bewegung, ein Navigator nimmt Ziele an. Mache nicht jede Funktion zur Node — Prozess- und Kommunikationsoverhead lohnen sich, wenn die Grenze Wiederverwendung, Isolation, Deployment oder Zuständigkeit verbessert.

Namen machen den Graphen verständlich. Nutze sprechende Node- und Schnittstellennamen wie /front_lidar, /wheel_odometry und /cmd_vel. Namespaces lassen zwei Roboter äquivalente Graphen ohne Kollisionen fahren.

Inspiziere ein laufendes System, bevor du es änderst:

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info zeigt Publisher, Subscriber, Service-Server/Clients und Actions an dieser Node. Es ist oft der schnellste Weg, eine fehlende oder falsch benannte Schnittstelle zu finden.

Nutze Topics für kontinuierliche Ströme

Ein Topic ist asynchrone Publish/Subscribe-Kommunikation. Publisher senden typisierte Nachrichten ohne auf direkte Antwort zu warten, und beliebig viele Subscriber können sie empfangen. Topics passen zu Daten, die sich über Zeit ändern:

• Kamerabilder und Lidarscans;
• Gelenkzustände und Radodometrie;
• Batteriestatus;
• kommandierte Geschwindigkeit;
• Diagnoseereignisse.

Prüfe einen Strom von der Kommandozeile:

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

Der Nachrichtentyp ist Teil des Vertrags. Koordinatensysteme, Einheiten, Zeitstempel und Kovarianz sind genauso wichtig wie Feldnamen. Ein Subscriber kann eine Position nicht sicher interpretieren, wenn er nicht weiß, ob der Wert Meter in map oder Millimeter in einem Kamerasystem ist.

Quality-of-Service-Einstellungen (QoS) beeinflussen Zustellung. Sensorströme bevorzugen oft aktuelle Daten gegenüber erneutem Senden alter Abtastungen, während zustandsartige Konfiguration zuverlässiges oder transient-lokales Verhalten brauchen kann. Publisher und Subscriber mit inkompatiblen QoS-Richtlinien können im Graphen erscheinen, aber keine Daten tauschen.

Nutze Services für kurze Anfrage und Antwort

Ein Serviceclient sendet eine Anfrage und wartet auf die Serverantwort. Services taugen für schnelle Operationen mit definitiver Antwort:

• Konfiguration lesen oder setzen;
• Odometrie zurücksetzen;
• Karte löschen;
• fragen, ob eine Komponente bereit ist.

Sie taugen schlecht für kontinuierliche Sensordaten oder ein Manöver, das Sekunden dauern kann. Ein synchroner Aufruf, der auf eine langsame Motoraktion wartet, kann einen Aufrufer blockieren und liefert weder Fortschrittsfeedback noch Abbruch standardmäßig.

Inspiziere und rufe einen Service mit:

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

Der exakte Typ im letzten Kommando muss zum Server passen. Entwerfe Antworten so, dass sie Transporterfolg und sinnvolle Operationszustände melden; eine erhaltene Antwort garantiert nicht, dass die gewünschte Hardwareaktion möglich war.

Nutze Actions für langlaufende Ziele

Eine Action modelliert ein Ziel, das Zeit braucht. Sie unterstützt Zielannahme, periodisches Feedback, Endergebnis sowie Abbruch oder Verdrängung. Navigation zu einer Pose und Armbewegung durch eine Trajektorie sind natürliche Actions.

Die Interaktion hat drei semantische Teile:

• Goal: was der Client will, etwa eine Zielpose.
• Feedback: Fortschritt während der Ausführung, etwa Restdistanz.
• Result: Endausgang und etwaige Rückdaten.

Actionserver sollten auf Abbruch zügig antworten und Hardware in dokumentiertem Zustand hinterlassen. Ein Client sollte Ablehnung, Abbruch, Abbruchfehler und Erfolg behandeln statt jedes Endergebnis als Fertigstellung zu werten.

Von der Kommandozeile:

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Ersetze Platzhalter durch Typ und Felder, die der laufende Graph meldet. Nutze das Kommando, um Verhalten zu inspizieren, nicht als festverdrahtete Produktionsschnittstelle.

Wähle mit einer Entscheidungstabelle

Ein Topic ist nicht automatisch „schnell“, und ein Service nicht automatisch „zuverlässig“. Timing und Zustellung hängen von QoS, Middleware, Executors, Last und Netz ab. Wähle zuerst nach Interaktionssemantik.

Ein Verhalten kann alle drei nutzen. Eine Navigationsnode abonniert Scan- und Odometrie-Topics, nimmt eine Navigations-Action an und bietet einen kurzen Service zum Löschen einer Costmap. Die Grenzen bleiben klar, weil jede Schnittstelle eine andere Art Frage beantwortet.

Entwirf einen kleinen Mobilroboter-Graphen

Betrachte einen Differenzialantriebs-Roboter:

1. /encoder_driver publiziert Radzählwerte.
2. /odometry abonniert Zählwerte, publiziert /odom und sendet odom → base_link.
3. /range_driver publiziert Distanzmessungen.
4. /safety_controller abonniert Distanzen und begrenzt /cmd_vel.
5. /navigator nimmt eine Bewegungs-Action an und publiziert Sollgeschwindigkeit.

Lasse nicht zwei fremde Nodes ohne Arbitrierung die Motoren kommandieren. Gib einer Komponente Eigentum am finalen Aktorkommando oder mache die Prioritätsregel explizit.

Nutze Standard-ROS-Nachrichtentypen, wenn ihre Semantik passt. Eigene Schnittstellen taugen, wenn der Datenvertrag ehrlich projektspezifisch ist — nicht nur, um vorhandene Felder umzubenennen.

Debugge den Graphen Schicht für Schicht

Wenn Daten fehlen:

1. Bestätige, dass beide Nodes in ros2 node list erscheinen.
2. Bestätige Schnittstellennamen und -typen.
3. Inspiziere Publisher/Subscriber-Zahlen.
4. Vergleiche QoS-Richtlinien.
5. Echoe eine Nachricht und prüfe Zeitstempel/Frame-IDs.
6. Prüfe Logs und Executor-Last.

Wenn eine Action nie fertig wird, unterscheide „Ziel nicht angenommen“, „Server produziert kein Feedback mehr“ und „Client ignorierte das Ergebnis“. Wenn ein Service hängt, prüfe, ob der Servercallback auf Arbeit blockiert wartet, die eine Action hätte sein sollen.

Vermeide die gängigen Architekturfehler

• Alles nutzt ein Topic: Aufrufer können nicht wissen, ob eine einmalige Anfrage gelang.
• Bewegung nutzt einen Service: Lange Arbeit ohne Fortschritt und Abbruchsemantik.
• Sensordaten nutzen per Default eine zuverlässige tiefe Queue: Alte Abtastungen stauen sich, wenn die Verarbeitung hinterherhinkt.
• Frame- und Einheitenkonventionen sind undokumentiert: Typisierte Nachrichten bleiben semantisch mehrdeutig.
• Eine Riesen-Node besitzt jedes Subsystem: Testen und Fehlerisolation verschwinden.
• Dutzende Winz-Nodes wrappen normale Funktionen: Der Graph wird schwerer, ohne nützliche Grenze hinzuzufügen.

Der Roboterarm-Simulator liefert eine konkrete actionartige Aufgabe: Ziel anfordern, Bewegung beobachten und unerreichbare oder beschränkte Ausgänge melden. Weiter mit ROS-2-TF2-Koordinatensystemen, damit die Geometrie jeder Node konsistent bleibt.