ROS 2 přes VPN: objevování není datová cesta

Dva uzly ROS 2 na opačných koncích VPN si mohou navzájem vypsat témata a přesto nedoručit jedinou zprávu. Objevování a uživatelská data jsou samostatné výměny se samostatnými cestami a server pro objevování nepředává užitečná data. Zkontrolovat jedno a předpokládat druhé je způsob, jakým týmy končí u výměny middlewaru, když tunel data prostě nikdy nepřenášel. Následující postup odděluje oba výsledky dříve, než se cokoli vymění.

Co server pro objevování skutečně nese

Ve Fast DDS Discovery Server distribuuje informace o koncových bodech: kdo publikuje, kdo odebírá a jaké QoS kdo očekává. Jakmile se partneři navzájem znají, uživatelská data putují přímo mezi nimi, nikoli přes tento server. Dosažení serveru dokazuje, že zprostředkovatel seznamování odpovídá, a nic víc. Směrovaná VPN stále potřebuje funkční cestu v obou směrech mezi adresami, které partneři inzerují.

Toto rozlišení také vysvětluje částečná selhání, kdy stávající partneři dál vyměňují data, zatímco nové objevování přestane fungovat. Berte je jako dvě samostatná vyšetřování.

Přečtěte si RMW, který uzly skutečně používají

ROS 2 může načítat různý middleware a proměnná exportovaná ve vašem shellu se nedostane do procesů spuštěných jinde. Ptejte se běžícího systému, ne historie terminálu.

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

Nenastavená proměnná obvykle znamená nainstalovanou výchozí hodnotu, která se mezi stroji ve stejném experimentu může lišit. Zpráva také uvádí distribuci a používaný middleware, takže je porovnejte na obou stranách tunelu, než předpokládáte, že se shodují. Démon příkazového řádku ROS ukládá stav do mezipaměti, takže ho po změně prostředí restartujte, místo abyste nechali zastaralého démona odpovídat za starou konfiguraci. Zapište distribuci a RMW obou hostitelů do poznámek k testu, dokud je relace otevřená.

Testujte objevování a data jako dva výsledky

Vyberte neškodné téma a měřte seznamování odděleně od doručení. Příkaz info vypisuje koncové body a QoS, zatímco echo dokazuje, zda jedna zpráva skutečně projde spojením.

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

Výskyt koncových bodů ve výstupu info je výsledek objevování. Doručení zprávy odběrateli je výsledek přenosu a pouze druhý z nich procvičuje cestu, kterou aplikace potřebuje. Když objevování funguje a echo vyprší, prozkoumejte inzerované adresy a zpětnou trasu, nikoli službu objevování. Spouštějte oba příkazy z každého hostitele, protože asymetrická trasa VPN se často projeví jen z jedné strany.

Měňte jednu závislost po druhé

Když datová cesta selže, vyhněte se změně middlewaru, režimu objevování a velikosti zpráv v jedné relaci, protože potom žádný výsledek nelze připsat. RMW Zenoh je legitimní alternativa, ale jeho router se stává další závislostí, která musí být dostupná tunelem.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Pod tímto RMW nese router objevování ve výchozím uspořádání Jazzy a vícesměrové objevování je tam vypnuté, takže závislost patří do vašich poznámek, nikoli do předpokladu vypůjčeného od jiného middlewaru. Držte zátěž pevnou, zatímco měníte jedno nastavení, potom zopakujte test echo a zaznamenejte směr, rychlost zpráv a podmínky spojení. Porovnání opakujte dvakrát, abyste oddělili skutečné zlepšení od šťastného opětovného připojení. Pokud změna zlepší objevování, zatímco doručování zůstane stejné, přesunuli jste službu seznamování, ne datovou cestu.