ROS 2 sobre malha sem fio: configurações de QoS DDS para equipes de robôs móveis

As equipes de robôs móveis geralmente se comunicam de maneira confiável em um laboratório e, em seguida, desenvolvem comandos atrasados, faltam atualizações de sensores ou recuperam lentamente quando as rotas da malha mudam. UM A malha sem fio ROS 2 adiciona largura de banda flutuante, perda de pacotes e alteração na contagem de saltos, enquanto o DDS pode retransmitir ou enfileirar dados que já estão obsoletos. As configurações de QoS ajudam a controlar a confiabilidade, o histórico, a profundidade, a durabilidade, o prazo e a vida útil de cada tópico, mas políticas incompatíveis de editores e assinantes podem interromper totalmente a entrega.

A chave é saber quais fluxos precisam de cada amostra, quais precisam apenas da mais nova e como evitar que grandes cargas sobrecarreguem um link em recuperação.

Comece com o tráfego, não com o menu QoS

Decida se o frescor ou a integridade são mais importantes

Comece perguntando o que acontece quando uma mensagem é perdida e o que acontece quando ela chega atrasada. Varreduras LiDAR, quadros de câmeras, odometria, atualizações de localização e telemetria de movimento são continuamente substituídos. Perder uma amostra pode ser aceitável, enquanto entregá-la após várias amostras mais recentes pode corromper decisões locais ou desperdiçar tempo de processamento.

Transições de missão, atribuições de tarefas, alterações de configuração, eventos de segurança e algumas transferências de mapas têm requisitos diferentes. Um evento discreto ausente pode deixar os robôs em estados operacionais inconsistentes, de modo que a retransmissão limitada pode ser justificada. Essa distinção é mais importante do que apenas o tipo de carga útil: um comando de velocidade pequena pode ser perigoso quando obsoleto, enquanto um instantâneo de mapa grande pode permanecer útil após um atraso.

Classificar o tráfego por atualização e integridade evita um erro comum de malha sem fio ROS 2: definir cada tópico como CONFIÁVEL porque confiável parece mais seguro. O DDS confiável retém amostras não reconhecidas e retransmite dados perdidos, criando sobrecarga que a comunicação de melhor esforço evita. O perfil de dados do sensor ROS 2 padrão, portanto, usa a confiabilidade de melhor esforço com uma fila menor, onde a entrega oportuna geralmente é mais importante do que o recebimento de todas as leituras.

Dê a cada tópico um orçamento de entrega

Cada tópico entre robôs precisa de quatro limites: duração máxima da mensagem útil, taxa de perda aceitável, frequência de atualização necessária e tempo máximo de recuperação após a desconexão. Esses limites transformam expectativas vagas, como “baixa latência”, em requisitos testáveis. Um fluxo de comando pode precisar de um limite de idade medido em dezenas de milissegundos, enquanto um instantâneo de mapa pode tolerar segundos se o robô continuar operando com segurança com sua cópia local.

Estime a carga oferecida a partir do tamanho da carga serializada, da taxa de publicação e do número de destinos. Em seguida, compare esse valor com o goodput multi-hop medido, em vez da taxa de dados nominal de um rádio. Deixe capacidade para confirmações, retransmissões, tráfego de descoberta, tráfego de gerenciamento de rotas e editores simultâneos.

Mantenha o tráfego interno do robô fora da malha compartilhada

Nem todo tópico ROS 2 deve ultrapassar os limites do robô. Feeds brutos de câmera, nuvens de pontos completos, dados de depuração e saídas de percepção intermediária geralmente pertencem ao robô que os produz. Publicar apenas detecções, rastreamentos de objetos, planos locais, nuvens reduzidas ou alterações de mapas reduz a demanda do canal compartilhado sem alterar o comportamento do DDS.

Esta etapa de filtragem é especialmente valiosa em uma malha sem fio ROS 2 multi-robô, onde um fluxo desnecessário de alta taxa pode consumir a capacidade necessária para vários tópicos de coordenação. A remoção do tráfego geralmente produz um sistema mais previsível do que tentar proteger um link sobrecarregado com filas mais profundas e novas tentativas adicionais.

Perfis práticos de QoS para tópicos comuns de frota

Fluxos de sensor e estado atualizado com frequência

Sensores de alta taxa e tópicos de estado geralmente precisam da amostra mais recente disponível, não de uma sequência histórica completa. Um perfil inicial prático é BEST_EFFORT, VOLATILE e KEEP_LAST com profundidade entre um e cinco. A profundidade um é adequada para dados que são imediatamente substituídos, enquanto uma fila um pouco maior pode absorver pequenos atrasos no agendamento de retorno de chamada sem criar um longo backlog.

