ROS 2 sobre unha VPN: o descubrimento non é a ruta de datos

Dous nodos de ROS 2 en extremos opostos dunha VPN poden listar os temas do outro e, aínda así, non entregar nin unha soa mensaxe. O descubrimento e os datos de usuario son intercambios separados con rutas separadas, e un servidor de descubrimento non retransmite cargas útiles. Comprobar un e supor o outro é como os equipos acaban substituíndo o middleware cando o túnel simplemente nunca transportou os datos. O procedemento seguinte separa os dous resultados antes de cambiar nada.

Que transporta realmente o servidor de descubrimento

En Fast DDS, un Discovery Server distribúe información sobre os extremos: quen publica, quen se subscribe e que QoS espera cada un. Cando os pares se coñecen, os datos de usuario viaxan directamente entre eles en lugar de pasar por ese servidor. Chegar ao servidor demostra que o intermediario das presentacións responde, e nada máis. Unha VPN encamiñada segue necesitando unha ruta funcional en ambos os sentidos entre os enderezos que anuncian os pares.

Esa distinción tamén explica os fallos parciais, nos que os pares existentes seguen intercambiando datos mentres o novo descubrimento deixa de funcionar. Tráteos como dúas investigacións.

Lea o RMW que os nodos usan realmente

ROS 2 pode cargar middleware distinto, e unha variable exportada na súa shell non chega aos procesos iniciados noutro lugar. Pregunte ao sistema en execución en lugar de ao historial do seu terminal.

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

Unha variable sen definir normalmente significa o valor predeterminado instalado, que pode diferir entre máquinas do mesmo experimento. O informe tamén indica a distribución e o middleware en uso, así que compáreos nos dous lados do túnel antes de supor que coinciden. O demo da liña de ordes de ROS almacena o estado na caché, así que reinícieo despois de cambiar a contorna en lugar de deixar que un demo obsoleto responda pola configuración anterior. Anote a distribución e o RMW de ambos os hosts nas notas da proba mentres a sesión estea aberta.

Probe o descubrimento e os datos como dous resultados

Elixa un tema inofensivo e mida a presentación por separado da entrega. A orde info enumera os extremos e o QoS, mentres que echo demostra se unha mensaxe cruza realmente a ligazón.

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

Que os extremos aparezan na saída de info é un resultado de descubrimento. Que unha mensaxe chegue ao subscritor é un resultado de transporte, e só o segundo exercita a ruta que necesita a aplicación. Cando o descubrimento funciona e echo esgota o tempo, revise os enderezos anunciados e a ruta de volta en lugar do servizo de descubrimento. Execute ambas as ordes desde cada host, porque unha ruta VPN asimétrica a miúdo só se revela desde un lado.

Cambie unha dependencia á vez

Cando falla a ruta de datos, evite cambiar o middleware, o modo de descubrimento e o tamaño das mensaxes na mesma sesión, xa que despois ningún resultado pode atribuírse. O RMW de Zenoh é unha alternativa lexítima, pero o seu encamiñador convértese noutra dependencia que debe ser alcanzable a través do túnel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Con ese RMW, o encamiñador transporta o descubrimento na disposición predeterminada de Jazzy, e alí o descubrimento por multicast está desactivado, así que a dependencia pertence ás súas notas e non a unha suposición tomada doutro middleware. Mantega a carga de traballo fixa mentres cambia un axuste, despois repita a proba echo e rexistre a dirección, a taxa de mensaxes e as condicións da ligazón. Repita a comparación dúas veces para separar unha mellora real dunha reconexión afortunada. Se un cambio mellora o descubrimento mentres a entrega segue igual, moveu o servizo de presentación, non a ruta de datos.