ROS 2 por VPN: a descoberta não é o caminho dos dados

Dois nós ROS 2 nos extremos opostos de uma VPN podem listar os tópicos um do outro e ainda assim não entregar uma única mensagem. A descoberta e os dados do utilizador são trocas separadas com caminhos separados, e um servidor de descoberta não retransmite cargas úteis. Verificar um e assumir o outro é como as equipas acabam por substituir o middleware quando o túnel simplesmente nunca transportou os dados. O procedimento abaixo separa os dois resultados antes de algo ser trocado.

O que o servidor de descoberta transporta realmente

No Fast DDS, um Discovery Server distribui informações sobre endpoints: quem publica, quem subscreve e que QoS cada um espera. Depois de os pares se conhecerem, os dados do utilizador viajam diretamente entre eles em vez de passarem por esse servidor. Chegar ao servidor prova que o intermediário das apresentações responde, e nada mais. Uma VPN encaminhada ainda precisa de um caminho funcional nos dois sentidos entre os endereços que os pares anunciam.

Essa distinção também explica falhas parciais, em que os pares existentes continuam a trocar dados enquanto a nova descoberta deixa de funcionar. Trate-as como duas investigações.

Leia o RMW que os nós usam realmente

O ROS 2 pode carregar middleware diferente, e uma variável exportada na sua shell não chega a processos iniciados noutro local. Pergunte ao sistema em execução em vez de ao histórico do terminal.

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

Uma variável não definida significa normalmente o valor predefinido instalado, que pode diferir entre máquinas na mesma experiência. O relatório também indica a distribuição e o middleware em uso, por isso compare-os nos dois lados do túnel antes de assumir que coincidem. O daemon da linha de comandos do ROS memoriza o estado em cache, por isso reinicie-o depois de alterar o ambiente em vez de deixar um daemon obsoleto responder pela configuração antiga. Anote a distribuição e o RMW de ambos os anfitriões nas notas do teste enquanto a sessão estiver aberta.

Teste a descoberta e os dados como dois resultados

Escolha um tópico inofensivo e meça a apresentação separadamente da entrega. O comando info lista endpoints e QoS, enquanto o echo prova se uma mensagem atravessa realmente a ligação.

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

O aparecimento de endpoints na saída do info é um resultado de descoberta. A chegada de uma mensagem ao subscritor é um resultado de transporte, e só o segundo exercita o caminho de que a aplicação precisa. Quando a descoberta funciona e o echo expira, inspecione os endereços anunciados e a rota de regresso em vez do serviço de descoberta. Execute ambos os comandos a partir de cada anfitrião, porque uma rota VPN assimétrica revela-se muitas vezes apenas de um lado.

Altere uma dependência de cada vez

Quando o caminho dos dados falha, evite alterar o middleware, o modo de descoberta e o tamanho das mensagens na mesma sessão, pois depois nenhum resultado pode ser atribuído. O RMW Zenoh é uma alternativa legítima, mas o seu router torna-se outra dependência que tem de ser alcançável através do túnel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Com esse RMW, o router transporta a descoberta na disposição predefinida do Jazzy, e aí a descoberta multicast está desativada, por isso a dependência pertence às suas notas e não a uma suposição emprestada de outro middleware. Mantenha a carga de trabalho fixa enquanto altera uma definição, depois repita o teste echo e registe a direção, a taxa de mensagens e as condições da ligação. Repita a comparação duas vezes para separar uma melhoria real de uma reconexão afortunada. Se uma alteração melhorar a descoberta enquanto a entrega fica igual, moveu o serviço de apresentação, não o caminho dos dados.