ROS 2 cez VPN: objavovanie nie je dátová cesta

Dva uzly ROS 2 na opačných koncoch VPN si môžu navzájom vypísať témy a napriek tomu nedoručiť ani jednu správu. Objavovanie a používateľské dáta sú samostatné výmeny so samostatnými cestami a server objavovania nepreposiela užitočné dáta. Skontrolovať jedno a predpokladať druhé je spôsob, akým tímy končia pri výmene middlewaru, keď tunel dáta jednoducho nikdy nepremiestňoval. Nasledujúci postup oddeľuje oba výsledky predtým, než sa čokoľvek vymení.

Čo server objavovania skutočne prenáša

Vo Fast DDS Discovery Server distribuuje informácie o koncových bodoch: kto publikuje, kto odoberá a aký QoS ktorý očakáva. Keď sa partneri navzájom poznajú, používateľské dáta putujú priamo medzi nimi, nie cez tento server. Dosiahnutie servera dokazuje, že sprostredkovateľ zoznámení odpovedá, a nič viac. Smerovaná VPN stále potrebuje funkčnú cestu v oboch smeroch medzi adresami, ktoré partneri inzerujú.

Toto rozlíšenie vysvetľuje aj čiastočné zlyhania, keď existujúci partneri pokračujú vo výmene dát, zatiaľ čo nové objavovanie prestane fungovať. Berte ich ako dve samostatné vyšetrovania.

Prečítajte si RMW, ktorý uzly skutočne používajú

ROS 2 môže načítať rôzny middleware a premenná exportovaná vo vašom shelli sa nedostane do procesov spustených inde. Pýtajte sa bežiaceho systému, nie histórie terminálu.

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

Nenastavená premenná zvyčajne znamená nainštalovanú predvolenú hodnotu, ktorá sa medzi strojmi v tom istom experimente môže líšiť. Správa uvádza aj distribúciu a používaný middleware, takže ich porovnajte na oboch stranách tunela, než predpokladáte, že sa zhodujú. Démon príkazového riadka ROS ukladá stav do vyrovnávacej pamäte, preto ho po zmene prostredia reštartujte, namiesto toho aby ste nechali zastaraného démona odpovedať za starú konfiguráciu. Zapíšte distribúciu a RMW oboch hostiteľov do poznámok k testu, kým je relácia otvorená.

Testujte objavovanie a dáta ako dva výsledky

Vyberte neškodnú tému a merajte zoznámenie oddelene od doručenia. Príkaz info vypisuje koncové body a QoS, zatiaľ čo echo dokazuje, či jedna správa skutočne prejde spojením.

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

Výskyt koncových bodov vo výstupe info je výsledok objavovania. Doručenie správy odberateľovi je výsledok prenosu a iba druhý z nich precvičuje cestu, ktorú aplikácia potrebuje. Keď objavovanie funguje a echo vyprší, preskúmajte inzerované adresy a spätnú trasu, nie službu objavovania. Spúšťajte oba príkazy z každého hostiteľa, pretože asymetrická trasa VPN sa často prejaví len z jednej strany.

Meňte jednu závislosť po druhej

Keď dátová cesta zlyhá, vyhnite sa zmene middlewaru, režimu objavovania a veľkosti správ v tej istej relácii, pretože potom sa žiadny výsledok nedá pripísať. RMW Zenoh je legitímna alternatíva, ale jeho smerovač sa stáva ďalšou závislosťou, ktorá musí byť dostupná cez tunel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Pod týmto RMW nesie smerovač objavovanie v predvolenom usporiadaní Jazzy a viacsmerové objavovanie je tam vypnuté, preto závislosť patrí do vašich poznámok, nie do predpokladu vypožičaného od iného middlewaru. Držte záťaž pevnú, kým meníte jedno nastavenie, potom zopakujte test echo a zaznamenajte smer, rýchlosť správ a podmienky spojenia. Porovnanie zopakujte dvakrát, aby ste oddelili skutočné zlepšenie od šťastného opätovného pripojenia. Ak zmena zlepší objavovanie, zatiaľ čo doručovanie zostane rovnaké, presunuli ste službu zoznámenia, nie dátovú cestu.