ROS 2 TF2-Koordinatensysteme für mobile Roboter

Ein Laserscan wird relativ zum Laser gemessen, eine Radodometrie-Pose relativ zu ihrem Startframe, und ein Navigationsziel steht meist in einer Karte. Um sie zu vergleichen, braucht der Roboter die geometrische Beziehung zwischen Koordinatensystemen zur korrekten Zeit. Das TF2-System von ROS 2 speichert und befragt diesen zeitveränderlichen Transformationsbaum.

Die meisten TF2-Fehler sind keine höhere Mathematik. Sie sind ein fehlender Parent, eine verdrehte Transformation, ein falscher Zeitstempel oder zwei Nodes, die Eigentum an derselben Framebeziehung beanspruchen.

Denke in Transformationen, nicht kopierten Posen

Eine Transformation beschreibt Translation und Rotation von einem Parentframe zu einem Kindframe. Wenn base_link → laser sagt, der Laser sitze 0,20 m vorn und 0,10 m über der Roboterbasis, kann TF2 Lasermessungen ins Basisframe transformieren. Kombiniert mit odom → base_link stehen sie in lokalen Odometriekoordinaten.

Frames bilden einen Baum: Jedes Kind hat zu einer Zeit exakt einen Parent. Ein Link kann sich bewegen, aber die Parentbeziehung darf nicht mehrdeutig sein. Schleifen wie A → B → C → A sind ungültig.

Frame-IDs sind semantische Namen, keine Einheiten oder Daten. Ein mit laser gestempelter Punkt braucht trotzdem eine passende Transformation zu seinem Messzeitpunkt.

Nutze die Standardkette für mobile Roboter

Ein gängiger Navigationsbaum ist:

map → odom → base_link → laser
                       → camera_link
                       → imu_link

Jeder Link hat einen eigenen Job:

• map → odom: globale Lokalisierungskorrektur. Kann sich ändern, wenn Lokalisierung aufgehäufte Drift korrigiert.
• odom → base_link: glatte lokale Bewegung aus Rad-/visueller/inertialer Odometrie. Sollte stetig bleiben, darf aber driften.
• base_link → sensor: feste Einbaugeometrie, normal eine statische Transformation.

Map und odom zu trennen lässt globale Korrekturen zu, ohne das lokale Regelframe springen zu lassen. Die Namen folgen ROS-Konventionen, aber dein Roboter kann base_footprint, Gimbalframes oder Gelenklinks ergänzen.

Entscheide, wer jede Kante publiziert

Schreibe vor dem Start der Nodes eine Eigentumstabelle:

Exakt eine maßgebliche Komponente sollte jede Kante publizieren. Zwei Publisher erzeugen alternierende oder widersprüchliche Transformationen, die wie zufällige Posesprünge aussehen können.

Statische Transformationen beschreiben vermessene Einbaugeometrie. Lege Ursprung und Achsenorientierung dorthin, wo das Sensormodell sie erwartet. Ein optisches Kameraframe nutzt andere Achsenkonventionen als ein typisches Roboterbasisframe — folge also der einschlägigen ROS-Sensorkonvention statt vom Bild zu raten.

Den Livebaum inspizieren

Beginne mit Kommandozeilenbelegen:

ros2 run tf2_tools view_frames
ros2 run tf2_ros tf2_echo odom base_link
ros2 run tf2_ros tf2_echo base_link laser

view_frames erzeugt einen Graphen mit Konnektivität, Publishern, Updaterate und Timinginfo. tf2_echo Ziel Quelle meldet die Transformation, die Daten aus dem Quellframe ins Zielframe wandelt. Vertauschte Argumente zeigen die Inverse — eine häufige Verwirrungsquelle.

Setze in RViz das feste Frame bewusst. Ist das feste Frame map, aber map → odom fehlt, lassen sich Displays aus Odometrie und Sensoren nicht platzieren, obwohl ihre Nachrichten eintreffen.

Messzeitstempel respektieren