O LIFESPAN pode adicionar outra proteção, fazendo com que as mensagens expirem após seu período útil. DEADLINE tem um propósito diferente: expressa o intervalo esperado entre as mensagens e pode disparar um evento quando essa expectativa for perdida. Nenhuma das políticas aumenta a capacidade do link, mas ambas facilitam a detecção e o tratamento de fluxos obsoletos ou interrompidos.

O perfil exato deve refletir o consumidor. Um nó local para evitar obstáculos pode precisar de verificações frequentes com idade mínima, enquanto um painel de frota pode aceitar uma taxa de atualização mais baixa. Enviar ambos através da mesma malha sem fio ROS 2 não significa que eles exijam configurações idênticas de confiabilidade, profundidade ou vida útil.

Comandos e eventos de coordenação precisam de tratamento diferenciado

Comandos contínuos e eventos de coordenação discretos não devem compartilhar um perfil padrão. Os fluxos de velocidade, direção e correção de formação são atualizados repetidamente, portanto, amostras antigas não devem ficar na fila atrás de retransmissões. Um histórico superficial, uma vida útil curta e um tempo limite no nível do aplicativo ajudam a garantir que um robô pare ou entre em um modo de fallback definido quando novos comandos desaparecerem.

A aceitação de tarefas, mudanças no modo de operação e transições de missão podem exigir entrega CONFIÁVEL porque cada evento muda o estado compartilhado. Mesmo assim, a história deve permanecer limitada. Repetir uma longa sequência de comandos substituídos após a recuperação de uma rota pode ser mais prejudicial do que relatar a interrupção e ressincronizar o estado atual da missão.

A confiabilidade do DDS é apenas uma camada de proteção. Todo robô móvel deve impor a expiração do comando local, restrições de movimento e comportamento de perda de comunicação, independentemente da rede. Uma malha sem fio ROS 2 pode melhorar o alcance e a resiliência de rota, mas não pode decidir se um comando antigo ainda é seguro.

Mapas, configuração e robôs de adesão tardia

Use RELIABLE com TRANSIENT_LOCAL quando um robô ingressando ou se reconectando precisar do estado publicado mais recente. Mapas atuais, cercas geográficas, modos operacionais compartilhados e instantâneos de configuração geralmente se enquadram nesse padrão. KEEP_LAST(1) geralmente é mais adequado do que reter todas as versões porque apenas o instantâneo completo mais recente permanece operacionalmente relevante.

KEEP_ALL deve ser reservado para dados cuja sequência completa seja realmente importante e cujos requisitos de recursos sejam conhecidos. O armazenamento Keep-All permanece sujeito a limites de recursos de middleware, portanto não é uma garantia ilimitada. A durabilidade local transitória também torna o editor responsável por reter amostras para assinaturas tardias.

A compatibilidade deve ser verificada em ambos os lados. Um editor de melhor esforço não pode satisfazer um assinante confiável, e um editor volátil não pode satisfazer uma assinatura local transitória. Editores confiáveis ​​podem atender assinantes com o melhor esforço, enquanto editores locais temporários podem enviar novas mensagens para assinantes voláteis. A entrega histórica retida requer configurações locais transitórias compatíveis.

Impedir que mensagens grandes assumam o controle do link

Reduza a fragmentação antes de adicionar novas tentativas

Imagens, grades de ocupação e nuvens de pontos densas são divididas em múltiplas unidades de transporte antes de cruzarem a rede. Quando um grande datagrama UDP é fragmentado na camada IP, a perda de um fragmento impede a reconstrução do datagrama completo. Os fragmentos restantes podem ocupar os buffers do kernel até expirarem, fazendo com que a conexão pareça paralisada e bloqueando o tráfego mais recente.

A degradação de grandes cargas úteis em conexões sem fio ROS 2 é comumente associada a três mecanismos conectados: fragmentação IP excessiva, tempo de retransmissão ineficiente e explosões de buffer congestivas. As alterações de parâmetros DDS compatíveis com os padrões podem reduzir esses efeitos sem exigir um protocolo de aplicação diferente.

Meça o MTU do caminho real em toda a malha sem fio ROS 2, incluindo criptografia, túneis, interfaces virtuais e todos os segmentos roteados. Onde a configuração de transporte permitir, reduza o tamanho da mensagem RTPS ou UDP o suficiente para evitar a fragmentação da camada de rede. Um valor calculado a partir de uma MTU Ethernet de 1.500 bytes é apenas uma hipótese inicial porque os cabeçalhos e o encapsulamento podem reduzir o tamanho utilizável.

Mantenha as filas de histórico menores que a janela de recuperação

