ROS 2-Einführung – Sichere Verteilung der Robotersteuerung auf Knoten, Themen und DDS

ROS 2 ist nicht der Roboter selbst. Es bildet die Grundlage für die Ausführung von Kameratreiber, Selbstlokalisierung, Pfadplanung und Motorsteuerung als separate Programme (Knoten) und deren Kombination über standardisierte Nachrichtenübermittlung und Kommunikation. Sie können mit einer einzelnen Python-Datei im Prototypenstadium beginnen und später auf C++, Echtzeitausführung, mehrere Computer und Sicherheitsüberwachung für ein fertiges Produkt skalieren. Entscheidend ist nicht das Auswendiglernen der API, sondern die Gestaltung der Datenhoheit, des Timings, der Zuverlässigkeit und des sicheren Zustands beim Herunterfahren.

ROS 2

Bild: Robot Operating System logo, Wikimedia Commons (CC BY-SA 4.0). Das Logo kennzeichnet die Middleware und garantiert keine bestimmte Distribution oder DDS-Konfiguration.

30-Sekunden-Zusammenfassung

• Ein Knoten ist ein Prozess mit einer einzigen Aufgabe, ein Thema repräsentiert einen kontinuierlichen Datenstrom, ein Dienst repräsentiert eine kurze Anfrage/Antwort und eine Aktion repräsentiert eine längere Aufgabe mit Zwischenrückmeldungen.

• Die Kommunikation von ROS 2 läuft über DDS, und QoS (Zuverlässigkeit, Historie, Tiefe, Dauerhaftigkeit, Frist) kann pro Endpunkt gewählt werden. Sensoren und Steuerung müssen nicht dieselben Einstellungen verwenden.

• TF2 verwaltet einen Baum von Koordinatenrahmen zusammen mit der Zeit. Werden map, odom, base_link und Sensorrahmen vermischt, fährt der Roboter an den falschen Ort, selbst wenn die Wahrnehmung korrekt ist.

• Auf realer Hardware sollten Lebenszyklusmanagement, Watchdogs, Privilegientrennung, Protokollierung und Ausfallsicherungen für Netzwerkausfälle implementiert werden. Die Arbeit in einer Simulation ist kein Sicherheitsnachweis.

• Beheben Sie von Anfang an das Problem mit einer Langzeitunterstützungsversion wie ROS 2 Jazzy zusammen mit einer passenden Kombination aus DDS, Betriebssystem und Treiber und erstellen Sie eine reproduzierbare Arbeitsumgebung.

1. Das große Ganze von ROS 2

Abbildung 1 – In ROS 2 erkennen und kommunizieren Knoten über einander. DDS. Nicht nur Themennamen, sondern auch QoS, Typ, Zeit und Koordinatenrahmen werden als Teil des Vertrags behandelt.

Ein ROS-2-Graph kann zur Laufzeit konfiguriert werden. Ein Kameraknoten veröffentlicht Bilder, ein Wahrnehmungsknoten abonniert diese, und ein Steuerknoten verarbeitet die Ergebnisse, führt die Selbstlokalisierung durch und veröffentlicht Geschwindigkeitsbefehle. Selbst wenn ein Knoten auf einen anderen Computer verschoben wird, bleibt der Graph bestehen, solange die DDS-Erkennung und -Serialisierung korrekt funktionieren.

2. Auswahl des richtigen Kommunikationsprimitivs

Parameter | Startzeit oder Konfiguration für niedrige Frequenzen | Verstärkung, Frame-Namen | Typ, Änderungsberechtigungen, Reproduzierbarkeit |

Eine Topic-Nachricht sollte neben dem Wert auch header.stamp und frame_id enthalten. Sind Bild- und IMU-Zeitstempel nicht synchron, kann der Algorithmus zwar ein Ergebnis berechnen, die Bewegung wird jedoch falsch eingeschätzt. Das erneute Senden von Kamerabildern mit hoher Zuverlässigkeit kann die Bandbreite überlasten. Wählen Sie daher die QoS passend zu den Eigenschaften jedes Sensors.

3. QoS als „Kommunikationsvertrag“

Die minimalen QoS-Einstellungen, die in ROS 2 überprüft werden sollten, sind: Zuverlässigkeit (Best Effort/Zuverlässig), Dauerhaftigkeit (Volatil/Transient Local), Verlauf (Letzten Eintrag behalten/Alle behalten), Tiefe, Frist und Lebendigkeit. Ein LiDAR mit hoher Datenrate eignet sich möglicherweise gut für Best Effort, da dieses veraltete Pakete verwirft. Geschwindigkeitsbefehle hingegen, die keine Nachrichtenverluste tolerieren, sollten Reliable mit einer kurzen Deadline verwenden.

Wenn die QoS von Publisher und Subscriber nicht kompatibel sind, kommunizieren sie selbst unter demselben Topic-Namen nicht. Überprüfen Sie die tatsächlichen Einstellungen mit ros2 topic info -v /scan, anstatt blind den Voreinstellungen eines Sensortreibers zu vertrauen. Testen Sie beim Überqueren eines Netzwerks MTU, WLAN-Retransmission, Multicast-Beschränkungen und Zeitsynchronisation gleichzeitig.

4. TF2 und Zeit

Die Position eines Roboters wird als Transformation zwischen Koordinatensystemen ausgedrückt. Ein typischer Baum sieht wie folgt aus:

