ROS 2 përmes një VPN: zbulimi nuk është rruga e të dhënave

Dy nyje ROS 2 në skajet e kundërta të një VPN mund të listojnë temat e njëri-tjetrit dhe megjithatë të mos dorëzojnë asnjë mesazh. Zbulimi dhe të dhënat e përdoruesit janë shkëmbime të veçanta me rrugë të veçanta, dhe një server zbulimi nuk i përcjell ngarkesat. Të kontrollosh njërën dhe të supozosh tjetrën është mënyra se si ekipet përfundojnë duke zëvendësuar middleware kur tuneli thjesht nuk i ka transportuar kurrë të dhënat. Procedura më poshtë i ndan dy rezultatet përpara se të ndërrohet diçka.

Çfarë mbart vërtet serveri i zbulimit

Në Fast DDS, një Discovery Server shpërndan informacion për pikat fundore: kush publikon, kush abonohet dhe çfarë QoS pret secili. Pasi partnerët njihen, të dhënat e përdoruesit udhëtojnë drejtpërdrejt mes tyre në vend që të kalojnë përmes atij serveri. Arritja e serverit provon që ndërmjetësi i prezantimeve përgjigjet, dhe asgjë më shumë. Një VPN e rrugëzuar ende ka nevojë për një rrugë funksionale në të dy drejtimet mes adresave që shpallin partnerët.

Ky dallim shpjegon gjithashtu dështimet e pjesshme, ku partnerët ekzistues vazhdojnë të shkëmbejnë të dhëna ndërsa zbulimi i ri ndalon së funksionuari. Trajtojini si dy hetime.

Lexoni RMW-në që nyjet përdorin vërtet

ROS 2 mund të ngarkojë middleware të ndryshëm, dhe një variabël e eksportuar në shell-in tuaj nuk arrin te proceset e nisura diku tjetër. Pyetni sistemin që po ekzekutohet, jo historikun e terminalit.

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

Një variabël e pavendosur zakonisht nënkupton parazgjedhjen e instaluar, e cila mund të ndryshojë mes makinave në të njëjtin eksperiment. Raporti përmend gjithashtu shpërndarjen dhe middleware-in që përdoret, prandaj krahasoni ato në të dyja anët e tunelit përpara se të supozoni se përputhen. Daemoni i linjës së komandës ROS e ruan gjendjen në cache, prandaj rinisni atë pas ndryshimit të mjedisit në vend që të lini një daemon të vjetëruar të përgjigjet për konfigurimin e vjetër. Shkruani shpërndarjen dhe RMW-në e të dy hosteve në shënimet e testit sa kohë që sesioni është i hapur.

Provoni zbulimin dhe të dhënat si dy rezultate

Zgjidhni një temë të padëmshme dhe matni prezantimin veçmas nga dorëzimi. Komanda info liston pikat fundore dhe QoS, ndërsa echo provon nëse një mesazh kalon vërtet lidhjen.

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

Shfaqja e pikave fundore në daljen e info është rezultat i zbulimit. Mbërritja e një mesazhi te abonuesi është rezultat i transportit, dhe vetëm i dyti teston rrugën që i nevojitet aplikacionit. Kur zbulimi funksionon dhe echo skadon, inspektoni adresat e shpallura dhe rrugën e kthimit në vend të shërbimit të zbulimit. Ekzekutoni të dy komandat nga çdo host, sepse një rrugë VPN asimetrike shpesh zbulohet vetëm nga një anë.

Ndryshoni një varësi në një kohë

Kur rruga e të dhënave dështon, shmangni ndryshimin e middleware-it, mënyrës së zbulimit dhe madhësisë së mesazhit në të njëjtin sesion, pasi më pas asnjë rezultat nuk mund t'i atribuohet. RMW Zenoh është një alternativë legjitime, por rutori i tij bëhet një varësi tjetër që duhet të jetë e arritshme përmes tunelit.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Nën atë RMW, rutori mbart zbulimin në rregullimin parazgjedhur të Jazzy, dhe zbulimi multicast është i çaktivizuar atje, kështu që varësia i përket shënimeve tuaja dhe jo një supozimi të huazuar nga një middleware tjetër. Mbani ngarkesën e punës fikse ndërsa ndryshoni një cilësim, pastaj përsëritni testin echo dhe regjistroni drejtimin, shkallën e mesazheve dhe kushtet e lidhjes. Ekzekutoni krahasimin dy herë për të ndarë një përmirësim real nga një rilidhje me fat. Nëse një ndryshim përmirëson zbulimin ndërsa dorëzimi mbetet i njëjtë, keni zhvendosur shërbimin e prezantimit, jo rrugën e të dhënave.