Frames de coordenadas TF2 do ROS 2 para robôs móveis

Uma varredura do laser é medida em relação ao laser, a pose da odometria das rodas é relativa ao frame inicial e uma meta de navegação normalmente é expressa em um mapa. Para compará-las, o robô precisa da relação geométrica entre os frames de coordenadas no instante correto. O sistema TF2 do ROS 2 armazena e consulta essa árvore de transformações que varia com o tempo.

A maioria das falhas do TF2 não exige matemática avançada. É um pai ausente, uma transformação invertida, um carimbo de tempo errado ou dois nós que afirmam ser responsáveis pela mesma relação entre frames.

Pense em transformações, não em poses copiadas

Uma transformação descreve a translação e a rotação de um frame pai para um frame filho. Se base_link → laser indica que o laser está 0,20 m à frente e 0,10 m acima da base do robô, o TF2 pode transformar as medições do laser para o frame da base. Ao combinar isso com odom → base_link, elas são expressas nas coordenadas locais de odometria.

Os frames formam uma árvore: cada filho tem exatamente um pai por vez. Uma ligação pode se mover, mas a relação com o pai não pode ser ambígua. Ciclos como A → B → C → A são inválidos.

IDs de frame são nomes semânticos, não unidades nem dados. Um ponto marcado com o frame laser ainda precisa de uma transformação correspondente no carimbo de tempo da medição.

Use a cadeia padrão para robôs móveis

Uma árvore de navegação comum é:

map → odom → base_link → laser
                       → camera_link
                       → imu_link

Cada ligação tem uma função distinta:

• map → odom: correção da localização global. Pode mudar quando a localização corrige a deriva acumulada.
• odom → base_link: movimento local suave obtido da odometria de rodas, visão ou inércia. Deve permanecer contínuo, mas pode sofrer deriva.
• base_link → sensor: geometria fixa de montagem, normalmente uma transformação estática.

Separar map e odom permite correções globais sem fazer o frame local de controle saltar. Os nomes seguem as convenções do ROS, mas seu robô pode adicionar base_footprint, frames de cardan ou ligações articuladas.

Defina quem publica cada ligação

Escreva uma tabela de responsabilidades antes de iniciar os nós:

Exatamente um componente autoritativo deve publicar cada ligação. Dois publicadores produzem transformações alternadas ou conflitantes, que podem parecer saltos aleatórios de pose.

Transformações estáticas descrevem a geometria de montagem medida. Posicione a origem e a orientação dos eixos onde o modelo do sensor espera. Um frame óptico da câmera usa convenções de eixos diferentes das de um frame típico da base do robô; portanto, siga a convenção pertinente ao sensor ROS em vez de adivinhar pelo desenho.

Inspecione a árvore em tempo real

Comece com evidências obtidas pela linha de comando:

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 gera um grafo que mostra conectividade, publicadores, taxa de atualização e informações de tempo. tf2_echo target source informa a transformação que converte dados do frame de origem para o frame de destino. Trocar os argumentos mostra o inverso, uma fonte comum de confusão.

No RViz, defina o frame fixo intencionalmente. Se o frame fixo for map, mas map → odom estiver ausente, as exibições que dependem da odometria e dos sensores não poderão ser posicionadas, mesmo que suas próprias mensagens estejam chegando.

Respeite os carimbos de tempo das medições

O TF2 armazena um histórico das transformações dinâmicas. Uma mensagem de sensor marcada no instante t deve ser transformada usando a árvore no instante t, e não simplesmente a transformação mais recente. Isso importa enquanto o robô está se movendo: usar uma pose posterior desloca a observação.

Use a mesma fonte de relógio em todos os nós. Em simulação, todos os participantes precisam concordar com o tempo simulado. Em vários computadores, os relógios precisam de sincronização adequada à precisão de tempo dos sensores.

Um erro de “extrapolação para o futuro” costuma significar que o carimbo de tempo solicitado é mais recente que a transformação disponível. “Extrapolação para o passado” significa que os dados solicitados são mais antigos que o buffer do TF2. Aumentar o buffer pode ajudar com dados realmente atrasados, mas não corrige relógios divergentes nem carimbos de tempo criados na etapa errada.

Verifique a geometria com testes físicos simples

Os números podem parecer plausíveis enquanto os eixos estão errados. Teste uma relação por vez:

1. Mantenha o robô parado e visualize os pontos dos sensores em base_link.
2. Coloque um alvo diretamente à frente. Sua posição transformada deve ficar no eixo de avanço esperado.
3. Gire o robô no lugar. Um alvo fixo no mundo deve permanecer fixo em odom, exceto por erros de odometria.
4. Translade para a frente. As observações dos sensores devem se mover de forma consistente com a pose da base.

Meça as translações estáticas a partir das origens escolhidas, não de bordas arbitrárias da carcaça. Para um robô planar, o sinal errado de guinada pode espelhar as varreduras e fazer as paredes parecerem girar com o veículo.

Transforme os dados no limite do consumidor

Um consumidor deve indicar o frame de destino de que precisa e pedir ao TF2 que transforme os dados com carimbo de tempo. Evite copiar manualmente valores de translação e rotação para fórmulas da aplicação; isso ignora a sincronização de tempo, o encadeamento de frames e o tratamento correto de quatérnios.

Se uma transformação puder chegar pouco depois da mensagem, use um filtro de mensagens compatível com TF ou uma espera limitada adequada ao nó. Não bloqueie indefinidamente um ciclo de controle em tempo real à espera de geometria.

Mantenha os IDs de frame sem barras iniciais e consistentes em grafia e maiúsculas. Planeje espaços de nomes para sistemas com vários robôs, de modo que robot_1/base_link e robot_2/base_link não entrem em conflito.

Diagnostique falhas pela forma do erro

• Não há conexão entre os frames: uma ligação está ausente ou o nome do frame difere entre o publicador e a mensagem.
• A árvore alterna entre poses: dois nós publicam a mesma transformação do filho.
• Os dados dos sensores estão rotacionados em 90° ou espelhados: a orientação estática ou a convenção do frame óptico está errada.
• Os dados ficam atrás do movimento: os carimbos de tempo estão errados, as transformações chegam atrasadas ou o consumidor usa a transformação mais recente.
• O robô salta globalmente, mas o controle local é suave: isso pode ser uma correção válida de localização em map → odom.
• O controle local salta quando a localização é atualizada: uma pose global está sendo publicada incorretamente como odom → base_link.
• O RViz mostra mensagens, mas não consegue posicioná-las: o frame fixo ou a conectividade da árvore está incorreta.

A pose integrada na odometria de tração diferencial fornece naturalmente odom → base_link. O tutorial sobre fundamentos de SLAM explica qual estimador global fornece map → odom e por que a separação importa.