Construa um robô ROS 2 que vê e segue até um marcador

O que você está construindo

Um robô colocado em algum lugar de uma sala que gira até encontrar um marcador impresso em uma parede e dirige até ele — parando a meio metro de distância, em ângulo reto com a face do marcador, e não apenas perto.

Todas as outras construções deste site executam um programa em um microcontrolador. Esta é um computador com rodas, e isso muda o assunto do projeto. As partes difíceis não são mais temporização e fiação; são saber onde as coisas estão em relação umas às outras e manter várias partes do software honestas entre si enquanto todas executam ao mesmo tempo.

Por que este robô precisa de um computador

Um Arduino não consegue fazer isso, e vale ser preciso sobre o motivo. Não é a velocidade bruta — é que um quadro de câmera ocupa um quarto de megabyte, a detecção ArUco exige álgebra linear com ponto flutuante e tudo isso precisa acontecer enquanto as rodas ainda estão sendo comandadas a 50 Hz. Esse é um trabalho para um sistema operacional com memória e agendamento reais.

O que você ganha em troca dessa máquina Linux é a capacidade de olhar para dentro de um robô em execução. Cada mensagem entre cada parte é um tópico que você pode assinar de um notebook. Quando o robô passa pelo marcador em vez de ir até ele, você não adiciona mensagens de impressão nem regrava o software — executa ros2 topic echo na pose e a vê errada em tempo real.

A forma do grafo de nós

Cinco responsabilidades, um nó para cada uma:

As interfaces são o que torna isso valer a pena. O controlador nunca toca em uma câmera ou em um motor — consome uma transformação e produz um Twist. Isso permite dirigir o mesmo robô por teleoperação com teclado, testar o controlador contra uma transformação falsa sem componentes e, depois, inserir uma pilha de navegação que publique exatamente o mesmo tópico.

Leia nós, tópicos, serviços e ações antes de desenhar sua própria versão dessa tabela. O erro mais comum nesta etapa é transformar o controlador de acoplamento em um serviço — ele é um objetivo de longa duração que precisa poder ser cancelado, e é exatamente para isso que serve uma ação.

Lista de materiais

Este é o robô com dois cérebros, e a lista de peças reflete isso: um computador para percepção e um microcontrolador para as coisas que um computador não faz de forma confiável.

Total: aproximadamente US$ 145–175. Este é o projeto mais caro do site por uma margem larga, e a maior parte do custo é o Pi.

A alimentação é onde esses robôs falham, e a falha é cara. Uma queda de tensão durante uma escrita no cartão SD corrompe toda a imagem do sistema. Use um regulador chaveado dimensionado bem acima do consumo do Pi, nunca compartilhe o trilho com os motores e verifique vcgencmd get_throttled — qualquer valor diferente de zero significa que a fonte é inadequada e que um cartão corrompido está a caminho.

Meça seus marcadores impressos. A solução da pose ArUco escala diretamente com o tamanho do marcador que você declara. Um marcador impresso a 95% pelo “ajustar à página” de uma impressora produz poses 5% erradas em todas as distâncias, e nada no fluxo de processamento informará isso.

Ordem de construção

1 — Faça o ROS 2 funcionar e prove a rede. Siga instalar o ROS 2 em um Raspberry Pi. Não avance até ros2 topic echo no notebook mostrar um tópico publicado no robô. A descoberta por Wi-Fi é a coisa mais provável de consumir uma noite, e você quer que ela aconteça agora, e não enquanto depura visão.

2 — Faça as rodas obedecerem a um Twist. Conecte o Arduino, os encoders e o TB6612FNG, e construa a ponte cmd_vel. Marco: a teleoperação por teclado do notebook dirige o robô real. Calibre aqui a separação entre rodas — tudo abaixo herda esse valor.

3 — Calibre a câmera. Corretamente, com um alvo real, seguindo calibração de câmera e pose ArUco. Uma câmera não calibrada produz poses que parecem plausíveis e estão erradas dezenas de pontos percentuais nas bordas do quadro, o pior modo de falha possível.

4 — Publique o marcador como uma transformação. Não como uma mensagem personalizada com x e y. Publicar camera_link → marker_7 no TF2 permite que o controlador pergunte “onde está o marcador, em base_link?”, e a resposta considera exatamente como a câmera está montada — inclusive o fato de ela estar inclinada, como está.

5 — Dirija até o marcador. Um controlador proporcional com base na direção medida em relação ao robô: vire em direção a ele, avance e pare na distância de aproximação. Isso funciona, mas chega em ângulo, que é o ponto da próxima etapa.