Durante uma interrupção de rota, um publicador confiável pode continuar produzindo mensagens enquanto as confirmações param de chegar. As amostras não reconhecidas acumulam-se no histórico até que os limites de recursos sejam atingidos. Quando a conectividade retornar, o caminho restaurado deverá transportar as publicações atuais, controlar o tráfego e o backlog retido ao mesmo tempo.

Escolha a profundidade do histórico a partir do número de amostras que permanecem úteis após a reconexão. Um fluxo de estado de 20 Hz com idade útil de 250 milissegundos raramente precisa de dezenas de amostras enfileiradas; a maioria deles já estaria obsoleta. O estado substituível deve favorecer a amostra mais recente, enquanto as sequências de eventos essenciais precisam de um plano de recuperação limitado.

Grandes amostras confiáveis ​​exigem uma verificação adicional: a rota esperada mais fraca pode drenar a fila sem atrasar o tráfego atual? Um histórico profundo pode reduzir a perda imediata de dados, mas também aumenta o uso de memória, o tempo de recuperação e a probabilidade de um aumento de tráfego pós-interrupção. O histórico retido excessivo pode produzir buffer bursts que pioram o congestionamento após o retorno da conectividade.

Fique atento a rajadas de retransmissão

O DDS confiável usa trocas de pulsação e confirmação para identificar amostras ausentes e acionar a retransmissão. Ciclos de recuperação pouco frequentes podem permitir que diversas perdas se acumulem antes de serem reenviadas, produzindo rajadas curtas que excedem a capacidade momentânea do link. Períodos de pulsação, fragmentação e intervalos de retransmissão também interagem estreitamente sob condições sem fio com perdas.

Teste o tempo de retransmissão em relação ao intervalo de publicação de cada tópico, em vez de aplicar um valor para toda a frota. Meça o atraso de recuperação, a latência final, o jitter, a sobrecarga do pacote de controle e a carga da CPU após cada alteração. A sinalização de recuperação mais rápida pode reduzir o atraso e o tamanho do burst, mas o tráfego de controle excessivo pode consumir processamento e largura de banda.

Nenhum ajuste de tempo pode resgatar uma malha sem fio ROS 2 cuja carga oferecida sustentada excede a capacidade utilizável. Quando o link permanece saturado, novas tentativas adicionam tráfego a um caminho já sobrecarregado.

Decida quando alterar a carga útil

O ajuste de QoS deve terminar onde a arquitetura do aplicativo se torna o problema maior. Reduza a resolução da imagem, a qualidade da codificação ou a taxa de quadros quando os fluxos visuais dominarem o canal. Corte ou reduza a resolução de nuvens de pontos antes da transmissão e publique trilhas de objetos, resultados de capacidade de travessia ou atualizações de mapas locais quando os colegas de equipe não precisarem de observações brutas.

O processamento de bordas geralmente fornece a solução mais limpa. Cada robô pode reter localmente dados de sensores de alta largura de banda e distribuir apenas as informações necessárias para a coordenação. Isto não compromete a confiabilidade do DDS; é uma decisão deliberada adequar a procura de comunicação à capacidade física da rede móvel.

Teste o perfil em robôs em movimento, não apenas em uma rede de bancada

Recrie as rotas e falhas que a frota encontrará

Um teste fixo de um salto não pode representar uma malha sem fio ROS 2 móvel. A validação deve incluir a rota mais curta, a contagem máxima de saltos planejada, movimento entre posições de relé, interferência crescente, tráfego assimétrico, interrupções curtas, interrupções longas, reconexão, adesão tardia e publicação simultânea por vários robôs.

Grave mais do que a latência média. As medidas úteis incluem:

●  Frequência de atualização recebida e taxa de perda de mensagens.

●  Idade da mensagem, latência mediana, latência final e jitter.

●  Tempo de descoberta ou reconexão após uma mudança de caminho.

●  Crescimento da fila de gravadores e leitores durante a interrupção.

●  Tempo necessário para limpar dados retidos úteis.

●  Uso de CPU e memória tanto por editores quanto por assinantes.

Avalie cada resultado em relação ao orçamento de entrega criado anteriormente. Um tópico de localização pode falhar porque sua frequência de atualização fica abaixo do requisito de controle, mesmo quando todas as amostras eventualmente chegam. Por outro lado, uma transferência de mapa poderá passar apesar da latência mais alta se for concluída dentro da janela de recuperação permitida.

Use telemetria de malha para explicar o comportamento do DDS

As métricas do ROS 2 revelam o que o aplicativo experimenta, enquanto a telemetria da malha ajuda a explicar por que isso aconteceu. Compare o desempenho do tópico com a contagem de saltos, alterações de topologia, intensidade do sinal, relação sinal-ruído, tráfego de upload e download e tempo de troca de rota. A correlação de ambas as camadas evita que as equipes culpem a QoS por uma mudança no caminho de rádio ou culpem a malha por configurações incompatíveis de editor e assinante.

