ROS 2 prek VPN: odkrivanje ni podatkovna pot

Dve vozlišči ROS 2 na nasprotnih koncih VPN lahko naštejeta teme drugega in vseeno ne dostavita niti enega sporočila. Odkrivanje in uporabniški podatki so ločene izmenjave z ločenimi potmi, strežnik za odkrivanje pa ne posreduje koristne obremenitve. Preveriti eno in domnevati drugo je način, kako ekipe začnejo menjati middleware, ko tunel preprosto nikoli ni prenašal podatkov. Spodnji postopek loči dva rezultata, preden se karkoli zamenja.

Kaj strežnik za odkrivanje dejansko prenaša

V Fast DDS Discovery Server razširja informacije o končnih točkah: kdo objavlja, kdo se naroči in kakšen QoS pričakuje vsak. Ko se partnerji poznajo, uporabniški podatki potujejo neposredno med njimi, ne skozi ta strežnik. Doseganje strežnika dokazuje, da posrednik predstavitev odgovarja, in nič več. Usmerjeni VPN še vedno potrebuje delujočo pot v obe smeri med naslovi, ki jih objavljajo partnerji.

Ta razlika pojasnjuje tudi delne okvare, ko obstoječi partnerji še naprej izmenjujejo podatke, medtem ko novo odkrivanje preneha delovati. Obravnavajte jih kot dve ločeni preiskavi.

Preberite RMW, ki ga vozlišči resnično uporabljata

ROS 2 lahko naloži različen middleware, spremenljivka, izvožena v vaši lupini, pa ne doseže procesov, zagnanih drugje. Vprašajte delujoči sistem, ne zgodovine terminala.

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

Nenastavljena spremenljivka običajno pomeni nameščeno privzeto vrednost, ki se med stroji v istem poskusu lahko razlikuje. Poročilo navaja tudi distribucijo in uporabljeni middleware, zato ju primerjajte na obeh straneh tunela, preden domnevate, da se ujemata. Demon ukazne vrstice ROS shranjuje stanje v predpomnilnik, zato ga po spremembi okolja znova zaženite, namesto da bi pustili zastarelemu demonu odgovarjati za staro konfiguracijo. Zapišite distribucijo in RMW obeh gostiteljev v testne opombe, dokler je seja odprta.

Preizkusite odkrivanje in podatke kot dva rezultata

Izberite neškodljivo temo in merite spoznavanje ločeno od dostave. Ukaz info našteje končne točke in QoS, medtem ko echo dokaže, ali eno sporočilo res prečka povezavo.

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

Pojav končnih točk v izhodu info je rezultat odkrivanja. Prihod sporočila do naročnika je rezultat prevoza in samo drugi preizkusi pot, ki jo aplikacija potrebuje. Ko odkrivanje deluje in echo poteče, preglejte objavljene naslove in povratno pot, ne storitve odkrivanja. Zaženite oba ukaza z vsakega gostitelja, ker se asimetrična pot VPN pogosto razkrije le z ene strani.

Spreminjajte eno odvisnost naenkrat

Ko podatkovna pot odpove, se izogibajte spreminjanju middlewarea, načina odkrivanja in velikosti sporočil v isti seji, saj po tem nobenega rezultata ne bo mogoče pripisati. RMW Zenoh je legitimna alternativa, vendar njegov usmerjevalnik postane še ena odvisnost, ki mora biti dosegljiva skozi tunel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Pod tem RMW usmerjevalnik nosi odkrivanje v privzeti razporeditvi Jazzy, večsmerno odkrivanje pa je tam onemogočeno, zato odvisnost spada v vaše opombe in ne v predpostavko, izposojeno od drugega middlewarea. Obremenitev držite nespremenjeno, medtem ko spreminjate eno nastavitev, nato ponovite test echo in zabeležite smer, hitrost sporočil in pogoje povezave. Primerjavo ponovite dvakrat, da ločite resnično izboljšavo od srečne ponovne povezave. Če sprememba izboljša odkrivanje, dostava pa ostane enaka, ste premaknili storitev spoznavanja, ne podatkovne poti.