Procesamiento en vivo o datos grabados: ¿qué necesita realmente una VPN?
Decida qué trabajo del robot debe cruzar la red: resultados oportunos, telemetría de observación o un conjunto de datos grabado. Tres condiciones y luego los comandos bag.
Un robot que deja de ser útil a una habitación de distancia tiene un problema de enlace o de carga de trabajo mucho antes de tener un problema de VPN. El cifrado protege una ruta; no amplía la cobertura de radio ni hace que un cálculo remoto termine antes. La decisión que tiene delante es qué trabajo debe cruzar realmente la red, y esa respuesta suele eliminar más tráfico de lo que la gente espera. Tres condiciones lo resuelven, y el rendimiento no es una de ellas.
Tres disposiciones, una sola pregunta sobre la dependencia
La tabla separa las disposiciones por lo que depende del enlace, no por qué software aparece en el 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 |
Ninguna fila de esa tabla es un argumento de seguridad. Las funciones de control y seguridad siguen necesitando una respuesta cualificada para el retardo, la pérdida de paquetes y una conexión caída, y ningún indicador de túnel la proporciona. La tabla dice dónde vive la dependencia, que es la parte que un diseño de red sí puede cambiar.
Condición uno: ¿tiene que ser oportuna la respuesta?
Si un resultado remoto alimenta un controlador, la red está dentro del bucle de control, y su retardo, su jitter y sus cortes se convierten en propiedades del control. Si el mismo resultado solo alimenta una pantalla, un panel o a una persona que mira, el mismo retardo es cosmético.
El trabajo en bucle cerrado por un enlace inalámbrico es posible, y de ahí provienen la mayoría de los informes de «la VPN va lenta», porque el túnel es el componente visible mientras la radio y el enrutamiento son la causa. Mida el viaje de ida y vuelta del mensaje real en lugar del ping del propio túnel, y pregunte después si el número encaja en el presupuesto del bucle. Cuando no encaja, mueva el paso a bordo en vez de negociar un nivel de servicio más estricto para un enlace que nadie en la sala controla. Anote el número medido con las condiciones en que se tomó, porque el próximo informe llegará sin ellas.
Condición dos: ¿qué tasa, dirección e interrupción puede declarar?
Escriba los datos, la tasa, la dirección y la interrupción más larga que tolera la aplicación. Un flujo de cámara ascendente y un canal de comandos descendente fallan de maneras distintas, y una interrupción que tolera una inspección estacionaria terminará una tarea en movimiento.
Mantenga el acople físico y el túnel por separado al comparar opciones, ya que una radio más potente y una carga menor son reparaciones distintas. Una transferencia grande que acaba completándose no demuestra nada sobre la llegada constante de un resultado sensible al tiempo, y un túnel sano no demuestra nada sobre la radio que hay detrás.
Luego reduzca la demanda en vez de defenderla. Submuestree el flujo de observación, envíe resúmenes o deltas y deje los datos crudos de los sensores a bordo, donde el almacenamiento es barato y la transmisión no. Una carga menor debilita el argumento a favor de un enlace más rápido y a menudo elimina la necesidad de tenerlo.
Condición tres: quién debe verlo y qué se queda local
La observación suele ser un requisito mucho menor que el procesamiento. Si una persona debe mirar la cámara y después debe existir un registro, eso es telemetría más almacenamiento; si un modelo debe ejecutarse, pregunte primero si puede ejecutarse a bordo con solo su resultado reenviado. Mover el paso pesado a bordo elimina la dependencia síncrona y deja una transferencia que se puede reintentar.
Dos participantes de ROS en el mismo robot no justifican un túnel por sí solos. El alcance de los nodos, la autorización de la aplicación y un plan de recuperación local son problemas separados, y una VPN solo responde al primero, y solo para el tráfico que se le pide enrutar.
Grabar un conjunto de datos es un diseño propio, con sus propios comandos
Para un ejemplo ligado a una versión, el tutorial de grabación de ROS 2 Jazzy cubre la grabación de temas seleccionados, la inspección del bag resultante y su reproducción. Grabe los temas de observación aprobados, ponga nombre a la ejecución y mantenga las definiciones de mensajes y la configuración junto a ella.
ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42
No grabe todos los temas solo porque la herramienta lo pone fácil. El almacenamiento se llena, los datos de cámara y ubicación conllevan sensibilidad, y un bag de temas sin etiquetar es un problema de análisis para quien lo abra la próxima vez. La distribución desplegada también decide los comandos: las herramientas escritas para bags de ROS 1 no se trasladan a los bags de ROS 2, así que ajuste la documentación a la versión instalada en el robot.
Reproduzca en un entorno aislado de análisis o simulación. Reproducir temas de comandos grabados en los actuadores de un robot vivo es un accidente, y la prevención es un dominio ROS separado o ningún hardware en el bucle.
Decida a dónde pertenece la dependencia y anótelo: una VPN protege un intercambio que tiene que ocurrir, el procesamiento a bordo elimina un intercambio que nunca necesitó ser síncrono, y un conjunto de datos grabado sustituye a un consumidor vivo por uno posterior. Después pruebe a propósito el caso desconectado, con el trabajo local aún en marcha, antes de que nadie dé el diseño por terminado.