Processamento ao vivo ou dados gravados: do que realmente precisa uma VPN?
Decida qual trabalho do robô tem de atravessar a rede: resultados pontuais, telemetria de observação ou um conjunto de dados gravado. Três condições e, depois, os comandos do bag.
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.
| Arrangement | What depends on the link | What stays onboard |
|---|---|---|
| Live remote processing | The exchange and any timely result the workstation returns | Only what the remote step does not block |
| Onboard processing, remote observation | The declared telemetry or display stream | The processing loop itself |
| Local recording, later analysis | Transfer of one selected dataset | The 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.