ROS 2 sobre una VPN: el descobriment no és el camí de dades

Dos nodes de ROS 2 als extrems oposats d'una VPN poden llistar els temes de l'altre i, tot i així, no lliurar ni un sol missatge. El descobriment i les dades d'usuari són intercanvis separats amb camins separats, i un servidor de descobriment no retransmet càrregues. Comprovar-ne un i suposar l'altre és com els equips acaben substituint el middleware quan el túnel simplement mai no va transportar les dades. El procediment següent separa els dos resultats abans que es canviï res.

Què transporta realment el servidor de descobriment

A Fast DDS, un Discovery Server distribueix informació sobre els punts finals: qui publica, qui se subscriu i quin QoS espera cadascun. Quan els parells es coneixen, les dades d'usuari viatgen directament entre ells en lloc de passar per aquell servidor. Arribar al servidor demostra que el broker de presentacions respon, i res més. Una VPN encaminada encara necessita un camí funcional en totes dues direccions entre les adreces que anuncien els parells.

Aquesta distinció també explica les fallades parcials, en què els parells existents continuen intercanviant dades mentre el descobriment nou deixa de funcionar. Tracteu-les com dues investigacions.

Llegiu l'RMW que els nodes fan servir realment

ROS 2 pot carregar middleware diferent, i una variable exportada a la vostra shell no arriba als processos iniciats en un altre lloc. Pregunteu al sistema en execució en lloc de a l'historial del terminal.

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

Una variable no definida normalment significa el valor per defecte instal·lat, que pot diferir entre màquines del mateix experiment. L'informe també indica la distribució i el middleware en ús, així que compareu-los als dos costats del túnel abans de suposar que coincideixen. El dimoni de línia d'ordres de ROS emmagatzema l'estat en memòria cau, així que reinicieu-lo després de canviar l'entorn en lloc de deixar que un dimoni obsolet respongui per la configuració antiga. Anoteu la distribució i l'RMW dels dos amfitrions a les notes de la prova mentre la sessió estigui oberta.

Proveu el descobriment i les dades com dos resultats

Trieu un tema inofensiu i mesureu la presentació per separat del lliurament. L'ordre info llista els punts finals i el QoS, mentre que echo demostra si un missatge travessa realment l'enllaç.

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

Que els punts finals apareguin a la sortida d'info és un resultat de descobriment. Que un missatge arribi al subscriptor és un resultat de transport, i només el segon exercita el camí que necessita l'aplicació. Quan el descobriment funciona i echo esgota el temps, reviseu les adreces anunciades i la ruta de tornada en lloc del servei de descobriment. Executeu les dues ordres des de cada amfitrió, perquè una ruta VPN asimètrica sovint es revela només des d'un costat.

Canvieu una dependència alhora

Quan falla el camí de dades, eviteu canviar el middleware, el mode de descobriment i la mida dels missatges a la mateixa sessió, ja que després cap resultat no es pot atribuir. L'RMW de Zenoh és una alternativa legítima, però el seu encaminador es converteix en una altra dependència que ha de ser abastable a través del túnel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Amb aquest RMW, l'encaminador transporta el descobriment en la disposició predeterminada de Jazzy, i allà el descobriment per multicast està desactivat, així que la dependència pertany a les vostres notes i no a una suposició manllevada d'un altre middleware. Manteniu la càrrega de treball fixa mentre canvieu un paràmetre, després repetiu la prova echo i anoteu la direcció, la taxa de missatges i les condicions de l'enllaç. Repetiu la comparació dues vegades per separar una millora real d'una reconnexió afortunada. Si un canvi millora el descobriment mentre el lliurament continua igual, heu mogut el servei de presentació, no el camí de dades.