Um robô que deixa de ser útil a uma sala de distância tem um problema de ligação ou de carga de trabalho muito antes de ter um problema de VPN. A cifra protege um caminho, mas não amplia a cobertura de rádio nem faz um cálculo remoto terminar mais cedo. A decisão à sua frente é qual trabalho tem realmente de atravessar a rede, e essa resposta costuma remover mais tráfego do que as pessoas esperam. Três condições decidem isso, e a taxa de transferência não é uma delas.

Três arranjos, uma pergunta de dependência

A tabela separa os arranjos pelo que depende da ligação, não pelo software que aparece no diagrama.

ArrangementWhat depends on the linkWhat stays onboard
Live remote processingThe exchange and any timely result the workstation returnsOnly what the remote step does not block
Onboard processing, remote observationThe declared telemetry or display streamThe processing loop itself
Local recording, later analysisTransfer of one selected datasetThe entire run, including raw sensors

Nenhuma linha dessa tabela é um argumento de segurança. As funções de controlo e de segurança continuam a precisar de uma resposta qualificada para atraso, perda de pacotes e ligação interrompida, e nenhum indicador de túnel a fornece. A tabela mostra onde vive a dependência, e é essa a parte que um projeto de rede consegue realmente mudar.

Primeira condição: a resposta tem de ser pontual?

Se um resultado remoto alimenta um controlador, a rede fica dentro do ciclo de controlo, e o seu atraso, jitter e falhas passam a ser propriedades do controlo. Se o mesmo resultado alimenta apenas um ecrã, um painel ou uma pessoa a observar, o atraso idêntico é puramente cosmético.

Trabalho em ciclo fechado por uma ligação sem fios é possível, e é também aí que nascem a maioria dos relatos de "a VPN está lenta", porque o túnel é o componente visível enquanto o rádio e o encaminhamento são a causa. Meça o tempo de ida e volta da mensagem real e não o ping do próprio túnel, e depois pergunte se o número cabe no orçamento do ciclo. Se não cabe, passe o passo para bordo em vez de negociar um nível de serviço mais exigente para uma ligação que ninguém na sala controla. Registe o número medido com as condições em que foi obtido, porque o próximo relatório chegará sem elas.

Segunda condição: que ritmo, direção e interrupção pode declarar?

Escreva os dados, o ritmo, a direção e a interrupção mais longa que a aplicação tolera. Um fluxo de câmara ascendente e um canal de comandos descendente falham de formas diferentes, e uma interrupção que uma inspeção estacionária tolera termina com uma tarefa em movimento.

Mantenha a ligação física e o túnel separados ao comparar opções, porque um rádio mais forte e uma carga menor são reparações distintas. Uma transferência grande que acaba por concluir não prova nada sobre um resultado sensível ao tempo a chegar de forma consistente, e um túnel saudável não prova nada sobre o rádio por trás dele.

Depois reduza a procura em vez de a defender. Reduza a amostragem do fluxo de observação, envie resumos ou deltas, e deixe os dados brutos dos sensores a bordo, onde o armazenamento é barato e a transmissão não. Uma carga útil menor enfraquece o argumento a favor de uma ligação mais rápida e muitas vezes elimina a necessidade dela.

Terceira condição: quem tem de ver, e o que fica local

A observação é normalmente um requisito muito menor do que o processamento. Se uma pessoa tem de ver a câmara e tem de existir um registo depois, isso é telemetria mais armazenamento; se um modelo tem de correr, pergunte primeiro se pode correr a bordo com apenas o resultado encaminhado. Passar o passo pesado para bordo remove a dependência síncrona e deixa uma transferência que pode ser repetida.

Existirem dois participantes ROS no mesmo robô não justifica um túnel por si só. A alcançabilidade dos nós, a autorização da aplicação e um plano de recuperação local são problemas separados, e uma VPN responde apenas ao primeiro, e só para o tráfego que lhe pedem para encaminhar.

Gravar um conjunto de dados é um projeto próprio, com comandos próprios

Para um exemplo ligado a uma versão, o tutorial de gravação do ROS 2 Jazzy cobre gravar tópicos selecionados, inspecionar o bag resultante e reproduzi-lo. Grave os tópicos de observação aprovados, dê um nome à execução e guarde as definições das mensagens e a configuração ao lado.

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

Não grave todos os tópicos só porque a ferramenta torna isso fácil. O armazenamento enche-se, os dados de câmara e de localização são sensíveis, e um bag de tópicos sem etiqueta é um problema de análise para quem o abrir a seguir. A distribuição instalada também decide os comandos: ferramentas escritas para bags do ROS 1 não passam para bags do ROS 2, por isso alinhe a documentação com a versão instalada no robô.

Reproduza num ambiente de análise ou simulação isolado. Reproduzir tópicos de comando gravados nos atuadores de um robô vivo é um acidente, e a prevenção é um domínio ROS separado ou nenhum hardware no ciclo.

Decida onde pertence a dependência e escreva-o: uma VPN protege uma troca que tem de acontecer, o processamento a bordo remove uma troca que nunca precisou de ser síncrona, e um conjunto de dados gravado substitui um consumidor ao vivo por um posterior. Depois teste o caso desligado de propósito, com a tarefa local ainda a correr, antes de alguém declarar o projeto terminado.

Artigos relacionados