Marcos de coordenadas TF2 en ROS 2 para robots móviles

Un barrido láser se mide respecto al láser, una pose de odometría de rueda es relativa a su marco de partida, y un objetivo de navegación suele expresarse en un mapa. Para compararlos, el robot necesita la relación geométrica entre los marcos de coordenadas en el instante correcto. El sistema TF2 de ROS 2 almacena y consulta ese árbol de transformaciones que varía con el tiempo.

La mayoría de los fallos de TF2 no son matemáticas avanzadas. Son un padre que falta, una transformación invertida, una marca de tiempo equivocada, o dos nodos reclamando la propiedad de la misma relación entre marcos.

Piense en transformaciones, no en poses copiadas

Una transformación describe la traslación y la rotación de un marco padre a un marco hijo. Si base_link → laser dice que el láser está 0.20 m hacia delante y 0.10 m por encima de la base del robot, TF2 puede transformar las mediciones del láser al marco de la base. Combinado con odom → base_link, eso las expresa en coordenadas de odometría local.

Los marcos forman un árbol: cada hijo tiene exactamente un padre a la vez. Un enlace puede moverse, pero la relación padre no puede ser ambigua. Los bucles como A → B → C → A no son válidos.

Los IDs de marco son nombres semánticos, no unidades ni datos. Un punto marcado con laser sigue necesitando una transformación que coincida en su marca de tiempo de medición.

Use la cadena estándar de un robot móvil

Un árbol de navegación habitual es:

map → odom → base_link → laser
                       → camera_link
                       → imu_link

Cada enlace tiene una función distinta:

• map → odom: corrección de localización global. Puede cambiar cuando la localización corrige la deriva acumulada.
• odom → base_link: movimiento local suave procedente de la odometría de ruedas, visual o inercial. Debe permanecer continuo, pero puede derivar.
• base_link → sensor: geometría de montaje fija, normalmente una transformación estática.

Separar map y odom permite que las correcciones globales ocurran sin que el marco de control local salte. Los nombres siguen las convenciones de ROS, pero su robot puede añadir base_footprint, marcos de cardán o eslabones articulados.

Decida quién publica cada arista

Escriba una tabla de propiedad antes de lanzar los nodos:

Exactamente un componente autoritativo debe publicar cada arista. Dos publicadores producen transformaciones alternas o contradictorias que pueden parecer saltos de pose aleatorios.

Las transformaciones estáticas describen la geometría de montaje medida. Ponga el origen y la orientación de los ejes donde el modelo del sensor los espera. Un marco óptico de cámara usa convenciones de ejes distintas de las de un marco de base de robot típico, así que siga la convención del sensor de ROS correspondiente en vez de deducirla del dibujo.

Inspeccione el árbol en vivo

Empiece con pruebas desde la línea de comandos:

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 genera un gráfico que muestra la conectividad, los publicadores, la tasa de actualización y la información de tiempos. tf2_echo destino origen informa de la transformación que convierte datos del marco origen en el marco destino. Intercambiar los argumentos muestra la inversa, que es una fuente habitual de confusión.

En RViz, fije el marco fijo de forma intencionada. Si el marco fijo es map pero falta map → odom, las visualizaciones que dependen de la odometría y de los sensores no se pueden colocar aunque sus propios mensajes estén llegando.

Respete las marcas de tiempo de medición

TF2 almacena un historial de las transformaciones dinámicas. Un mensaje de sensor marcado en el instante t debe transformarse usando el árbol en el instante t, no sencillamente la última transformación. Esto importa mientras el robot se mueve: usar una pose posterior desplaza la observación.

Use la misma fuente de reloj en todos los nodos. En simulación, todos los participantes deben estar de acuerdo sobre el tiempo simulado. En varios ordenadores, los relojes necesitan una sincronización acorde con la precisión temporal de los sensores.

Un error de «extrapolación hacia el futuro» a menudo significa que la marca de tiempo solicitada es más nueva que la transformación disponible. «Extrapolación hacia el pasado» significa que los datos solicitados son más antiguos que el búfer de TF2. Aumentar el búfer puede ayudar con datos genuinamente retrasados, pero no arregla relojes que no coinciden ni marcas de tiempo creadas en la etapa equivocada.

Verifique la geometría con pruebas físicas sencillas

Los números pueden parecer plausibles mientras los ejes están mal. Pruebe una relación cada vez:

1. Mantenga el robot quieto y visualice los puntos del sensor en base_link.
2. Coloque un objetivo justo delante. Su posición transformada debería estar en el eje hacia delante esperado.
3. Gire el robot sobre sí mismo. Un objetivo fijo del mundo debería permanecer fijo en odom salvo error de odometría.
4. Avance en línea recta. Las observaciones del sensor deberían moverse de forma coherente con la pose de la base.

Mida las traslaciones estáticas desde los orígenes elegidos, no desde bordes arbitrarios de la carcasa. Para un robot planar, un signo de guiñada equivocado puede reflejar los barridos y hacer que las paredes parezcan girar con el vehículo.

Transforme los datos en el límite del consumidor

Un consumidor debe declarar el marco destino que necesita y pedirle a TF2 que transforme los datos con su marca de tiempo. Evite copiar manualmente valores de traslación y rotación en fórmulas de la aplicación; eso se salta la sincronización temporal, el encadenamiento de marcos y el manejo establecido de cuaterniones.

Si una transformación puede llegar poco después del mensaje, use un filtro de mensajes consciente de TF2 o una espera acotada acorde al nodo. No bloquee un lazo de control en tiempo real indefinidamente esperando geometría.

Mantenga los IDs de marco sin barras iniciales y consistentes en ortografía y mayúsculas. Los espacios de nombres deben planearse para sistemas multirobot, de modo que robot_1/base_link y robot_2/base_link no puedan colisionar.

Diagnostique los fallos a partir de la forma del error

• Sin conexión entre marcos: falta una arista o el nombre del marco difiere entre el publicador y el mensaje.
• El árbol alterna entre poses: dos nodos publican la misma transformación hija.
• Los datos del sensor están girados 90° o reflejados: la orientación estática o la convención del marco óptico es incorrecta.
• Los datos van por detrás del movimiento: las marcas de tiempo están mal, las transformaciones llegan tarde, o el consumidor usa la última transformación.
• El robot salta globalmente pero el control local es suave: puede ser una corrección de localización map → odom válida.
• El control local salta cuando la localización se actualiza: se está publicando una pose global como si fuera odom → base_link.
• RViz muestra mensajes pero no puede colocarlos: el marco fijo o la conectividad del árbol están mal.

La pose integrada en la odometría de tracción diferencial suministra de forma natural odom → base_link. El tutorial de fundamentos de SLAM explica qué estimador global suministra map → odom y por qué la separación importa.