ROS 2 per VPN: aptikimas nėra duomenų kelias

Du ROS 2 mazgai priešinguose VPN galuose gali išvardyti vienas kito temas ir vis tiek nepristatyti nė vienos žinutės. Aptikimas ir naudotojo duomenys yra atskiri mainai su atskirais keliais, o aptikimo serveris nepersiunčia naudingosios apkrovos. Patikrinti vieną ir manyti kitą yra būdas, kuriuo komandos pradeda keisti tarpinę programinę įrangą, kai tunelis tiesiog niekada nevežė duomenų. Toliau pateikta procedūra atskiria du rezultatus prieš ką nors keičiant.

Ką aptikimo serveris iš tikrųjų neša

Fast DDS Discovery Server platina informaciją apie galinius taškus: kas skelbia, kas prenumeruoja ir kokio QoS kiekvienas tikisi. Kai partneriai vienas kitą žino, naudotojo duomenys keliauja tiesiogiai tarp jų, o ne per tą serverį. Pasiekti serverį įrodo, kad pažinčių tarpininkas atsako, ir nieko daugiau. Maršrutizuotai VPN vis tiek reikia veikiančio kelio abiem kryptimis tarp adresų, kuriuos skelbia partneriai.

Šis skirtumas taip pat paaiškina dalinius gedimus, kai esami partneriai toliau keičiasi duomenimis, o naujas aptikimas nustoja veikti. Traktuokite juos kaip du atskirus tyrimus.

Skaitykite RMW, kurį mazgai tikrai naudoja

ROS 2 gali įkelti skirtingą tarpinę programinę įrangą, o jūsų apvalkale eksportuotas kintamasis nepasiekia kitur paleistų procesų. Klauskite veikiančios sistemos, o ne terminalo istorijos.

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

Nenustatytas kintamasis paprastai reiškia įdiegtą numatytąją reikšmę, kuri tame pačiame eksperimente gali skirtis tarp mašinų. Ataskaita taip pat nurodo naudojamą distribuciją ir tarpinę programinę įrangą, todėl palyginkite juos abiejose tunelio pusėse prieš manydami, kad jie sutampa. ROS komandų eilutės demonas kaupia būseną talpykloje, todėl paleiskite jį iš naujo pakeitę aplinką, o neleiskite pasenusiam demonui atsakyti už seną konfigūraciją. Įrašykite abiejų hostų distribuciją ir RMW į testo pastabas, kol sesija atvira.

Tikrinkite aptikimą ir duomenis kaip du rezultatus

Pasirinkite nekenksmingą temą ir matuokite pažintį atskirai nuo pristatymo. Komanda info išvardija galinius taškus ir QoS, o echo įrodo, ar viena žinutė tikrai kerta ryšį.

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

Galinių taškų pasirodymas info išvestyje yra aptikimo rezultatas. Žinutės atvykimas prenumeratoriui yra transportavimo rezultatas, ir tik antrasis išbando kelią, kurio reikia programai. Kai aptikimas veikia, o echo baigiasi skirtuoju laiku, tirkite paskelbtus adresus ir grįžtamąjį maršrutą, o ne aptikimo paslaugą. Vykdykite abi komandas iš kiekvieno hosto, nes asimetrinis VPN maršrutas dažnai atsiskleidžia tik iš vienos pusės.

Keiskite vieną priklausomybę vienu metu

Kai duomenų kelias nepavyksta, venkite keisti tarpinę programinę įrangą, aptikimo režimą ir žinutės dydį toje pačioje sesijoje, nes vėliau jokio rezultato nebus galima priskirti. Zenoh RMW yra teisėta alternatyva, bet jo maršrutizatorius tampa dar viena priklausomybe, kuri turi būti pasiekiama per tunelį.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Pagal tą RMW maršrutizatorius neša aptikimą numatytoje Jazzy schemoje, o multicast aptikimas ten išjungtas, todėl priklausomybė priklauso jūsų pastaboms, o ne prielaidai, pasiskolintai iš kitos tarpinės programinės įrangos. Laikykite darbo krūvį fiksuotą keisdami vieną nuostatą, tada pakartokite echo testą ir užrašykite kryptį, žinučių dažnį ir ryšio sąlygas. Pakartokite palyginimą du kartus, kad atskirtumėte tikrą patobulinimą nuo laimingo pakartotinio prisijungimo. Jei pakeitimas pagerina aptikimą, o pristatymas išlieka toks pat, perkėlėte pažinties paslaugą, o ne duomenų kelią.