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.

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

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.

Artículos relacionados