Procesamento en directo ou datos gravados: que necesita realmente unha VPN?
Decida que traballo do robot debe cruzar a rede: resultados oportunos, telemetría de observación ou un conxunto de datos gravado. Tres condicións e despois os comandos bag.
Un robot que deixa de ser útil a unha habitación de distancia ten un problema de enlace ou de carga de traballo moito antes de ter un problema de VPN. O cifrado protexe un camiño; non amplía a cobertura de radio nin fai que un cálculo remoto remate antes. A decisión que ten diante é que traballo debe cruzar realmente a rede, e esa resposta adoita eliminar máis tráfico do que a xente espera. Tres condicións o resolven, e o rendemento non é unha delas.
Tres disposicións, unha soa pregunta sobre a dependencia
A táboa separa as disposicións polo que depende do enlace, non por que software 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 |
Ningunha fila desa táboa é un argumento de seguridade. As funcións de control e seguridade seguen necesitando unha resposta cualificada para o retardo, a perda de paquetes e unha conexión caída, e ningún indicador de túnel a proporciona. A táboa di onde vive a dependencia, que é a parte que un deseño de rede si pode cambiar.
Condición un: ten que ser oportuna a resposta?
Se un resultado remoto alimenta un controlador, a rede está dentro do bucle de control, e o seu retardo, o seu jitter e os seus cortes convértense en propiedades do control. Se o mesmo resultado só alimenta unha pantalla, un panel ou a unha persoa que mira, o mesmo retardo é cosmético.
O traballo en bucle pechado por un enlace sen fíos é posible, e de aí veñen a maioría dos informes de «a VPN vai lenta», porque o túnel é o compoñente visible mentres a radio e o encamiñamento son a causa. Mida a ida e volta da mensaxe real en lugar do ping do propio túnel, e pregunte despois se o número encaixa no orzamento do bucle. Cando non encaixa, mova o paso a bordo en vez de negociar un nivel de servizo máis estrito para un enlace que ninguén na sala controla. Anote o número medido coas condicións en que se tomou, porque o próximo informe chegará sen elas.
Condición dous: que taxa, dirección e interrupción pode declarar?
Escriba os datos, a taxa, a dirección e a interrupción máis longa que tolera a aplicación. Un fluxo de cámara ascendente e un canal de comandos descendente fallan de maneiras distintas, e unha interrupción que tolera unha inspección estacionaria rematará unha tarefa en movemento.
Manteña o acoplamento físico e o túnel por separado ao comparar opcións, xa que unha radio máis potente e unha carga menor son reparacións distintas. Unha transferencia grande que acaba completándose non demostra nada sobre a chegada constante dun resultado sensible ao tempo, e un túnel san non demostra nada sobre a radio que hai detrás.
Logo reduza a demanda en vez de defendela. Submuestree o fluxo de observación, envíe resumos ou deltas e deixe os datos crus dos sensores a bordo, onde o almacenamento é barato e a transmisión non. Unha carga menor debilita o argumento a favor dun enlace máis rápido e a miúdo elimina a necesidade de telo.
Condición tres: quen debe velo e que queda local
A observación adoita ser un requisito moito menor que o procesamento. Se unha persoa debe mirar a cámara e despois debe existir un rexistro, iso é telemetría máis almacenamento; se un modelo debe executarse, pregunte primeiro se pode executarse a bordo con só o seu resultado reenviado. Mover o paso pesado a bordo elimina a dependencia síncrona e deixa unha transferencia que se pode reintentar.
Dous participantes de ROS no mesmo robot non xustifican un túnel por si sós. O alcance dos nodos, a autorización da aplicación e un plan de recuperación local son problemas separados, e unha VPN só responde ao primeiro, e só para o tráfico que se lle pide encamiñar.
Gravar un conxunto de datos é un deseño propio, cos seus propios comandos
Para un exemplo ligado a unha versión, o tutorial de gravación de ROS 2 Jazzy cobre a gravación de temas seleccionados, a inspección do bag resultante e a súa reprodución. Grave os temas de observación aprobados, poña nome á execución e manteña as definicións de mensaxes e a configuración ao lado.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
Non grave todos os temas só porque a ferramenta o pon fácil. O almacenamento énchese, os datos de cámara e localización levan sensibilidade, e un bag de temas sen etiquetar é un problema de análise para quen o abra a próxima vez. A distribución despregada tamén decide os comandos: as ferramentas escritas para bags de ROS 1 non se trasladan aos bags de ROS 2, así que axuste a documentación á versión instalada no robot.
Reproduza nun ambiente illado de análise ou simulación. Reproducir temas de comandos gravados nos actuadores dun robot vivo é un accidente, e a prevención é un dominio ROS separado ou ningún hardware no bucle.
Decida a onde pertence a dependencia e anóteo: unha VPN protexe un intercambio que ten que ocorrer, o procesamento a bordo elimina un intercambio que nunca necesitou ser síncrono, e un conxunto de datos gravado substitúe un consumidor vivo por un posterior. Despois probe a propósito o caso desconectado, co traballo local aínda en marcha, antes de que ninguén dea o deseño por terminado.