TF2 speichert eine Historie dynamischer Transformationen. Eine Sensornachricht mit Stempel t sollte mit dem Baum zu Zeit t transformiert werden, nicht schlicht mit der neuesten Transformation. Während der Roboter fährt, zählt das: Eine spätere Pose zu nutzen verschiebt die Beobachtung.

Nutze dieselbe Uhrenquelle über Nodes. In Simulation müssen sich alle Beteiligten auf simulierte Zeit einigen. Auf mehreren Rechnern brauchen Uhren Synchronisation passend zur Sensortiming-Genauigkeit.

Ein „Extrapolation in die Zukunft“-Fehler heißt oft, der angefragte Zeitstempel ist neuer als die verfügbare Transformation. „Extrapolation in die Vergangenheit“ heißt, die angefragten Daten sind älter als der TF2-Puffer. Den Puffer zu vergrößern kann ehrlich verspäteten Daten helfen, fixt aber keine Uhren, die sich widersprechen, oder Zeitstempel, die an falscher Stufe erzeugt wurden.

Geometrie mit simplen Physiktests prüfen

Zahlen können plausibel wirken, während Achsen falsch sind. Teste eine Beziehung auf einmal:

1. Halte den Roboter still und visualisiere Sensorpunkte in base_link.
2. Lege ein Ziel direkt voraus. Seine transformierte Position sollte auf der erwarteten Vorwärtsachse liegen.
3. Rotiere den Roboter auf der Stelle. Ein festes Weltziel sollte in odom fest bleiben, abgesehen von Odometriefehler.
4. Fahre vorwärts. Sensorbeobachtungen sollten sich konsistent mit der Basispose bewegen.

Miss statische Translationen ab den gewählten Ursprüngen, nicht ab beliebigen Gehäusekanten. Für einen planaren Roboter kann ein falsches Giervorzeichen Scans spiegeln und Wände mit dem Fahrzeug rotieren lassen.

Daten an der Verbrauchergrenze transformieren

Ein Verbraucher sollte das Zielframe nennen, das er braucht, und TF2 bitten, die gestempelten Daten zu transformieren. Vermeide, Translations- und Rotationswerte manuell in Anwendungsformeln zu kopieren; das umgeht Zeitsynchronisation, Frameverkettung und etablierten Quaternionenumgang.

Wenn eine Transformation etwas nach der Nachricht eintreffen kann, nutze einen TF-bewussten Nachrichtenfilter oder begrenztes Warten passend zur Node. Blockiere keinen Echtzeitregelkreis unbegrenzt beim Warten auf Geometrie.

Halte Frame-IDs frei von führenden Schrägstrichen und konsistent in Schreibweise und Großklein. Namespaces sollten für Mehrrobotersysteme geplant sein, sodass robot_1/base_link und robot_2/base_link nicht kollidieren können.

Fehler an der Fehlerform diagnostizieren

• Keine Verbindung zwischen Frames: Eine Kante fehlt oder der Framename unterscheidet sich zwischen Publisher und Nachricht.
• Der Baum wechselt zwischen Posen: Zwei Nodes publizieren dieselbe Kindtransformation.
• Sensordaten um 90° verdreht oder gespiegelt: Statische Orientierung oder Optikframe-Konvention ist falsch.
• Daten hinken der Bewegung hinterher: Zeitstempel falsch, Transformationen kommen spät oder der Verbraucher nutzt die neueste Transformation.
• Der Roboter springt global, aber Lokalregelung ist ruhig: Das kann gültige map → odom-Lokalisierungskorrektur sein.
• Lokalregelung springt bei Lokalisierungsupdate: Eine globale Pose wird fälschlich als odom → base_link publiziert.
• RViz zeigt Nachrichten, kann sie aber nicht platzieren: Festes Frame oder Baumkonnektivität ist falsch.

Die in Differenzialantriebs-Odometrie integrierte Pose liefert natürlicherweise odom → base_link. Die SLAM-Grundlagenanleitung erklärt, welcher globale Schätzer map → odom liefert und warum die Trennung zählt.