Nós, tópicos, serviços e ações no ROS 2

O Robot Operating System 2 (ROS 2) permite que programas executados de forma independente troquem dados tipados. Um driver de câmera, um controlador de motores, um planejador e uma interface com o usuário podem ser nós separados, conectados pelo grafo do ROS. A decisão de projeto importante não é apenas o tipo da mensagem; é se a interação é um fluxo, uma solicitação curta ou uma meta de longa duração.

Este guia independe da distribuição. Os comandos e os conceitos fundamentais são estáveis, mas os detalhes de instalação e as versões de pacotes devem seguir a documentação da versão do ROS 2 que você realmente usar.

Modele uma responsabilidade por nó

Um nó é um participante do grafo do ROS. Bons limites entre nós seguem as responsabilidades: um driver de lidar publica varreduras, um nó de odometria estima o movimento e um módulo de navegação aceita metas. Evite transformar cada função em um nó — a sobrecarga de processamento e comunicação é justificável quando o limite melhora reutilização, isolamento, implantação ou propriedade.

Nomes tornam o grafo compreensível. Use nomes descritivos de nós e interfaces, como /front_lidar, /wheel_odometry e /cmd_vel. Espaços de nomes permitem que dois robôs executem grafos equivalentes sem colisões.

Inspecione um sistema em execução antes de alterá-lo:

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info revela publicadores, assinantes, servidores e clientes de serviços e ações conectados ao nó. Muitas vezes, é a forma mais rápida de encontrar uma interface ausente ou com nome incorreto.

Use tópicos para fluxos contínuos

Um tópico é comunicação assíncrona por publicação e assinatura. Publicadores enviam mensagens tipadas sem esperar uma resposta direta, e qualquer número de assinantes pode recebê-las. Tópicos combinam com dados que mudam ao longo do tempo:

• imagens de câmera e varreduras de lidar;
• estados das juntas e odometria das rodas;
• estado da bateria;
• velocidade comandada;
• eventos de diagnóstico.

Verifique um fluxo pela linha de comando:

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

O tipo da mensagem faz parte do contrato. Frames de coordenadas, unidades, carimbos de tempo e covariância são tão importantes quanto os nomes dos campos. Um assinante não pode interpretar uma posição com segurança se não sabe se o valor está em metros no frame map ou em milímetros em um frame de câmera.

As configurações de Qualidade de Serviço (QoS) afetam a entrega. Fluxos de sensores normalmente preferem dados recentes a retransmitir amostras antigas, enquanto estados semelhantes a configurações podem exigir entrega confiável ou a política de durabilidade TRANSIENT_LOCAL. Um publicador e um assinante com políticas de QoS incompatíveis podem aparecer no grafo, mas não trocar dados.

Use serviços para solicitações e respostas curtas

Um cliente de serviço envia uma solicitação e espera a resposta de um servidor. Serviços combinam com operações rápidas que têm uma resposta definida:

• ler ou atualizar uma configuração;
• redefinir a odometria;
• limpar um mapa;
• perguntar se um componente está pronto.

Eles não combinam com dados contínuos de sensores nem com uma manobra que possa levar segundos. Uma chamada síncrona que espera uma ação lenta do motor pode bloquear quem a chamou e não oferece nenhum mecanismo padrão de retorno de progresso ou cancelamento.

Inspecione e chame um serviço com:

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

O tipo exato no último comando precisa corresponder ao servidor. Projete as respostas para informar tanto o sucesso da comunicação quanto o estado significativo da operação; receber uma resposta não garante que foi possível executar a ação de hardware solicitada.

Use ações para metas de longa duração

Uma ação modela uma meta que leva tempo. Ela oferece aceitação da meta, feedback periódico, resultado final e cancelamento ou preempção. Navegar até uma pose e mover um braço ao longo de uma trajetória são ações naturais.

A interação tem três partes semânticas:

• Meta: o que o cliente deseja, como uma pose de destino.
• Feedback: o progresso durante a execução, como a distância restante.
• Resultado: o estado terminal e quaisquer dados retornados.

Servidores de ação devem responder rapidamente ao cancelamento e deixar o hardware em um estado documentado. Um cliente deve tratar rejeição, cancelamento, aborto e sucesso como estados distintos, em vez de considerar todo resultado como conclusão bem-sucedida.

Pela linha de comando:

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Substitua os marcadores pelo tipo e pelos campos informados pelo grafo em execução. Use o comando para inspecionar o comportamento, não como uma interface de produção fixa.

Escolha com uma tabela de decisão

Um tópico não é automaticamente “rápido”, e um serviço não é automaticamente “confiável”. A temporização e a entrega dependem da QoS, do middleware, dos executores, da carga de trabalho e da rede. Escolha primeiro pela semântica da interação.

Um comportamento pode usar os três. Um nó de navegação assina tópicos de varredura e odometria, aceita uma ação de navegação e expõe um serviço curto para limpar um mapa de custos. Os limites permanecem claros porque cada interface responde a um tipo diferente de pergunta.

Projete um grafo para um robô móvel simples

Considere um robô de tração diferencial:

1. /encoder_driver publica as contagens das rodas.
2. /odometry assina as contagens, publica /odom e, no TF2, a transformação odom → base_link.
3. /range_driver publica medições de distância.
4. /safety_controller assina as distâncias e limita /cmd_vel.
5. /navigator aceita uma ação de movimento e publica a velocidade desejada.

Não deixe dois nós sem relação comandarem os motores sem arbitragem. Dê a um componente a propriedade do comando final do atuador ou torne explícita a regra de prioridade.

Use os tipos padrão de mensagem do ROS quando suas semânticas forem adequadas. Interfaces personalizadas são apropriadas quando o contrato de dados for realmente específico do projeto, não apenas quando se quer renomear campos existentes.

Depure o grafo camada por camada

Quando os dados não chegam:

1. Confirme que os dois nós aparecem em ros2 node list.
2. Confirme os nomes e tipos das interfaces.
3. Inspecione as contagens de publicadores e assinantes.
4. Compare as políticas de QoS.
5. Exiba uma mensagem e verifique os carimbos de tempo e os IDs de frame.
6. Verifique os registros e a carga dos executores.

Quando uma ação nunca termina, diferencie “meta não aceita”, “servidor parou de produzir feedback” e “cliente ignorou o resultado”. Quando um serviço fica bloqueado, verifique se o callback do servidor está esperando por um trabalho que deveria ser uma ação.

Evite os erros comuns de arquitetura

• Tudo usa um tópico: quem chama não pode saber se uma solicitação única foi atendida.
• Movimentação usa um serviço: trabalho longo não tem semântica de progresso nem cancelamento.
• Dados de sensores usam por padrão uma fila confiável e profunda: amostras antigas se acumulam quando o processamento fica para trás.
• As convenções de frame e unidade não são documentadas: mensagens tipadas ainda são ambíguas semanticamente.
• Um nó gigante controla todos os subsistemas: testes e isolamento de falhas desaparecem.
• Dezenas de nós minúsculos encapsulam funções comuns: o grafo fica mais difícil sem ganhar um limite útil.

O simulador de braço robótico oferece uma tarefa concreta semelhante a uma ação: solicite um destino, observe o movimento e relate resultados inalcançáveis ou restringidos. Continue com frames de coordenadas no TF2 do ROS 2 para manter a geometria consistente em todos os nós.