6 — Aproxime-se ao longo da normal. Em vez de dirigir diretamente ao marcador, calcule um ponto de passagem afastado da face do marcador ao longo de sua normal, vá até ele e só então dirija em linha reta. Esta é a diferença entre alcançar o acoplador e acoplar. É também onde a orientação do marcador — a parte da pose que você não precisava até agora — começa a importar, e onde encontrará a ambiguidade de pose.

7 — Coloque tudo em uma máquina de estados. Procurar, aproximar, alinhar, final, concluído, além das transições de saída de cada estado quando o marcador é perdido. Máquinas de estados finitas para comportamento de robôs cobre a estrutura; o que este robô precisa especificamente é um tempo limite de marcador perdido que volte à busca em vez de continuar pela última pose conhecida.

Observações dos componentes que importam

Monte a câmera rigidamente e meça como ela está. Toda pose que o robô calcula é relativa à câmera, e TF2 a transforma em uma pose relativa ao robô usando a transformação que você declara de base_link a camera_link. Uma câmera em suporte flexível torna essa transformação declarada uma mentira que varia com a aceleração.

Incline a câmera para baixo e registre isso. Uma câmera apontada para o horizonte perde o marcador exatamente quando o robô fica perto. De dez a quinze graus para baixo a mantém no quadro durante a aproximação final — e essa inclinação vai para a transformação estática, não para um fator de correção improvisado no controlador.

Meça o marcador com paquímetro. A escala da pose é diretamente proporcional ao tamanho do marcador que você informa ao solucionador. Imprimir a 96% porque a impressora ajustou à página torna cada distância 4% errada, de forma silenciosa e consistente.

Alimente o Pi separadamente dos motores. Um motor travado derruba o trilho, e onde um Arduino apenas reiniciaria sem dano, um Pi corrompe o sistema de arquivos. Use um regulador separado ou outra bateria — este não é o lugar de economizar uma peça.

Mantenha o cabo da câmera longe dos fios dos motores. É uma ligação de alta velocidade sem blindagem. Ruído dos motores acoplado a ela aparece como quadros corrompidos, que aparecem como detecções piscando sem nenhuma razão visível.

Como fica um bom resultado

Duas linhas carregam a lição do projeto inteiro.

Resolução não é gratuita, e uma resolução maior costuma ser pior. Ir de 640×480 para 1080p custa 4–6× o processamento para cerca de 1,7× o alcance de detecção. A menos que você realmente precise ver um marcador mais distante, o quadro menor oferece uma resposta mais rápida e atual — e atualidade importa mais que precisão em um laço de controle.

A linha de latência explica por que existe a divisão em dois cérebros. A 0,3 m/s, 100 ms de latência de visão são 3 cm de deslocamento; girando a 90°/s, são 9° de rotação. Toda medição de visão descreve onde o robô estava. Feche um laço rápido diretamente nela e ele oscilará. A estrutura que funciona é a que este robô usa: o Arduino executa o laço rápido com encoders, e a visão o corrige lentamente — exatamente a mesma forma de fundir GPS com odometria no rover de pontos de passagem, e pelo mesmo motivo.

Obturador rolante, se o robô se mover enquanto olha

Os módulos de câmera padrão do Pi têm obturador rolante: as linhas são expostas uma após outra, então o topo de um quadro é capturado alguns milissegundos antes da parte inferior. Parado, isso é invisível. Girando a 90°/s, os quatro cantos de um marcador ArUco são capturados em quatro orientações diferentes do robô — e a pose resolvida a partir deles está errada de uma maneira que a calibração não consegue corrigir.

Se o robô precisa fazer visão em movimento, é para isso que existe o módulo Global Shutter. Se ele pode parar, olhar e depois se mover, o módulo mais barato é perfeitamente suficiente — e parar para olhar é uma escolha legítima de projeto, não uma solução improvisada.

Quando algo dá errado

Vale perceber essa distribuição antes de começar: quase nada nela é visão computacional. É rede, referenciais, unidades e controle — é isso que construir um robô ROS 2 realmente ensina, e é por isso que o caminho dos fundamentos do ROS 2 passa o tempo em padrões de comunicação e referenciais, e não em OpenCV.

Se este passo for demais, o micromouse ensina mapeamento e planejamento em um microcontrolador sem Linux envolvido, e o robô controlado por celular cobre a metade de “comandos chegam por uma rede” desse problema com uma fração das peças.