ROS-2-Grundlagen: Nodes, Frames und Roboter-Vision
Du kannst einen Roboter als ROS-2-Nodes strukturieren, Topics gegen Services und Actions korrekt wählen und die Beobachtungen einer Kamera im Frame-Baum des Roboters verorten.
Alles andere auf dieser Seite läuft auf einem Mikrocontroller: ein Programm, eine Schleife, volle Kontrolle. ROS 2 ist der Ort, zu dem man wechselt, wenn ein Roboter daraus herauswächst – wenn er Kamera, Planer und Treiberstack hat, die alle gleichzeitig laufen müssen, von verschiedenen Leuten geschrieben, einzeln neustartbar.
Der Preis ist eine neue Ideenmenge – und die erste lautet: Ein ROS-2-Roboter ist kein Programm, sondern ein Graph aus Nodes, die miteinander sprechen. Die meiste frühe Verwirrung besteht darin, zwischen den vier Sprechweisen falsch zu wählen – deshalb beginnt dieser Pfad dort: Topics für Ströme, Services für schnelle Anfragen, Actions für lange Jobs, die man eventuell abbrechen muss.
Dann TF2 – der Teil, der Leute leise besiegt. Ein Roboter ist ein Baum aus Koordinatenframes – Basis, Räder, jeder Sensor –, und fast jeder echte Fehler ist ein Transform, der fehlt, veraltet ist oder am falschen Elternteil hängt. Sobald Frames Sinn ergeben, wird eine kalibrierte Kamera einfach eine weitere Node, die eine Pose in diesen Baum publiziert – genau so schließt sich Vision dem restlichen Roboter an.
Bevor du beginnst
Du solltest dich auf einer Linux-Kommandozeile wohlfühlen und Python oder C++ lesen können. Ein Raspberry Pi ist das übliche Ziel, aber alles bis zu den Hardwarenodes läuft auf einem Laptop. Das Setup selbst dauert einen Abend einplanen – ROS 2 ist ein verteiltes System und verhält sich vom ersten Befehl an wie eines.
Was du danach kannst
- Korrekt zwischen Topic, Service und Action wählen, statt alles zum Topic zu machen und die Grenzen später zu entdecken.
- Einen TF2-Frame-Baum bauen, der einen Punkt vom Sensorframe in den Roboter transformiert – und ihn debuggen, wenn ein Transform fehlt.
- Eine Kamera kalibrieren, die Pose eines Markers bestimmen und verstehen, relativ wozu die Zahlen gelten.
- Einen
cmd_vel-Twist in linke und rechte Raddrehzahl umwandeln – mit Sättigung, die den befohlenen Bogen erhält.
Wo die meisten feststecken
Nodes sehen sich nicht. ROS-2-Discovery funktioniert automatisch – bis es das nicht tut. Zwei Rechner mit verschiedenen ROS_DOMAIN_ID-Werten sind füreinander unsichtbar, und WLAN, das Multicast blockiert, bricht Discovery vollständig, während jede Node sich als kerngesund meldet.
Unpassendes QoS. Ein Publisher mit Best-Effort und ein Subscriber, der Reliable verlangt, verbinden sich nie – und hilfreicherweise loggt keiner einen Fehler. Das Topic transportiert einfach nichts. Sensordaten sind der übliche Schuldige, da Sensortreiber oft standardmäßig Best-Effort liefern.
Vergessen, den Workspace zu sourcen. Ein neues Terminal kennt deine Pakete nicht, bis es gesourct wird – also meldet ros2 run ein eindeutig vorhandenes Paket als fehlend.
Ein Frame mit zwei Eltern. TF2 ist ein Baum. Denselben Kindframe aus zwei Quellen zu publizieren gibt ihm zwei Eltern – Lookups scheitern intermittierend je nach Timing: einer der schwerer sichtbaren ROS-Fehler, weil es meistens funktioniert.
Leere Zeitstempel und Frame-IDs. Eine Nachricht ohne frame_id im Header lässt sich nicht transformieren, und eine mit Nullstempel passt zu nichts. Beide passieren das Typsystem ohne Beanstandung und scheitern erst, wenn etwas versucht, sie gemeinsam zu nutzen.
Was du brauchst
| Was | Warum dieser Pfad es braucht | Hinweise |
|---|---|---|
| Eine Linux-Kommandozeile, in der du dich wohlfühlst | ROS 2 ist ein Linux-first-System und die Werkzeuge setzen das voraus | Ubuntu passt zu den offiziellen Binärpaketen; alles andere heißt Bauen |
| Python oder C++ | Nodecode wird in einer der beiden geschrieben | Python ist zum Lernen schneller; C++ nutzen die zeitkritischen Nodes |
| Einen Rechner mit echtem Bildschirm | Ein verteiltes System über SSH zu debuggen ist unnötig schmerzhaft | Ein Laptop ist das bessere Lernziel als ein headless Pi |
| Einen Raspberry Pi (nur Hardwarenodes) | Erst nötig, wenn der Roboter seinen eigenen Rechner trägt | Pi 4 oder besser; ein Pi Zero enttäuscht |
| Eine Kamera (nur Visionsnode) | Die letzte Station des Pfads | Ein Pi-Kameramodul oder eine beliebige UVC-Webcam |
| Einen Abend fürs Setup | Kein Scherz – das gehört zum Pfad | Installation ist wirklich der erste schwere Schritt |
Warum der Pfad in dieser Reihenfolge läuft
Kommunikationsmuster kommen zuerst, weil falsche Wahl später teuer wird. Die vier Sprechweisen von ROS-2-Nodes sind nicht austauschbar – und der Standard-Anfängerfehler ist, alles zum Topic zu machen, um dann, dreihundert Zeilen später, zu entdecken, dass man Abbruch und Fortschrittsmeldungen gebraucht und Actions von Hand nachgebaut hat. Zehn Minuten Entscheidung zwischen Topic, Service und Action sparen ein Umschreiben.
TF2 kommt als Zweites, weil es der Teil ist, der Leute leise besiegt. Sobald mehrere Nodes Daten über die physische Welt publizieren, meint jede mit „3 Meter“ etwas anderes relativ zu etwas anderem – Kamera, Basis, Karte. TF2 beschreibt, wie das zusammenhängt, und die Mehrheit echter ROS-Fehler ist ein Transform, der fehlt, veraltet ist oder am falschen Elternteil hängt. Es als Thema zu lernen, bevor man es braucht, ist weit billiger, als ihm als mysteriösem Lookup-Fehler zu begegnen.
Kamerakalibrierung kommt als Drittes, weil sie vollständig vom Zweiten abhängt. Eine Markerpose ist bedeutungslos, ohne zu wissen, relativ wozu sie gilt. Sobald Frames Sinn ergeben, ist eine kalibrierte Kamera einfach eine weitere Node, die eine Pose in den Baum publiziert – und Vision hört auf, ein Sonderfall zu sein.
Die Antriebsnode schließt den Pfad, weil dort ROS auf die Hardware trifft, von der alles andere auf dieser Seite handelt. Ein cmd_vel-Twist ist die Standardschnittstelle, die jede ROS-Navigationskomponente spricht – und ihn in linke und rechte Raddrehzahl zu verwandeln, mit Sättigung, die den befohlenen Bogen erhält statt verzerrt, ist die Brücke zwischen ROS-Welt und Motorwelt.
Kontrollpunkte: Woran man merkt, dass eine Stufe sitzt
| Stufe | Die Prüfung | Wie Bestanden aussieht |
|---|---|---|
| Installation | ros2 topic list in einem frischen Terminal |
Es funktioniert nach dem Sourcen, und du weißt, warum es vorher scheitert |
| Zwei Nodes | Talker und Listener auf zwei Rechnern laufen lassen | Nachrichten kommen an – und du kannst die gemeinsame Domain-ID nennen |
| Topic gegen Service | Je eines für dieselben Daten schreiben | Du kannst in einem Satz sagen, warum jedes Muster zu seinem Job passt |
| Actions | Eine lange Action starten und mittendrin abbrechen | Sie stoppt sauber, und du hast unterwegs Feedback erhalten |
| QoS | Absichtlich Reliable auf einem Topic fehlpassen | Es transportiert lautlos nichts – jetzt erkennst du das Symptom |
| TF2-Baum | ros2 run tf2_tools view_frames laufen lassen |
Ein Baum, eine Wurzel, kein Frame mit zwei Eltern |
| Transform-Lookup | Einen Punkt vom Sensorframe in den Basisframe transformieren | Die Zahl stimmt, und du kannst sie gegen ein Maßband prüfen |
| Veraltete Transforms | Einen Transform-Publisher stoppen, während ein Lookup läuft | Ein Extrapolationsfehler kommt – der Fehler hat jetzt einen Namen |
| Kamerakalibrierung | Kalibrieren und den Reprojektionsfehler prüfen | Deutlich unter einem Pixel; ein großer Wert heißt: schlechte Aufnahmeserie |
| Markerpose | Einen Marker in gemessenem Abstand platzieren und seine Pose lesen | Stimmt mit dem Maßband überein, und du kannst sagen, in welchem Frame sie gilt |
cmd_vel |
Einen Twist mit Linear- und Winkelanteil publizieren | Beide Räder drehen korrekt, und Sättigung des einen skaliert das andere zum Bogenerhalt |
Wo dieser Pfad endet
Dieser Pfad baut die Grundlagen unter einem ROS-2-Roboter – wie Nodes sprechen, wie Frames zusammenhängen und wie Sensor und Antriebsstrang in den Graph kommen. Er endet bewusst vor den großen Subsystemen, die all das voraussetzen.
Kein Nav2-Stack – die Standardantwort auf autonome Navigation in ROS 2 und ein erhebliches System für sich: Costmaps, Behaviour Trees, Planer und Controller, alles konfiguriert statt geschrieben. Nav2 setzt einen funktionierenden TF-Baum und eine cmd_vel-Schnittstelle voraus – genau das, was dieser Pfad liefert.
Keine URDF und Roboterbeschreibung – das XML-Format, das dem restlichen ROS sagt, welche Form dein Roboter hat. Alles hier publiziert Transforms von Hand; URDF heißt, damit aufzuhören.
Keine Simulation in Gazebo – so geschieht die meiste ernsthafte ROS-Entwicklung tatsächlich –, kein ros2_control, die Standard-Hardwareabstraktion für echte Antriebe.
Und kein Echtzeitverhalten. ROS 2 baut auf DDS auf und kann hier weit mehr als ROS 1 – aber ein Linux-Rechner mit Python-Node ist kein Echtzeit-Regelsystem. Die engen Schleifen – Balancieren, Stromregelung, alles bei einem Kilohertz – gehören weiter auf einen Mikrocontroller, mit ROS 2 darüber. Diese Aufteilung ist die normale Architektur eines ernsthaften Roboters, kein Kompromiss.
Lern-Roadmap
Der Pfad
Folge den Knoten der Reihe nach – jeder schaltet den nächsten frei, sobald du ihn erledigt hast. Dein Fortschritt wird auf diesem Gerät gespeichert.
0 / 5 erledigt
Häufige Fragen
Häufig gestellte Fragen
Wann sollte ein Roboter von Arduino zu ROS 2 wechseln?
Wenn eine Schleife nicht mehr reicht. Ein Mikrocontroller mit einem einzigen Programm ist die richtige Architektur für einen Linienfolger, einen Labyrinthlöser oder alles, dessen Gesamtverhalten in eine Regelschleife passt – und er ist für diese ehrlich besser als ROS 2, weil deterministisch und komplett im Kopf behaltbar. ROS 2 verdient seine Komplexität, wenn ein Roboter mehrere Dinge gleichzeitig mit verschiedenen Raten laufen lassen muss – eine Kamerapipeline, einen Planer, einen Treiberstack –, zu verschiedenen Zeiten geschrieben, einzeln neustartbar. Der Preis ist ein verteiltes System, und es verhält sich vom allerersten Befehl an wie eines.
Topic, Service oder Action – wie wähle ich in ROS 2?
Das Kommunikationsmuster zum Job passend wählen. Ein Topic ist ein Strom ohne Antwort: Sensordaten, Odometrie, Geschwindigkeitsbefehle – alles, was fortlaufend publiziert wird und wo der neueste Wert zählt. Ein Service ist eine schnelle Anfrage mit Antwort, für Dinge, die in Millisekunden erledigt sind, wie einen Parameter abfragen oder einen Modus umschalten. Eine Action ist für lange Jobs, von denen man Fortschritt haben oder die man abbrechen können will – zu einem Ziel navigieren oder einen Greifer an einem Objekt schließen. Der häufigste Anfängerfehler ist, alles zum Topic zu machen und dann Anfrage-Antwort-Semantik von Hand darauf zu bauen.
Warum sehen sich meine ROS-2-Nodes nicht?
Drei Ursachen decken fast alles ab. Unterschiedliche ROS_DOMAIN_ID-Werte machen zwei Rechner gegenseitig völlig unsichtbar, während beide sich selbst als kerngesund melden. WLAN-Netze, die Multicast blockieren, brechen das Discovery-Protokoll vollständig – weshalb sich Nodes über Ethernet oft finden und über den Büro-Access-Point nicht. Und unpassendes QoS – ein Publisher bietet Best-Effort, ein Subscriber verlangt Reliable – heißt: Beide verbinden sich nie, und keiner loggt einen Fehler. Zuerst die Domain-ID prüfen; das kostet nichts und ist die häufigste Antwort.
Was ist TF2 und warum schlagen Transforms ständig fehl?
TF2 pflegt den Baum der Koordinatenframes eines Roboters – Basis, Räder und jeder Sensor –, damit man fragen kann, wo ein Punkt im Kameraframe im Roboterframe sitzt. Lookups scheitern aus drei wiederkehrenden Gründen. Ein Frame mit zwei Eltern bricht den Baum – und weil es nur davon abhängt, welcher Publisher das Timing gewann, funktioniert es meistens. Eine leere frame_id im Nachrichtenheader heißt: Die Nachricht lässt sich gar nicht transformieren. Und ein Null- oder veralteter Zeitstempel heißt: Der Transform existiert, aber nicht zu der Zeit, nach der gefragt wurde. Alle drei passieren das Typsystem ohne Beanstandung.
Brauche ich einen Raspberry Pi, um ROS 2 zu lernen?
Nein. Alles außer den Hardware-Treiber-Nodes läuft perfekt auf einem Laptop – und dort lernt es sich besser: schnellere Builds, echter Bildschirm, kein Risiko, dass eine SD-Kartenkorruption einen Abend kostet. Ein Pi wird nötig, wenn der Roboter seinen eigenen Rechner tragen soll. Wer einen nutzt, sollte einkalkulieren, dass der Pi die Grenze ist: Eine Kamerapipeline und ein Planer zusammen finden die Grenzen eines Pi 4 schnell.
Warum meldet ros2 run, mein Paket existiere nicht, obwohl es eindeutig da ist?
Der Workspace wurde in diesem Terminal nicht gesourct. Jedes neue Terminal weiß nichts über gebaute Pakete, bis das Install-Setup-Skript gesourct wird – und ROS meldet das Ergebnis als fehlendes Paket statt als ungesourcte Umgebung. Es ist die häufigste ROS-2-Kleinigkeit, sie erwischt alle wiederholt, und die Standardmilderung ist, es aus dem Shell-Profil zu sourcen – mit dem Vorbehalt, dass das das Problem dann versteckt, wenn man wirklich zwei Workspaces hat.