Os módulos WDS MIMOmesh OEM/ODM e unidades aerotransportadas leves usam uma arquitetura totalmente IP com roteamento dinâmico distribuído e sem centro e modos de retransmissão multi-hop. Suas funções de gerenciamento de rede fornecem informações de topologia, intensidade de campo, SNR, tráfego, distância do nó e status operacional que os engenheiros podem comparar com a latência, perda e comportamento da fila do ROS 2.

As taxas de dados do produto e os números de atraso de salto único devem permanecer como referências de planejamento, em vez de garantir o desempenho do aplicativo. O comportamento real de ponta a ponta também inclui profundidade de rota, ocupação de canal, recuperação de pacotes, serialização, filas de middleware e processamento de nós. Em um movendo a malha sem fio ROS 2 , o bom desempenho medido na rota operacional mais fraca deve impulsionar as taxas de publicação e os limites de histórico.

Altere uma variável de cada vez

Comece confirmando nomes de tópicos, tipos de mensagens e compatibilidade de QoS. Teste a descoberta separadamente da transferência de dados porque um nó que nunca descobre que seu peer tem uma falha diferente de um endpoint correspondente que perde pacotes. Eventos de QoS incompatíveis podem ajudar os aplicativos a detectar incompatibilidades de políticas, em vez de deixar a falha sem explicação.

Estabeleça uma rota e um padrão de movimento repetíveis e, em seguida, ajuste uma variável por corrida. Altere a confiabilidade, a profundidade, a durabilidade, a vida útil, a taxa de publicação, o tamanho da carga útil ou o limite de fragmentação de forma independente. A repetição do mesmo cenário permite identificar se uma aparente melhoria vem da mudança de QoS ou de um melhor caminho de rádio.

Defina as condições de aprovação antes do teste. Os exemplos incluem uma idade máxima de comando, uma frequência mínima de localização, um tempo máximo para um robô reconectado receber o mapa atual e um limite no tempo de drenagem do backlog. O perfil final deve passar pela rota realista mais fraca e não apenas fornecer médias impressionantes na bancada de testes.

 

Conclusão

A comunicação confiável da frota depende da correspondência do comportamento do DDS com a finalidade de cada tópico. Fluxos de sensores recentes geralmente precisam de filas superficiais de melhor esforço, enquanto eventos de missão e reconexão de robôs podem exigir confiabilidade limitada ou durabilidade local transitória. A fragmentação, o crescimento do backlog e o goodput medido de vários saltos devem moldar o perfil final.

Para equipes que estão construindo uma malha sem fio ROS 2, a Shenzhen Sinosun Technology Co., Ltd. oferece módulos MIMOmesh OEM/ODM e rádios aerotransportados leves para implantações móveis de vários saltos. Combinadas com testes disciplinados de QoS, essas plataformas podem ajudar a reduzir o tráfego obsoleto, encurtar a recuperação e manter a largura de banda compartilhada focada em dados operacionalmente úteis.

 

Perguntas frequentes

P: O ROS 2 é adequado para comunicação sem fio entre vários robôs?

R: Sim, mas os links sem fio exigem configurações de QoS específicas do tópico. A confiabilidade, a profundidade da fila, a durabilidade e a taxa de carga útil devem refletir a perda de pacotes, a latência, a mobilidade e a largura de banda disponível.

P: Qual configuração de confiabilidade de QoS funciona melhor em uma malha sem fio ROS 2?

R: Use o melhor esforço para fluxos de sensores atualizados com frequência e entrega confiável e limitada para comandos, eventos de missão, mapas ou dados de configuração que não devem ser perdidos.

P: Por que os editores e assinantes do ROS 2 às vezes não conseguem se conectar?

R: Políticas de QoS incompatíveis podem impedir a comunicação. As incompatibilidades comuns envolvem configurações de confiabilidade, durabilidade, prazo ou vivacidade entre o perfil oferecido pelo editor e o perfil solicitado pelo assinante.

P: Como as grandes mensagens LiDAR ou de câmera devem ser tratadas em uma rede mesh?

R: Reduza o tamanho da carga útil, evite a fragmentação de IP, limite as taxas de publicação e mantenha as filas superficiais. O processamento local ou as saídas compactadas geralmente apresentam melhor desempenho do que a transmissão de cada amostra bruta do sensor.

P: Que profundidade de histórico as equipes de robôs móveis devem usar?

R: Escolha a profundidade de acordo com o tempo de vida da mensagem e as necessidades de recuperação. Use a profundidade um para estado substituível, enquanto eventos essenciais podem precisar de uma fila maior, mas estritamente limitada.