Repères de coordonnées TF2 sous ROS 2 pour robots mobiles

Un balayage laser est mesuré par rapport au laser, une pose odométrique est relative à son repère de départ, et un but de navigation est généralement exprimé dans une carte. Pour les comparer, le robot a besoin de la relation géométrique entre les repères de coordonnées au bon instant. Le système TF2 de ROS 2 stocke et interroge cet arbre de transformées variable dans le temps.

La plupart des pannes TF2 ne sont pas des mathématiques avancées. Ce sont un parent manquant, une transformée inversée, un horodatage faux, ou deux nœuds qui revendiquent la même relation entre repères.

Pensez en transformées, pas en poses copiées

Une transformée décrit la translation et la rotation d’un repère parent vers un repère enfant. Si base_link → laser indique que le laser est à 0,20 m en avant et 0,10 m au-dessus de la base du robot, TF2 peut transformer les mesures laser dans le repère de base. Combinée avec odom → base_link, elle les exprime en coordonnées odométriques locales.

Les repères forment un arbre : chaque enfant a exactement un parent à la fois. Un lien peut bouger, mais la relation de parenté ne peut pas être ambiguë. Les boucles comme A → B → C → A sont invalides.

Les ID de repères sont des noms sémantiques, pas des unités ni des données. Un point estampillé laser a toujours besoin d’une transformée correspondante à son instant de mesure.

Utilisez la chaîne standard des robots mobiles

Un arbre de navigation courant est :

map → odom → base_link → laser
                       → camera_link
                       → imu_link

Chaque lien a un rôle distinct :

• map → odom : correction de localisation globale. Elle peut changer quand la localisation corrige la dérive accumulée.
• odom → base_link : mouvement local lisse issu de l’odométrie roues/visuelle/inertielle. Elle doit rester continue mais peut dériver.
• base_link → capteur : géométrie de montage fixe, normalement une transformée statique.

Séparer map et odom permet des corrections globales sans faire sauter le repère de commande local. Les noms suivent les conventions ROS, mais votre robot peut ajouter base_footprint, des repères de nacelle ou des liens articulés.

Décidez qui publie chaque arête

Écrivez un tableau de propriété avant de lancer les nœuds :

Exactement un composant faisant autorité doit publier chaque arête. Deux publieurs produisent des transformées alternées ou contradictoires qui peuvent ressembler à des sauts de pose aléatoires.

Les transformées statiques décrivent la géométrie de montage mesurée. Placez l’origine et l’orientation des axes où le modèle capteur les attend. Un repère optique de caméra utilise des conventions d’axes différentes d’un repère de base robotique typique, suivez donc la convention ROS du capteur concerné plutôt que de deviner d’après le dessin.

Inspectez l’arbre en direct

Commencez par des preuves en ligne de commande :

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 génère un graphe montrant connectivité, publieurs, fréquence de mise à jour et informations temporelles. tf2_echo cible source rend compte de la transformée qui convertit les données du repère source vers le repère cible. Échanger les arguments montre l’inverse, source fréquente de confusion.

Dans RViz, réglez le repère fixe à dessein. Si le repère fixe est map mais que map → odom est absent, les affichages dépendant de l’odométrie et des capteurs ne peuvent pas être placés même si leurs messages arrivent.

Respectez les horodatages de mesure

TF2 conserve un historique des transformées dynamiques. Un message capteur estampillé à l’instant t doit être transformé avec l’arbre à l’instant t, pas simplement avec la dernière transformée. Cela compte pendant que le robot bouge : utiliser une pose plus tardive déplace l’observation.

Utilisez la même source d’horloge sur tous les nœuds. En simulation, tous les participants doivent s’accorder sur le temps simulé. Sur plusieurs ordinateurs, les horloges doivent être synchronisées selon la précision temporelle des capteurs.

Une erreur « extrapolation vers le futur » signifie souvent que l’horodatage demandé est plus récent que la transformée disponible. « Extrapolation vers le passé » signifie que les données demandées sont plus anciennes que le tampon TF2. Augmenter le tampon peut aider des données vraiment retardées, mais ne corrige ni des horloges en désaccord ni des horodatages créés à la mauvaise étape.

Vérifiez la géométrie par des essais physiques simples

Des nombres peuvent sembler plausibles avec des axes faux. Testez une relation à la fois :

1. Gardez le robot immobile et visualisez les points capteurs dans base_link.
2. Placez une cible droit devant. Sa position transformée doit se trouver sur l’axe avant attendu.
3. Tournez le robot sur place. Une cible fixe du monde doit rester fixe dans odom à l’erreur d’odométrie près.
4. Avancez. Les observations capteurs doivent bouger en cohérence avec la pose de base.

Mesurez les translations statiques depuis les origines choisies, pas depuis des bords de boîtier arbitraires. Pour un robot plan, un signe de lacet faux peut miroiter les balayages et faire tourner les murs avec le véhicule.

Transformez les données à la frontière du consommateur

Un consommateur doit déclarer le repère cible voulu et demander à TF2 de transformer les données estampillées. Évitez de copier manuellement translations et rotations dans les formules applicatives ; cela contourne la synchronisation temporelle, le chaînage des repères et la gestion éprouvée des quaternions.

Si une transformée peut arriver légèrement après le message, utilisez un filtre de messages sensible à TF ou une attente bornée adaptée au nœud. Ne bloquez pas indéfiniment une boucle de commande temps réel en attendant la géométrie.

Gardez les ID de repères sans barres obliques initiales, avec orthographe et casse cohérentes. Les espaces de noms doivent être planifiés pour les systèmes multirobots afin que robot_1/base_link et robot_2/base_link ne puissent pas entrer en collision.

Diagnostiquez les pannes d’après leur forme

• Pas de connexion entre repères : une arête manque ou le nom de repère diffère entre publieur et message.
• L’arbre alterne entre poses : deux nœuds publient la même transformée enfant.
• Données capteur tournées de 90° ou miroitées : orientation statique ou convention de repère optique fausse.
• Les données traînent derrière le mouvement : horodatages faux, transformées en retard, ou consommateur utilisant la dernière transformée.
• Le robot saute globalement mais la commande locale est lisse : c’est peut-être une correction de localisation map → odom valide.
• La commande locale saute quand la localisation se met à jour : une pose globale est publiée à tort comme odom → base_link.
• RViz montre des messages mais ne peut pas les placer : repère fixe ou connectivité de l’arbre faux.

La pose intégrée dans l’odométrie différentielle fournit naturellement odom → base_link. Le tutoriel des fondamentaux SLAM explique quel estimateur global fournit map → odom et pourquoi cette séparation compte.