Inhalt
  1. Ein Knoten erfüllt eine logische Aufgabe
  2. Topics für fortlaufende Daten
  3. Services für Anfrage und Antwort
  4. Die entscheidenden Fragen liegen an den Grenzen
  5. Was ROS 2 nicht allein entscheidet
  6. Quellen

Ein mobiler Roboter verarbeitet Messwerte, schätzt seine Position und plant Bewegungen. Diese Aufgaben müssen nicht in einem einzigen großen Programm stecken. ROS 2 bietet Konzepte, um solche Funktionen in kommunizierende Softwarebausteine aufzuteilen.

Ein Knoten erfüllt eine logische Aufgabe

Die offizielle ROS-2-Dokumentation zu Nodes beschreibt Knoten als Teilnehmer im ROS-Graphen. Sie können innerhalb eines Prozesses, zwischen Prozessen oder über Rechnergrenzen hinweg kommunizieren. Ein sinnvoller Zuschnitt könnte beispielsweise einen Sensortreiber von der Positionsschätzung trennen.

Diese Aufteilung erleichtert es, einzelne Komponenten auszutauschen oder ihre Ausgaben zu beobachten. Sie nimmt dem Entwickler aber nicht die Aufgabe ab, eindeutige Zuständigkeiten zu schaffen. Wenn mehrere Bausteine widersprüchliche Fahrbefehle erzeugen, löst die Kommunikationsschicht den fachlichen Konflikt nicht automatisch.

Topics für fortlaufende Daten

Topics eignen sich laut Dokumentation für Datenströme wie Sensordaten und Roboterzustände. Ein Sender veröffentlicht Nachrichten zu einem benannten Topic; passende Empfänger abonnieren sie. Die Nachrichten besitzen definierte Typen. Trotzdem müssen sich die Beteiligten auch über die Bedeutung verständigen, etwa Einheiten und Koordinatensysteme.

Aufgabe Passendes Grundkonzept
Fortlaufende Sensormessung Topic
Kurze gezielte Anfrage Service
Länger laufender Auftrag Action-Konzept prüfen

Services für Anfrage und Antwort

Ein Service folgt dem Prinzip eines entfernten Funktionsaufrufs. Die Dokumentation sieht dafür kurze Vorgänge vor und verweist bei längeren, gegebenenfalls abzubrechenden Aufgaben auf Actions. Diese Unterscheidung verhindert, dass ein einfacher Aufruf unbegrenzt auf eine umfangreiche Bewegung wartet.

Die entscheidenden Fragen liegen an den Grenzen

Was bedeutet ein veralteter Messwert? Wie reagiert die Navigation, wenn ein Sensorknoten ausfällt? Wer erkennt, dass ein Auftrag nicht mehr fortgesetzt werden darf? Solche Regeln gehören zur Anwendung und sollten ausdrücklich beschrieben werden.

Auch Diagnoseinformationen brauchen einen Bezug zur Zeit und zum jeweiligen Systemstand. Eine aufgezeichnete Nachricht ist wenig hilfreich, wenn unklar bleibt, ob sie vor oder nach einer Konfigurationsänderung entstand. Für reproduzierbare Fehleranalyse sollten Softwareversionen und relevante Parameter nachvollziehbar sein.

Was ROS 2 nicht allein entscheidet

Ein einfacher Architekturplan kann für jeden Baustein Eingang, Ausgang und Fehlerstatus aufführen. Beim Sensorknoten ist das beispielsweise die Beziehung zwischen Rohmessung und veröffentlichter Nachricht. Bei der Navigation kommt hinzu, welcher Zustand bei fehlenden Daten erlaubt ist. Diese Beschreibung hilft auch Teams mit unterschiedlichen Fachrichtungen: Mechanik, Elektrik und Software können sich über die erwartete Wirkung verständigen, ohne jede interne Implementierung kennen zu müssen. So wird die modulare Struktur im Projekt tatsächlich nutzbar.

ROS 2 ist kein automatischer Nachweis für die Eignung einer gesamten Maschine. Echtzeitanforderungen, Schutzfunktionen und Betriebsgrenzen müssen gesondert betrachtet werden. Unsere Einordnung: Der größte Gewinn liegt in sauber beschriebenen Bausteinen und beobachtbarer Kommunikation. Wie industrielle Steuerungen dazu passen, erklärt unser Beitrag über SPS und KI.

Quellen & weiterführende Informationen