Contents — find the section you need
O ROS 2 não é o robô em si. É uma base para executar um driver de câmera, autolocalização, planejamento de trajetória e controle de motores como programas separados (nós) e combiná-los por meio de mensagens e comunicação padronizadas. Você pode começar com um único arquivo Python na fase de protótipo e expandir para C++, execução em tempo real, múltiplos computadores e monitoramento de segurança para um produto. O que importa não é memorizar a API — é projetar quem detém os dados, o tempo, a confiabilidade e o estado seguro no desligamento.
Imagem: Robot Logotipo do Sistema Operacional, Wikimedia Commons (CC BY-SA 4.0). O logotipo identifica o middleware e não garante uma distribuição ou configuração DDS específica.
Resumo de 30 segundos
- Um nó é um processo com uma única responsabilidade, um tópico representa um fluxo contínuo, um serviço representa uma breve solicitação/resposta e uma ação representa uma tarefa longa com feedback intermediário.
- A comunicação do ROS 2 funciona com DDS, e a QoS (confiabilidade, histórico, profundidade, durabilidade, prazo) pode ser escolhida por endpoint. Sensores e controle não precisam usar as mesmas configurações.
-
O TF2 gerencia uma árvore de sistemas de coordenadas juntamente com o tempo. Misture os sistemas
map,odom,base_linke os sistemas de sensores, e o robô irá para o lugar errado, mesmo que a percepção esteja correta. -
Em hardware real, adicione gerenciamento de ciclo de vida, watchdogs, separação de privilégios, registro de logs e mecanismos de segurança para quedas de rede. Trabalhar em simulação não é garantia de segurança.
-
Corrija uma versão com suporte de longo prazo como o ROS 2 Jazzy, juntamente com uma combinação compatível de DDS, sistema operacional e driver, desde o início, e construa um ambiente de trabalho reproduzível.
1. Visão Geral do ROS 2
Figura 1 — No ROS 2, os nós descobrem e se comunicam entre si via DDS. Não apenas os nomes dos tópicos, mas também QoS, tipo, tempo e sistema de coordenadas são tratados como parte do contrato.
Um grafo ROS 2 pode ser configurado em tempo de execução. Um nó de câmera publica imagens, um nó de percepção se inscreve nelas e um nó de controle recebe os resultados, juntamente com a autolocalização, e publica comandos de velocidade. Mesmo se você mover um nó para um computador diferente, o mesmo grafo permanece válido, desde que a descoberta e a serialização do DDS funcionem corretamente.
2. Escolhendo a Primitiva de Comunicação Correta
| Tipo | Onde é usado | Exemplo | Considerações de projeto |
|---|---|---|---|
| Tópico | Fluxo contínuo, muitos para muitos | /scan , /camera/image |
QoS, largura de banda, latência, perdas |
| Serviço | Requisição e resposta curtas | /reset_odometry |
Tempo limite, reentrância |
| Ação | Tarefa de longa duração com progresso | Navegação, captura | Cancelamento, interrupção segura |
| Parâmetro | Configuração de inicialização ou de baixa frequência | Ganhos, nomes de quadros | Tipo, alterar permissões, reprodutibilidade |
Uma mensagem de tópico deve conter não apenas o valor, mas também header.stamp e frame_id. Se o carimbo de data/hora da imagem e o carimbo de data/hora da IMU estiverem dessincronizados, o algoritmo ainda poderá calcular um resultado, mas estimará o movimento incorretamente. Reenviar imagens da câmera com confiabilidade pode sobrecarregar a largura de banda, portanto, escolha a QoS que corresponda às características de cada sensor.
3. QoS como um "Contrato de Comunicação"
As configurações mínimas de QoS a serem verificadas no ROS 2 são: Confiabilidade (Melhor Esforço/Confiável), Durabilidade (Volátil/Local Transitório), Histórico (Manter Última/Manter Todas), Profundidade, Prazo e Vivacidade. Um LiDAR de alta taxa pode ser adequado para o modo Melhor Esforço, que descarta pacotes obsoletos, enquanto os comandos de velocidade, que não toleram mensagens descartadas, devem usar o modo Confiável com um Prazo curto.
Se a QoS do Publicador e do Assinante não forem compatíveis, eles não se comunicarão, mesmo com o mesmo nome de tópico. Verifique as configurações reais com ros2 topic info -v /scan em vez de confiar cegamente na predefinição do driver do sensor. Ao atravessar uma rede, teste MTU, retransmissão Wi-Fi, restrições de multicast e sincronização de tempo simultaneamente.
4. TF2 e Tempo
A pose de um robô é expressa como uma transformação entre sistemas de coordenadas. Uma árvore típica se parece com:
map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
├── base_laser
├── imu_link
└── camera_link
map é o sistema de coordenadas global de longo prazo, odom é a odometria suave de curto prazo e base_link é o sistema de coordenadas do veículo. SLAM corrige map → odom, enquanto a estimativa da roda/IMU atualiza odom → base_link em alta frequência. TF2 armazena transformações com timestamps e as interpola para o tempo de aquisição de cada sensor.
Padronize os sistemas de coordenadas como destros e explicite a diferença entre o sistema de coordenadas óptico (z para frente, x para a direita, y para baixo) e o sistema de coordenadas do veículo (x para frente, y para a esquerda, z para cima). Corrija as transformações estáticas com static_transform_publisher e não publique uma transformação dinâmica como estática. Um ciclo ou múltiplos pais na árvore TF é um erro de projeto.
5. Pacotes e o Fluxo de Implementação
Um nó Python ROS 2 mínimo se parece com isto.
import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32
class Speed(Node):
def __init__(self):
super().__init__('speed_node')
self.pub = self.create_publisher(Float32, '/speed', 10)
self.timer = self.create_timer(0.02, self.tick) # 50 Hz
def tick(self):
msg = Float32(); msg.data = 0.2
self.pub.publish(msg)
rclpy.init(); node = Speed(); rclpy.spin(node)
Em hardware real, não envie comandos de velocidade diretamente para o motor — coloque um nó a montante, limitação de velocidade, parada de emergência e monitoramento de hardware entre eles. Mesmo ao usar o rclcpp do C++, verifique os grupos de retorno de chamada, o Executor, a alocação de memória e o comportamento em tempo real.
Separe o espaço de trabalho em src, build, install e log e resolva as dependências com rosdep. Fixe o SO, o DDS e o compilador com Docker ou um devcontainer e compile ros2 doctor, ros2 node list, ros2 topic hz e tf2_tools tanto para CI quanto para diagnósticos de campo.
6. Ciclo de Vida e Segurança
Sensores e atuadores não devem necessariamente aceitar comandos instantaneamente ao serem ligados. As transições de estado do Nó de Ciclo de Vida — Não Configurado → Inativo → Ativo → Finalizado — separam a inicialização do driver, a calibração, as verificações de comunicação e a autorização de saída. Quando um watchdog perde o sinal de atividade, zere o comando de velocidade e também abra o freio ou o relé no hardware.
Em termos de segurança, a comunicação de mensagens do ROS 2 por si só não atende aos padrões de segurança funcional. Verifique o escopo aplicável das normas IEC 61508/ISO 26262/ISO 13849 e similares, e separe as funções de segurança em um sistema de monitoramento, um MCU certificado e um dispositivo físico de parada de emergência. Ao conectar-se a uma rede, adote chaves e certificados SROS 2, segurança DDS, controle de acesso e auditoria de logs.
7. Ecossistema Atual e Pesquisa
O Nav2 integra autolocalização, mapeamento, planejamento de trajetória e controle por meio de ações e gerenciamento de ciclo de vida, e o ros2_control padroniza a fronteira entre hardware e controladores. O MoveIt 2 lida com a cinemática do manipulador, verificação de colisões e planejamento de trajetória. A simulação no Gazebo ou Webots e a reprodução de logs de sensores com o rosbag2 permitem testes de regressão sem interromper o funcionamento do robô real.
A pesquisa está avançando em comunicação sem cópia, pipelines de imagem tipados que utilizam GPUs/NPUs, executores determinísticos, aprendizado distribuído e robótica em nuvem que vai além do DDS. Ao adotar um novo recurso, teste não apenas benchmarks, mas também quedas de rede, desvios de tempo, reinicializações de processos, falhas de sensores e comprimento de mensagens malformadas.
Resumo
O ROS 2 transforma um robô de uma coleção de peças em um sistema distribuído reutilizável. Projete as responsabilidades dos nós, a QoS dos tópicos, as coordenadas e o tempo do TF2, o ciclo de vida e os estados seguros antecipadamente, e todo o sistema permanecerá robusto mesmo ao substituir algoritmos.
A conectividade entre os nós garante a operação correta?
Os timestamps, frames, QoS e taxas também devem corresponder.
Receber dados não garante que eles sejam utilizáveis para controle.
Comentários
Entre na sua conta para continuar.
Ainda não há dados.