Einen ROS-2-Roboter bauen, der sieht und zu einem Marker fährt

Was du baust

Einen Roboter, der irgendwo im Raum abgesetzt wird, sich dreht, bis er einen gedruckten Marker an einer Wand findet, und darauf zufährt – einen halben Meter davor stoppend, rechtwinklig zur Markerfläche statt bloß nahe dran.

Jeder andere Bau dieser Seite fährt ein Programm auf einem Mikrocontroller. Dieser hier ist ein Rechner mit Rädern – und das ändert, worum es im Projekt geht. Die schweren Teile sind nicht mehr Timing und Verdrahtung; sie heißen: zu wissen, wo Dinge relativ zueinander sind, und mehrere Softwarestücke ehrlich zueinander zu halten, während alle zugleich laufen.

Warum dieser Roboter einen Rechner braucht

Ein Arduino kann das nicht – und der Grund lohnt Präzision. Es ist nicht rohe Geschwindigkeit: Ein Kamerabild ist ein Viertel-Megabyte, ArUco-Erkennung will Gleitkomma-lineare-Algebra, und das alles muss geschehen, während die Räder weiter mit 50 Hz befohlen werden. Das ist ein Job für ein Betriebssystem mit echtem Speicher und echtem Scheduling.

Was man im Tausch für diese Linux-Kiste bekommt, ist die Fähigkeit, in einen laufenden Roboter hineinzuschauen. Jede Nachricht zwischen jedem Teil ist ein Topic, das man vom Laptop abonnieren kann. Fährt der Roboter am Marker vorbei statt darauf zu, fügt man keine Print-Statements hinzu und flasht neu – man lässt ros2 topic echo die Pose ausgeben und sieht ihr live beim Falschsein zu.

Die Form des Nodegraphen

Fünf Verantwortlichkeiten, eine Node pro Stück:

Die Schnittstellen machen die Strukturierung lohnend. Der Controller fasst nie Kamera oder Motor an – er verbraucht einen Transform und erzeugt einen Twist. Heißt: Man kann denselben Roboter per Tastatur-Teleop fahren, den Controller gegen einen Fake-Transform ganz ohne Hardware testen und später einen Navigationsstack einsetzen, der dasselbe Topic publiziert.

NODES, TOPICS, SERVICES UND ACTIONS lesen, bevor man eine eigene Version dieser Tabelle zeichnet. Der häufigste Fehler in dieser Phase: Den Andockregler zum Service machen – es ist ein langlaufendes Ziel, das man abbrechen können muss, was exakt das ist, wofür eine Action da ist.

Stückliste

Das ist der Zwei-Gehirne-Roboter, und die Stückliste spiegelt das: einen Rechner für Wahrnehmung und einen Mikrocontroller für die Dinge, die ein Rechner nicht verlässlich kann.

Gesamt: grob 145–175 $. Das ist mit Abstand das teuerste Projekt der Seite – und das meiste davon ist das Pi.

Versorgung ist der Ort, wo diese Roboter scheitern – und der Fehler ist teuer. Ein Brownout während eines SD-Kartenschreibens korrumpiert das ganze Systemabbild. Einen Schaltregler deutlich über dem Pi-Bedarf verwenden, die Schiene nie mit den Motoren teilen, und vcgencmd get_throttled prüfen – alles ungleich null heißt: Versorgung unzureichend und eine korrumpierte Karte kommt.

Die gedruckten Marker vermessen. Eine ArUco-Posenlösung skaliert direkt mit der deklarierten Markergröße. Ein Marker, gedruckt mit 95 % per Drucker-„An Seite anpassen“, liefert Posen, die bei jeder Entfernung 5 % falsch sind – und nichts in der Pipeline verrät es.

Baureihenfolge

1 – ROS 2 zum Laufen bringen und das Netz beweisen. ROS 2 auf einem Raspberry Pi installieren folgen. Nicht weitergehen, bis ros2 topic echo auf deinem Laptop ein Topic zeigt, das auf dem Roboter publiziert wird. Discovery über WLAN frisst am ehesten einen Abend – und soll ihn jetzt fressen statt beim Debuggen von Vision.

2 – Die Räder einen Twist gehorchen lassen. Arduino, Encoder und TB6612FNG verdrahten und die cmd_vel-Brücke bauen. Meilenstein: Tastatur-Teleop vom Laptop fährt den echten Roboter. Hier die Radseparation kalibrieren – alles Nachgelagerte erbt sie.

3 – Die Kamera kalibrieren. Ordentlich, mit echtem Target, nach Kamerakalibrierung und ArUco-Pose. Eine unkalibrierte Kamera erzeugt Posen, die plausibel aussehen und an den Bildrändern um Dutzende Prozent falsch sind – die schlimmste verfügbare Fehlermode.

4 – Den Marker als Transform publizieren. Nicht als eigene Nachricht mit einem x und y darin. camera_link → marker_7 in TF2 zu publizieren heißt: Der Controller kann fragen „wo ist der Marker, in base_link?“, und die Antwort berücksichtigt exakt die eigene Kameramontage – inklusive dass sie geneigt ist, was sie ist.

5 – Auf den Marker zufahren. Ein Proportionalregler auf Peilung: Darauf zudrehen, vorwärts fahren, im Sollabstand stoppen. Das funktioniert – und kommt schräg an, was der Sinn des nächsten Schritts ist.

