ROS 2 TF2-coördinatenframes voor mobiele robots

Een laserscan wordt gemeten ten opzichte van de laser, een pose uit wielodometrie is relatief ten opzichte van het startframe, en een navigatiedoel wordt meestal in een kaart gegeven. Om die te vergelijken heeft de robot de geometrische relatie tussen coördinatenframes op het juiste moment nodig. Het TF2-systeem van ROS 2 bewaart en bevat die tijdafhankelijke transformatiestructuur.

De meeste TF2-storingen zijn geen gevorderde wiskunde. Het ontbreekt een bovenliggende node, een transformatie is omgekeerd, een tijdstempel klopt niet, of twee nodes claimen eigendom over dezelfde framerelatie.

Denk in transformaties, niet in gekopieerde poses

Een transformatie beschrijft de translatie en rotatie van een bovenliggend naar een onderliggend frame. Als base_link → laser zegt dat de laser 0.20 m naar voren en 0.10 m boven de robotbasis zit, kan TF2 lasermetingen naar het basisframe transformeren. Dat gecombineerd met odom → base_link drukt ze uit in lokale odometrie-coördinaten.

Frames vormen een boomstructuur: elk kindframe heeft op elk moment precies één bovenliggend frame. Een verbinding kan bewegen, maar de ouderrelatie mag niet dubbelzinnig zijn. Lussen zoals A → B → C → A zijn ongeldig.

Frame-ID’s zijn semantische namen, geen eenheden of gegevens. Een punt met stempel laser heeft nog steeds een passende transformatie nodig op het tijdstempel van de meting.

Gebruik de standaardketen voor mobiele robots

Een veelgebruikte navigatiestructuur is:

map → odom → base_link → laser
                       → camera_link
                       → imu_link

Elke verbinding heeft een eigen taak:

• map → odom: globale lokalisatiecorrectie. Die kan veranderen wanneer de lokalisatie opgebouwde drift corrigeret.
• odom → base_link: soepele lokale beweging uit wiel-, visuele of inertiaalodometrie. Die moet continu blijven maar kan drijven.
• base_link → sensor: vaste montagegeometrie, normaal een statische transformatie.

Het scheiden van map en odom maakt globale correcties mogelijk zonder het lokale regelframe te laten springen. De namen volgen de ROS-conventies, maar je robot kan base_footprint, draaibare frames of geledingen toevoegen.

Bepaal wie elke verbinding publiceert

Schrijf een eigendomstabel voordat je nodes start:

Precies één gezaghebbende component moet elke verbinding publiceren. Twee publishers leveren alternerende of conflicterende transformaties op die eruit kunnen zien als willekeurige posesprongen.

Statische transformaties beschrijven gemeten montagegeometrie. Zet oorsprong en asrichting waar het sensormodel ze verwacht. Een optisch cameraframe gebruikt andere asconventies dan een typisch robotbasisframe, dus volg de relevante ROS-sensorconventie in plaats van te gokken op basis van de tekening.

Inspecteer de levende structuur

Begin met bewijs van de opdrachtregel:

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 genereert een grafiek met connectiviteit, publishers, updatefrequentie en timinginformatie. tf2_echo target source meldt de transformatie die gegevens uit het bronframe omzet naar het doelframe. De argumenten omwisselen toont de inverse, en dat is een veelvoorkende bron van verwarring.

Stel in RViz het vaste frame bewust in. Is het vaste frame map maar ontbreekt map → odom, dan kunnen weergaven die van odometrie en sensoren afhangen niet worden geplaatst, ook al komen hun eigen berichten binnen.

Respecteer de meettijdstempels

TF2 bewaart een geschiedenis van dynamische transformaties. Een sensorbericht met tijdstempel t moet worden getransformeerd met de boomstructuur op tijdstip t, niet simpelweg met de nieuwste transformatie. Dat telt terwijl de robot beweegt: een latere pose verschuift de waarneming.

Gebruik dezelfde klokbron in alle nodes. In simulatie moeten alle deelnemers dezelfde gesimuleerde tijd delen. Op meerdere computers moeten klokken worden gesynchroniseerd op een manier die past bij de nauwkeurigheid van de sensortiming.

Een foutje “extrapolation into the future” betekent vaak dat het gevraagde tijdstempel nieuwer is dan de beschikbare transformatie. “Extrapolation into the past” betekent dat de gevraagde gegevens ouder zijn dan de TF2-buffer. Een grotere buffer helpt misschien bij werkelijk vertraagde gegevens, maar verhelpt klokken die niet overeenkomen of tijdstempels die in de verkeerde fase zijn gemaakt niet.

Verifieer de geometrie met eenvoudige fysieke proeven

Getallen kunnen er aannemelijk uitzien terwijl de assen verkeerd staan. Test één relatie tegelijk:

1. Houd de robot stil en visualiseer sensorpunten in base_link.
2. Plaats een doel recht vooruit. De getransformeerde positie moet op de verwachte vooruitas liggen.
3. Draai de robot op de plaats. Een vast werelddoel moet in odom vast blijven, afgezien van odometriefout.
4. Rij vooruit. Sensorwaarnemingen moeten consistent meebewegen met de basispose.

Meet statische translaties vanaf de gekozen oorsprongen, niet vanaf willekeurige randen van de behuizing. Bij een robot in het vlak kan een verkeerd teken van de gierhoek scans spiegelen en muren met het voertuig mee doen draaien.

Transformeer gegevens bij de verbruiker

Een verbruiker moet aangeven welk doelframe hij nodig heeft en aan TF2 vragen de van een tijdstempel voorziene gegevens te transformeren. Vermijd om translatie- en rotatiewaarden handmatig in applicatieformules te kopiëren; dat omzeilt tijdsynchronisatie, frameketens en de gevestigde afhandeling van quaternions.

Kan een transformatie net na het bericht binnenkomen, gebruik dan een TF-bewuste berichtfilter of een begrensde wachttijd die bij de node past. Blokkeer een regelloop voor realtimebesturing nooit onbeperkt terwijl je op geometrie wacht.

Houd frame-ID’s vrij van voorafgaande schuine strepen en consistent in spelling en hoofdlettergebruik. Namespaces moeten vooraf zijn gepland voor robotsystemen met meerdere robots, zodat robot_1/base_link en robot_2/base_link niet botsen.

Diagnoseer storingen op basis van de foutvorm

• Geen verbinding tussen frames: een verbinding ontbreekt, of de framenaam verschilt tussen publisher en bericht.
• De boom wisselt steeds van pose: twee nodes publiceren dezelfde kindtransformatie.
• Sensorgegevens staan 90° gedraaid of zijn gespiegeld: de statische oriëntatie of de optische frameconventie klopt niet.
• De gegevens lopen achter op de beweging: tijdstempels zijn verkeerd, transformaties komen te laat, of de verbruiker gebruikt de nieuwste transformatie.
• De robot springt wereldwijd maar de lokale regeling is soepel: dit kan een geldige map → odom-lokalisatiecorrectie zijn.
• De lokale regeling springt wanneer de lokalisatie bijwerkt: er wordt ten onrechte een globale pose gepubliceerd als odom → base_link.
• RViz toont berichten maar kan ze niet plaatsen: het vaste frame of de connectiviteit van de boom klopt niet.

De pose die in odometrie voor differentiële aandrijving wordt geïntegreerd levert vanzelf odom → base_link. De tutorial over SLAM-basisbegrippen legt uit welke globale schatter map → odom levert en waarom de scheiding belangrijk is.