ROS 2: fundamentos, referenciais e visão de robôs
Você pode estruturar um robô como nós ROS 2, escolher tópicos, serviços e ações corretamente e posicionar as observações de uma câmera na árvore de referenciais do robô.
Todo o restante deste site funciona em um microcontrolador: um programa, um laço e controle total. ROS 2 é a etapa seguinte quando um robô ultrapassa esse limite — quando tem uma câmera, um planejador e uma pilha de drivers que precisam funcionar ao mesmo tempo, escritas por pessoas diferentes e reiniciáveis de forma independente.
O preço é um conjunto de novas ideias. A primeira é que um robô ROS 2 não é um programa, mas um grafo de nós que conversam entre si. Boa parte da confusão inicial vem de escolher a forma errada de comunicação entre os quatro modos disponíveis. Por isso, esta trilha começa aqui: tópicos para fluxos, serviços para solicitações rápidas e ações para trabalhos longos que talvez seja preciso cancelar.
Depois vem TF2, a parte que costuma derrubar quem está começando. Um robô é uma árvore de referenciais de coordenadas — a base, as rodas, todos os sensores — e quase todo problema real é uma transformação ausente, desatualizada ou ligada ao pai errado. Depois que os referenciais fazem sentido, uma câmera calibrada se torna apenas outro nó que publica uma pose nessa árvore, que é exatamente como a visão se integra ao restante do robô.
Antes de começar
Você precisa se sentir à vontade na linha de comando do Linux e conseguir ler Python ou C++. Um Raspberry Pi costuma ser o computador de destino, mas tudo o que vem antes dos nós de drivers funciona em um notebook. A própria configuração deve levar uma noite — o ROS 2 é um sistema distribuído e se comporta como um desde o primeiro comando.
O que você será capaz de fazer
- Escolher corretamente entre um tópico, um serviço e uma ação, em vez de transformar tudo em tópico e descobrir os limites depois.
- Construir uma árvore de referenciais TF2 que transforme um ponto do referencial de um sensor para o do robô e depurar a árvore quando uma transformação estiver ausente.
- Calibrar uma câmera, obter a pose de um marcador e entender a qual referencial os valores se referem.
- Converter um twist
cmd_velem velocidades das rodas esquerda e direita, com saturação que preserve o arco comandado.
Onde as pessoas costumam travar
Os nós não se enxergam. A descoberta do ROS 2 é automática até deixar de ser. Duas
máquinas com valores de ROS_DOMAIN_ID diferentes são invisíveis uma para a outra, e um Wi-Fi que
bloqueia multicast interrompe totalmente a descoberta enquanto todos os nós informam estar saudáveis.
QoS incompatíveis. Um publicador que oferece melhor esforço e um assinante que exige confiabilidade nunca se conectam e, para ajudar, nenhum dos dois registra um erro. O tópico simplesmente não transporta dados. Dados de sensores costumam ser o culpado, pois seus drivers normalmente usam melhor esforço.
Esquecer de disponibilizar o espaço de trabalho. Um novo terminal não conhece seus pacotes até o espaço de trabalho ser
disponibilizado, então o comando ros2 run informa que um pacote que existe claramente está ausente.
Um referencial com dois pais. TF2 forma uma árvore. Publicar o mesmo referencial filho a partir de duas fontes lhe dá dois pais, e as consultas começam a falhar de forma intermitente conforme o tempo — um dos bugs mais difíceis de identificar no ROS, porque quase sempre funciona.
Timestamps vazios e IDs de referencial. Uma mensagem cujo cabeçalho não tem frame_id não pode
ser transformada, e uma cujo timestamp é zero não será alinhada a nada. Ambas passam pelo sistema de
tipos sem gerar avisos e falham somente quando alguém tenta usá-las em conjunto.
O que você precisa
| Item | Por que esta trilha precisa dele | Observações |
|---|---|---|
| Uma linha de comando do Linux com a qual você se sinta à vontade | O ROS 2 é um sistema voltado primeiro ao Linux, e as ferramentas pressupõem esse ambiente | Ubuntu corresponde aos binários oficiais; qualquer outro sistema exige compilação |
| Python ou C++ | O código dos nós é escrito em uma das duas linguagens | Python é mais rápido de aprender; C++ é usado nos nós críticos de desempenho |
| Uma máquina com tela física | Depurar um sistema distribuído por SSH é desnecessariamente difícil | Um notebook é um destino melhor de aprendizagem que um Pi sem tela |
| Um Raspberry Pi (somente para nós de drivers) | Só é necessário quando o robô carrega seu próprio computador | Pi 4 ou superior; um Pi Zero decepciona |
| Uma câmera (somente para o nó de visão) | O último nó da trilha | Um módulo de câmera para Pi ou qualquer webcam UVC |
| Uma noite para a configuração | Sem brincadeira — isso faz parte da trilha | A instalação é de fato o primeiro passo difícil |
Por que a trilha segue esta ordem
Os padrões de comunicação vêm primeiro porque uma escolha errada fica cara depois. As quatro formas de comunicação dos nós ROS 2 não são intercambiáveis, e o erro comum de iniciantes é transformar tudo em tópico — só para descobrir, trezentas linhas depois, que precisava de cancelamento e retorno de progresso e vinha reimplementando ações manualmente. Dez minutos para decidir entre tópico, serviço e ação evitam uma reescrita.
TF2 vem em segundo porque é a parte que costuma derrubar quem está começando. Depois que vários nós publicam dados sobre o mundo físico, cada um entende “3 metros” em relação a algo diferente — a câmera, a base, o mapa. TF2 relaciona essas referências, e a maioria dos problemas reais do ROS é uma transformação ausente, desatualizada ou ligada ao pai errado. Estudar TF2 como uma disciplina antes de precisar dele custa muito menos do que lidar com uma falha misteriosa durante uma consulta.
A calibração da câmera vem em terceiro porque depende totalmente do segundo. A pose de um marcador não significa nada sem saber a que referencial ela pertence. Depois que os referenciais fazem sentido, uma câmera calibrada é apenas outro nó que publica uma pose na árvore, e a visão deixa de ser um caso especial.
O nó de acionamento encerra a trilha porque é onde o ROS encontra o equipamento que dá sentido a todo o
restante deste site. Um twist cmd_vel é a interface padrão usada por todos os componentes de
navegação do ROS, e transformá-lo em velocidades das rodas esquerda e direita — com saturação que preserva
o arco comandado em vez de distorcê-lo — é a ponte entre o mundo ROS e o mundo dos motores.
Pontos de verificação: como saber que uma etapa foi dominada
| Etapa | Verificação | Como é um resultado aprovado |
|---|---|---|
| Instalação | ros2 topic list em um terminal novo |
Funciona após disponibilizar o espaço de trabalho, e você sabe por que falha antes |
| Dois nós | Execute publicador e assinante em duas máquinas | As mensagens chegam — e você sabe qual ID de domínio elas compartilham |
| Tópico vs. serviço | Escreva um de cada para os mesmos dados | Você explica em uma frase por que cada padrão atende à sua tarefa |
| Ações | Inicie uma ação longa e cancele-a no meio | Ela para corretamente, e você recebeu retorno durante a execução |
| QoS | Cause deliberadamente uma incompatibilidade de confiabilidade em um tópico | Ele não transporta nada silenciosamente — agora você reconhece o sintoma |
| Árvore de referenciais TF2 | Execute ros2 run tf2_tools view_frames |
Uma árvore, uma raiz e nenhum referencial com dois pais |
| Consulta de transformação | Transforme um ponto do referencial de um sensor para o da base | O número está correto, e você pode conferi-lo com uma trena |
| Transformações desatualizadas | Pare um publicador de transformação durante uma consulta | Você recebe um erro de extrapolação — agora a falha tem nome |
| Calibração da câmera | Calibre e verifique o erro de reprojeção | Bem abaixo de um pixel; um valor alto indica um conjunto ruim de capturas |
| Pose do marcador | Coloque um marcador a uma distância medida e leia sua pose | O valor corresponde à trena, e você sabe em qual referencial ele está |
cmd_vel |
Publique um twist com termos linear e angular | Ambas as rodas giram corretamente, e a saturação de uma ajusta a outra para manter o arco |
Onde esta trilha termina
Esta trilha constrói os fundamentos que sustentam um robô ROS 2 — como os nós conversam, como os referenciais se relacionam e como um sensor e um conjunto motriz entram no grafo. Ela termina de propósito antes dos grandes subsistemas que pressupõem tudo isso.
Ela não cobre a pilha Nav2, a resposta padrão para navegação autônoma no ROS 2 e um sistema
substancial por si só — mapas de custo, árvores de comportamento, planejadores e controladores,
todos configurados em vez de programados. A Nav2 pressupõe uma árvore de referenciais TF2 funcional e uma interface
cmd_vel, que é exatamente o que esta trilha oferece.
Também não cobre URDF e descrição do robô, o formato XML que informa ao restante do ROS qual é o formato do seu robô. Tudo aqui publica transformações manualmente; URDF é a forma de parar de fazer isso.
Não cobre simulação no Gazebo, ambiente em que a maior parte do desenvolvimento ROS mais sério acontece de fato, nem ros2_control, a camada padrão de abstração do equipamento para conjuntos motrizes reais.
E não cobre comportamento em tempo real. O ROS 2 é construído sobre DDS e é muito mais capaz nesse aspecto do que o ROS 1 era, mas uma máquina Linux executando um nó Python não é um sistema de controle em tempo real. As malhas de controle mais rápidas — equilíbrio, controle de corrente e tudo que opera em quilohertz — continuam pertencendo a um microcontrolador, com o ROS 2 acima dele. Essa divisão é a arquitetura normal de um robô sofisticado, não um compromisso.
Roteiro de aprendizagem
O caminho
Siga os nós em ordem — cada um desbloqueia o próximo depois que você o conclui. Seu progresso fica salvo neste dispositivo.
0 / 5 concluídos
Dúvidas comuns
Perguntas frequentes
Quando um robô deve passar do Arduino para o ROS 2?
Quando um único laço de controle deixa de ser suficiente. Um microcontrolador executando um único programa é a arquitetura certa para um seguidor de linha, um solucionador de labirinto ou qualquer comportamento que caiba em um único laço de controle — e é realmente melhor do que o ROS 2 nesses casos, porque é determinístico e você consegue manter tudo isso na cabeça. O ROS 2 compensa sua complexidade quando um robô precisa executar várias coisas ao mesmo tempo, em ritmos diferentes — um fluxo de câmera, um planejador, uma pilha de drivers — escritas em momentos diferentes e reiniciáveis de forma independente. O custo é um sistema distribuído, que se comporta como tal desde o primeiro comando.
Tópico, serviço ou ação — como escolher no ROS 2?
Associe o padrão de comunicação à tarefa. Um tópico é um fluxo sem resposta: dados de sensores, odometria, comandos de velocidade — tudo o que é publicado continuamente e para o qual o valor mais recente importa. Um serviço é uma solicitação e resposta rápidas, usado para tarefas que levam milissegundos, como consultar um parâmetro ou alternar um modo. Uma ação é para trabalhos longos dos quais você pode querer acompanhar o progresso ou que precisa cancelar — navegar até um objetivo ou fechar uma garra sobre um objeto. O erro mais comum no início é transformar tudo em tópico e depois implementar manualmente a semântica de solicitação e resposta por cima.
Por que meus nós ROS 2 não se enxergam?
Três causas explicam quase todos os casos. Valores diferentes de ROS_DOMAIN_ID tornam duas máquinas completamente invisíveis uma para a outra, embora ambas informem estar perfeitamente saudáveis. Redes Wi-Fi que bloqueiam multicast interrompem todo o protocolo de descoberta; por isso os nós costumam se encontrar por Ethernet, mas não pelo ponto de acesso do escritório. E QoS incompatíveis — um publicador oferece melhor esforço enquanto um assinante exige confiabilidade — impedem a conexão, e nenhum dos dois registra um erro. Verifique primeiro o ID do domínio: isso não custa nada e é a causa mais comum.
O que é TF2 e por que as transformações continuam falhando?
O TF2 mantém a árvore de referenciais de coordenadas de um robô — base, rodas e todos os sensores — para que você possa perguntar onde está um ponto no referencial da câmera em relação ao referencial do robô. As consultas falham por três motivos recorrentes. Um referencial com dois pais quebra a árvore e, como a falha depende de qual publicador venceu a disputa de tempo, ele funciona na maioria das vezes. Um frame_id vazio no cabeçalho de uma mensagem impede qualquer transformação. E um timestamp zero ou desatualizado significa que a transformação existe, mas não no instante solicitado. Os três casos passam pelo sistema de tipos sem reclamar.
Preciso de um Raspberry Pi para aprender ROS 2?
Não. Tudo, exceto os nós de drivers, funciona perfeitamente em um notebook, que é um ambiente melhor para aprender — compilações mais rápidas, uma tela física e nenhum risco de corrupção do cartão SD que faça você perder uma noite. O Pi se torna necessário quando você quiser que o robô carregue seu próprio computador. Se usar um, espere que ele seja o gargalo: um fluxo de câmera e um planejador juntos esgotarão rapidamente a capacidade de um Pi 4.
Por que o comando ros2 run informa que meu pacote não existe, embora ele exista?
Você não disponibilizou o espaço de trabalho nesse terminal. Cada novo terminal desconhece seus pacotes compilados até você executar source install/setup.bash, e o ROS relata o resultado como um pacote ausente, não como um ambiente não disponibilizado. É o problema mais comum do ROS 2, atinge todo mundo repetidamente e a solução padrão é disponibilizá-lo pelo perfil do shell — com a ressalva de que isso oculta o problema quando você realmente tem dois espaços de trabalho.