ROS 2 sobre una VPN: el descubrimiento no es la ruta de datos

Dos nodos de ROS 2 en extremos opuestos de una VPN pueden enumerar los temas del otro y, aun así, no entregar ni un solo mensaje. El descubrimiento y los datos de usuario son intercambios separados con rutas separadas, y un servidor de descubrimiento no retransmite cargas útiles. Comprobar uno y suponer el otro es como los equipos acaban sustituyendo el middleware cuando el túnel simplemente nunca transportó los datos. El procedimiento siguiente separa los dos resultados antes de cambiar nada.

Qué transporta realmente el servidor de descubrimiento

En Fast DDS, un Discovery Server distribuye información sobre los extremos: quién publica, quién se suscribe y qué QoS espera cada uno. Cuando los pares se conocen, los datos de usuario viajan directamente entre ellos en lugar de pasar por ese servidor. Llegar al servidor demuestra que el intermediario de las presentaciones responde, y nada más. Una VPN enrutada sigue necesitando una ruta funcional en ambos sentidos entre las direcciones que anuncian los pares.

Esa distinción también explica los fallos parciales, en los que los pares existentes siguen intercambiando datos mientras el nuevo descubrimiento deja de funcionar. Trátelos como dos investigaciones.

Lea el RMW que los nodos usan realmente

ROS 2 puede cargar middleware distinto, y una variable exportada en su shell no llega a procesos iniciados en otro lugar. Pregunte al sistema en ejecución en lugar de al historial de su terminal.

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

Una variable sin definir normalmente significa el valor predeterminado instalado, que puede diferir entre máquinas del mismo experimento. El informe también indica la distribución y el middleware en uso, así que compárelos en ambos lados del túnel antes de suponer que coinciden. El demonio de línea de comandos de ROS almacena el estado en caché, así que reinícielo después de cambiar el entorno en lugar de dejar que un demonio obsoleto responda por la configuración anterior. Anote la distribución y el RMW de ambos hosts en las notas de la prueba mientras la sesión esté abierta.

Pruebe el descubrimiento y los datos como dos resultados

Elija un tema inofensivo y mida la presentación por separado de la entrega. El comando info enumera los extremos y el QoS, mientras que echo demuestra si un mensaje cruza realmente el enlace.

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

Que los extremos aparezcan en la salida de info es un resultado de descubrimiento. Que un mensaje llegue al suscriptor es un resultado de transporte, y solo el segundo ejercita la ruta que necesita la aplicación. Cuando el descubrimiento funciona y echo agota el tiempo, revise las direcciones anunciadas y la ruta de vuelta en lugar del servicio de descubrimiento. Ejecute ambos comandos desde cada host, porque una ruta VPN asimétrica a menudo solo se revela desde un lado.

Cambie una dependencia a la vez

Cuando falla la ruta de datos, evite cambiar el middleware, el modo de descubrimiento y el tamaño de los mensajes en la misma sesión, ya que después ningún resultado puede atribuirse. El RMW de Zenoh es una alternativa legítima, pero su enrutador se convierte en otra dependencia que debe ser alcanzable a través del túnel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Con ese RMW, el enrutador transporta el descubrimiento en la disposición predeterminada de Jazzy, y allí el descubrimiento por multicast está desactivado, así que la dependencia pertenece a sus notas y no a una suposición tomada de otro middleware. Mantenga la carga de trabajo fija mientras cambia un ajuste, luego repita la prueba echo y registre la dirección, la tasa de mensajes y las condiciones del enlace. Repita la comparación dos veces para separar una mejora real de una reconexión afortunada. Si un cambio mejora el descubrimiento mientras la entrega sigue igual, ha movido el servicio de presentación, no la ruta de datos.