ROS 2 e Interoperabilidade DDS: Guia Prático para Integração Perfeita

ROS 2 depende de DDS para sua camada de comunicação subjacente, ainda assim alcançar interoperabilidade perfeita entre uma implantação DDS nativa e ROS 2 ainda pode apresentar desafios sutis. Este guia destila os passos práticos e ajustes de configuração que se provaram eficazes a partir do release "Bouncy Bolson" (julho 2018) do ROS 2, ajudando equipes a evitar armadilhas comuns e alavancar todo o poder do Connext DDS dentro do ROS 2.

Estado Atual do ROS 2

ROS 2 é um framework em rápida evolução, e futuros releases podem introduzir nuances adicionais de interoperabilidade. No entanto, quando você roda ROS 2 com a camada RMW rmw_connext_cpp, você ainda está usando a stack nativa Connext DDS. Isso significa que você retém todos os recursos avançados do Connext — como controle QoS de grão fino e suporte multi-transporte — enquanto desfruta das abstrações de nível superior do ROS 2.

Configurações-Chave de Interoperabilidade

Nomes de Tópicos e Partições

ROS 2 codifica o namespace de um tópico no nome do tópico ou na partição DDS. Todos os tópicos de usuário ROS 2 residem no namespace "rt" (ROS Topic). Em DDS isso é representado como:

Tipos de Dados de Tópicos

Quando a camada RMW Connext está ativa, ROS 2 anuncia todo tópico "rt/*" com um tipo de serialização genérico. Como resultado, uma aplicação DDS pura que publica o dado original fortemente tipado experimentará um mismatch de QoS e não conseguirá conectar.

A solução mais direta é suprimir a publicação automática de type-code dos participantes ROS 2. Adicione um arquivo USER_QOS_PROFILES.xml ao diretório que lança seus nós ROS 2. Uma configuração mínima que esconde o type code e desabilita compartilhamento de type object parece assim:

Sinta-se à vontade para ajustar a configuração de confiabilidade para atender sua aplicação; o exemplo acima usa "Best Effort" como ponto de partida.

Lembre-se que este arquivo QoS aplica-se apenas a nós ROS 2 iniciados do mesmo diretório. Se você precisa de configurações isoladas, coloque um USER_QOS_PROFILES.xml dedicado ao lado de cada pasta de launch do nó.

Seleção de Transporte

Quando um sistema DDS e um sistema ROS 2 compartilham a mesma rede, avisos sobre transports ausentes ou não suportados (ex: udpv6 não disponível em um participante que só suporta udpv4) podem aparecer. Para evitar tais avisos e garantir conectividade confiável, configure preferências de transporte explicitamente.

1. Defina os transports permitidos em USER_QOS_PROFILES.xml adicionando uma máscara <transport_builtin> dentro de <participant_qos>:

<participant_qos> <transport_builtin> <mask>UDPV4|SHMEM</mask> </transport_builtin> </participant_qos> 

2. Crie um arquivo NDDS_DISCOVERY_PEERS no diretório de launch e liste os endereços de peers que você deseja descobrir. Um exemplo separado por vírgulas que desabilita descoberta multicast é:

localhost,192.168.1.12,shmem:// 

Escolhendo a Camada RMW no ROS 2

Sempre defina a variável de ambiente RMW_IMPLEMENTATION para rmw_connext_cpp antes de iniciar nós ROS 2:

export RMW_IMPLEMENTATION=rmw_connext_cpp 

Ou passe inline ao lançar um nó:

RMW_IMPLEMENTATION=rmw_connext_cpp ros2 run demo_nodes_cpp talker 

Sequências e Strings Não Limitadas

Alguns tópicos ROS 2 contêm sequências ou strings não limitadas. Se sua aplicação DDS precisa consumir ou publicar estes tópicos, habilite "Unbounded Support" no gerador de código DDS. Consulte a documentação RTI para como alternar esta opção durante geração de código.

Próximos Passos com RTI

Cobriremos uma lacuna temporária no conjunto de recursos atual do ROS 2 — gravação e replay de dados de tópicos — na próxima edição desta série. Enquanto isso, se você está pronto para implantar uma solução ROS 2 robusta apoiada por DDS, entre em contato com nossos especialistas RTI. Nós ajudaremos a ajustar sua configuração e acelerar time-to-market.