Témata ROS 1 přes VPN: sledujte ohlášený koncový bod

Registrace v masteru ROS 1 nepřenáší data témat. Přečtěte si ohlášené URI uzlu, nastavte tuto adresu jako směrovatelnou a poté povolte port vydavatele.

Vaše pracovní stanice dosáhne masteru ROS 1 přes tunel a přesto zobrazuje prázdný seznam témat. Tento vzorec je běžný, protože registrace v masteru a přenos témat jsou dvě různé konverzace a pouze první z nich prochází masterem. Kontrolní seznam níže prochází druhou konverzaci: koncový bod, který vydavatel ohlašuje, adresa, na kterou se musí odběratel dostat, a oprávnění, které dvojici umožní mluvit. Vše zde se týká pouze staršího ROS 1, jehož okno podpory Noetic skončilo v květnu 2025.

Krok 1: dokažte, že spojení s masterem není spojení s tématem

Začněte tím, že oddělíte, co funguje, od toho, co nefunguje. Úspěšný rostopic list dokazuje, že váš shell dosáhne na port XMLRPC masteru a že master o tématech ví; nic neříká o tom, zda se odběratel dostane k vydavateli. Tři příkazy níže tento rozdíl zviditelňují a všechny jsou pouze pro čtení.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Výstup rostopic info uvádí URI uzlu vydavatele, což je adresa XMLRPC na hostiteli vydavatele. Tuto adresu bude váš odběratel volat jako další, takže musí být dostupná odkudkoli, kde odběratel běží. Pokud ukazuje na rozhraní, které existuje jen v LAN samotného robotu, vyhledání v masteru uspěje a data nikdy nedorazí.

Krok 2: přečtěte si ohlášený koncový bod ze samotného uzlu

ROS 1 volí svou ohlášenou identitu hostitele z ROS_IP nebo ROS_HOSTNAME, když je jeden z nich nastaven, a jinak se vrací k vlastnímu překladu jmen hostitele. Prohlédněte si prostředí procesu, který byl skutečně spuštěn, protože jednotka systemd, kontejner nebo druhý terminál může nést jinou hodnotu než shell, ve kterém váš test fungoval.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

Ohlášení jména hostitele funguje jen tehdy, když každý protějšek přeloží toto jméno na zamýšlenou dostupnou adresu. Pokud se toto jméno překládá jen uvnitř vlastní sítě robotu, pracovní stanice na druhé straně tunelu ho nemůže použít, a VPN, která neposílá žádný DNS suffix, nesoulad ještě zhoršuje. Nastavení ROS_IP na adresu tunelu je menší změna, když je topologie směrovaná. Ať zvolíte cokoli, zaznamenejte to pro oba konce, protože vydavatel a odběratel, kteří se neshodnou na identitě, budou vyjednávat a pak se nepřipojí.

Zastavte se zde, pokud ohlášené URI používá adresu, na kterou žádný protějšek nedokáže směrovat. Žádná práce s firewallem neopraví jméno, které se překládá na špatné rozhraní.

Krok 3: udělejte ohlášenou adresu přeložitelnou a směrovanou

S URI v ruce testujte dostupnost z hostitele odběratele, ne z robotu. Port TCPROS se volí během vyjednávání, takže užitečný raný test je port XMLRPC a užitečný pozdější test je navázaný socket. Trasa, která existuje jen jedním směrem, je častá závada na směrovaných VPN a zpáteční cesta je stejně důležitá jako cesta tam.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

Směrované rozhraní TUN přenáší tyto IP konverzace, aniž by rozšiřovalo Ethernetový segment robotu, což je obvykle to, co vzdálený operátor chce. Pokud něco ve stacku závisí místo toho na broadcastu nebo multicastu, musí se tento požadavek posoudit samostatně; převod tunelu na TAP, aby se vyhovělo jednomu nástroji, rozšiřuje síť pro každého účastníka.

Zastavte se zde, pokud chybí trasa nebo zpáteční cesta. Vydavatel, který odpovídá na svém hostiteli, ale není dosažitelný z pracovní stanice, má problém se směrováním, ne problém s ROS.

Krok 4: povolte konverzaci protějšků a sledujte jedno téma

Otevřete jen porty, které vyjednaná konverzace potřebuje, a každé pravidlo omezte na deklarované účastníky. Posluchač masteru není přeposílatelem obsahu témat, takže povolení pouze jeho nechává koncový bod vydavatele zavřený. Držte posluchače ROS na hranici privátní VPN, místo abyste je vystavovali veřejnému internetu.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Sledujte jedno neškodné téma od skutečného vydavatele ke skutečnému odběrateli a potvrďte jak ohlášený koncový bod, tak zpáteční cestu. Jedna zpráva dokazuje, že cesta funguje; stabilní frekvence dokazuje, že zůstává otevřená. Řízení aktuátorů a bezpečnostní kontroly držte mimo tento test týkající se jen sítě, protože fungující téma nepotvrzuje fungujícího robota. Zaznamenejte verzi ROS a dvojici koncových bodů, kterou jste pozorovali, aby další člověk mohl rozeznat změnu topologie od regrese.

Kontrolní seznam je hotový, když je ohlášené URI dostupné z odběratele, vyjednaný port je otevřený jen pro tento protějšek, jedno deklarované téma proudí a hodnoty prostředí jsou zapsané pro oba hostitele. Starší ROS 1 nedostane v této oblasti opravy, takže záznam je ta část, která pokračuje v práci poté, co se lidé vymění.

Související články