map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
                                                        ├── base_laser
                                                        ├── imu_link
                                                        └── camera_link

map ist das langfristige Weltkoordinatensystem, odom ist die glatte Kurzzeit-Odometrie und base_link ist das Fahrzeugreferenzsystem. SLAM korrigiert map → odom, während die Rad-/IMU-Schätzung odom → base_link mit hoher Frequenz aktualisiert. TF2 speichert Transformationen mit Zeitstempeln und interpoliert sie auf die Erfassungszeit jedes Sensors.

Koordinatensysteme werden als rechtshändig standardisiert, und der Unterschied zwischen dem optischen Koordinatensystem (z vorwärts, x rechts, y unten) und dem Fahrzeugkoordinatensystem (x vorwärts, y links, z oben) wird explizit dargestellt. Statische Transformationen werden mit static_transform_publisher korrigiert, und dynamische Transformationen werden nicht als statisch veröffentlicht. Zyklen oder mehrere übergeordnete Elemente im TF-Baum stellen einen Designfehler dar.

5. Pakete und Implementierungsablauf

Ein minimaler ROS 2 Python-Knoten sieht folgendermaßen aus:

import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32

class Speed(Node):
    def __init__(self):
        super().__init__('speed_node')
        self.pub = self.create_publisher(Float32, '/speed', 10)
        self.timer = self.create_timer(0.02, self.tick)  # 50 Hz
    def tick(self):
        msg = Float32(); msg.data = 0.2
        self.pub.publish(msg)

rclpy.init(); node = Speed(); rclpy.spin(node)

Senden Sie auf realer Hardware keine Geschwindigkeitsbefehle direkt an den Motor. Platzieren Sie stattdessen einen vorgelagerten Knoten, eine Geschwindigkeitsbegrenzung, einen Not-Aus und eine Hardwareüberwachung dazwischen. Auch bei Verwendung von rclcpp in C++ sollten Sie Callback-Gruppen, den Executor, die Speicherverwaltung und das Echtzeitverhalten überprüfen.

Unterteilen Sie den Arbeitsbereich in src, build, install und log und lösen Sie Abhängigkeiten mit rosdep auf. Fixieren Sie Betriebssystem, DDS und Compiler mit Docker oder einem Entwicklungscontainer und kompilieren Sie ros2 doctor, ros2 node list, ros2 topic hz und tf2_tools sowohl für die CI-Pipeline als auch für die Felddiagnose.

6. Lebenszyklus und Sicherheit

Sensoren und Aktoren sollten nicht unbedingt sofort nach dem Einschalten Befehle entgegennehmen. Die Zustandsübergänge des Lebenszyklusknotens – Nicht konfiguriert → Inaktiv → Aktiv → Abgeschlossen – trennen Treiberinitialisierung, Kalibrierung, Kommunikationsprüfungen und Ausgabeautorisierung. Wenn ein Watchdog sein Signal verliert, setzen Sie den Geschwindigkeitsbefehl auf Null und öffnen Sie die Bremse oder das Relais hardwareseitig.

Im Hinblick auf die Sicherheit erfüllt die Nachrichtenkommunikation von ROS 2 allein nicht die Standards für funktionale Sicherheit. Prüfen Sie den Anwendungsbereich von IEC 61508/ISO 26262/ISO 13849 und ähnlichen Normen und trennen Sie Sicherheitsfunktionen in ein Überwachungssystem, einen zertifizierten Mikrocontroller und einen physischen Not-Aus-Schalter. Verwenden Sie bei der Netzwerkanbindung SROS 2-Schlüssel und -Zertifikate, DDS-Sicherheit, Zugriffskontrolle und Protokollprüfung.

7. Aktuelles Ökosystem und Forschung

Nav2 integriert Selbstlokalisierung, Kartierung, Pfadplanung und Steuerung durch Aktionen und Lebenszyklusmanagement. ros2_control standardisiert die Schnittstelle zwischen Hardware und Controllern. MoveIt 2 übernimmt die Kinematik, Kollisionsprüfung und Trajektorienplanung eines Manipulators. Simulationen in Gazebo oder Webots und die Wiedergabe von Sensordaten mit rosbag2 ermöglichen Regressionstests, ohne den realen Roboter anzuhalten.

Die Forschung schreitet voran in den Bereichen Zero-Copy-Kommunikation, typisierte Bildverarbeitungspipelines mit GPUs/NPUs, deterministische Executors, verteiltes Lernen und Cloud-Robotik, die über DDS hinausgeht. Bei der Einführung neuer Funktionen sollten neben Benchmarks auch Netzwerkausfälle, Zeitabweichungen, Prozessneustarts, Sensorausfälle und fehlerhafte Nachrichtenlängen getestet werden.

Zusammenfassung

ROS 2 verwandelt einen Roboter von einer Ansammlung von Teilen in ein wiederverwendbares, verteiltes System. Definieren Sie die Verantwortlichkeiten der Knoten, die QoS der Themen, die Koordinaten und das Timing von TF2, den Lebenszyklus und die sicheren Zustände im Voraus. So bleibt das gesamte System auch beim Austausch von Algorithmen robust.

Referenzen

• Offizielle ROS 2-Dokumentation
• ROS 2 Quality of Service-Einstellungen
• ROS 2 tf2
• DDS Foundation
• Nav2-Dokumentation
• ros2_control