6 – Entlang der Normalen anfahren. Statt auf den Marker zu lenken, einen Wegpunkt berechnen, der vor der Markerfläche entlang ihrer Normalen steht, dorthin fahren und erst dann gerade hineinfahren. Das ist der Unterschied zwischen Dock erreichen und Andocken. Hier beginnt die Markerorientierung – der Poseteil, den man bis jetzt nicht brauchte – zu zählen, und hier begegnet man Posenmehrdeutigkeit.

7 – In eine Zustandsmaschine wickeln. Suchen, Anfahren, Ausrichten, final, fertig – plus die Übergänge aus jedem, wenn der Marker verloren geht. Endliche Zustandsmaschinen für Roboterverhalten deckt die Struktur ab; das Spezielle, das dieser Roboter braucht, ist ein Marker-verloren-Timeout, das zur Suche zurückkehrt statt auf letzter bekannter Pose weiterzufahren.

Hardwarenotizen, die zählen

Die Kamera steif montieren, und wie vermessen. Jede Pose, die der Roboter rechnet, ist relativ zur Kamera – und TF2 verwandelt das per deinem deklarierten Transform von base_link zu camera_link in eine roboterrelative Pose. Eine Kamera an biegsamer Halterung macht diesen deklarierten Transform zur Lüge, die mit Beschleunigung variiert.

Die Kamera nach unten neigen, und das angeben. Eine Kamera zum Horizont verliert den Marker exakt, wenn der Roboter nahe kommt. Zehn bis fünfzehn Grad nach unten halten ihn durch die Endanfahrt im Bild – und diese Neigung gehört in den statischen Transform, nicht in einen Fudge-Faktor im Regler.

Den Marker mit Messschieber messen. Posenskalierung ist direkt proportional zur dem Löser genannten Markergröße. Mit 96 % zu drucken, weil der Drucker auf Passend skalierte, macht jede Entfernung 4 % falsch – lautlos und konsistent.

Das Pi getrennt von den Motoren speisen. Ein blockierender Motor drückt die Schiene – und wo ein Arduino harmlos zurücksetzen würde, korrumpiert ein Pi sein Dateisystem. Entweder ein separater Regler oder ein separater Pack – hier spart man kein Bauteil.

Das Kameraband von Motorleitungen fernhalten. Es ist eine ungeschirmte Hochgeschwindigkeitsverbindung. Eingekoppeltes Motorrauschen erscheint als korrumpierte Bilder – die als Detektionen erscheinen, die ohne sichtbaren Grund flackern.

Wie gut aussieht

Zwei Zeilen tragen die Lektion des ganzen Projekts.

Auflösung ist nicht gratis, und höher ist oft schlechter. Von 640×480 auf 1080p kostet 4–6× Verarbeitung für grob 1,7× Erkennungsreichweite. Wenn man nicht gezielt einen Marker weiter entfernt sehen muss, liefert das kleinere Bild eine schnellere, frischere Antwort – und Frische zählt in einer Regelschleife mehr als Präzision.

Die Latenzzeile erklärt die Zwei-Gehirne-Aufteilung. Bei 0,3 m/s sind 100 ms Visionslatenz 3 cm Fahrt; bei 90°/s Drehung 9° Rotation. Jede Visionsmessung beschreibt, wo der Roboter war. Darauf direkt eine schnelle Schleife zu schließen schwingt. Die funktionierende Struktur ist die, die dieser Roboter nutzt: Der Arduino fährt die schnelle Schleife auf Encodern, und Vision korrigiert sie langsam – exakt dieselbe Form wie GPS mit Odometrie auf dem Wegpunktrover zu fusionieren, aus exakt demselben Grund.

Rolling Shutter, wenn der Roboter schaut während er fährt

Die Standard-Pi-Kameramodule haben Rolling Shutter: Zeilen werden nacheinander belichtet – die Bildoberkante wird also wenige Millisekunden vor der Unterkante erfasst. Stationär unsichtbar. Bei 90°/s Drehung wurden die vier Ecken eines ArUco-Markers bei vier verschiedenen Roboterorientierungen erfasst – und die daraus gelöste Pose ist auf eine Art falsch, die keine Kalibrierung behebt.

Muss der Roboter Vision während der Fahrt betreiben, dafür ist das Global-Shutter-Modul da. Kann er es sich leisten zu stoppen, zu schauen und dann zu fahren, reicht das billigere Modul völlig – und Stoppen-zum-Schauen ist eine legitime Entwurfsentscheidung, kein Workaround.

Wenn es schiefgeht

Die Verteilung in dieser Tabelle lohnt Bemerken vor Beginn: Fast nichts davon ist Bildverarbeitung. Es sind Vernetzung, Frames, Einheiten und Regelung – was der Bau eines ROS-2-Roboters wirklich lehrt, und warum der Lernpfad ROS-2-Grundlagen seine Zeit mit Kommunikationsmustern und Koordinatenframes statt OpenCV verbringt.

Ist das ein Schritt zu weit, lehrt der Micromouse Kartierung und Planung auf Mikrocontroller ohne Linux, und der handygesteuerte Roboter deckt die „Befehle kommen übers Netz“-Hälfte dieses Problems für einen Bruchteil der Teile ab.