ROS 1-témák VPN-en át: kövesse a meghirdetett végpontot

A ROS 1 master-regisztráció nem szállít témaadatokat. Olvassa el a meghirdetett csomópont-URI-t, tegye útvonalazhatóvá azt a címet, majd engedélyezze a közzétevő portját.

A munkafizikája az alagúton keresztül eléri a ROS 1 mastert, és mégis üres témalistát mutat. Ez a minta gyakori, mert a master-regisztráció és a témaátvitel két különböző beszélgetés, és csak az első megy át a masteren. Az alábbi ellenőrzőlista a második beszélgetést járja végig: a végpontot, amelyet a közzétevő meghirdet, a címet, amelyet a feliratkozónak el kell érnie, és az engedélyt, amely beszélgetni engedi a párt. Itt minden csak a régi ROS 1-re vonatkozik, amelynek Noetic-támogatási ablaka 2025 májusában ért véget.

1. lépés: bizonyítsa, hogy a master-kapcsolat nem a témakapcsolat

Kezdje annak szétválasztásával, ami működik, attól, ami nem. Egy sikeres rostopic list bizonyítja, hogy a héja eléri a master XMLRPC-portját, és hogy a master ismeri a témákat; semmit nem mond arról, elérheti-e a feliratkozó a közzétevőt. Az alábbi három parancs láthatóvá teszi a különbséget, és mindegyik csak olvasásra szolgál.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

A rostopic info kimenete megnevezi a közzétevő csomópont-URI-jét, amely XMLRPC-cím a közzétevő gépén. Ez az a cím, amelyet a feliratkozója következőként hívni fog, ezért elérhetőnek kell lennie onnan, ahol a feliratkozó fut. Ha olyan interfészre mutat, amely csak a robot saját LAN-ján létezik, a master-keresés sikerül, és az adatok soha nem érkeznek meg.

2. lépés: olvassa el a meghirdetett végpontot magából a csomópontból

A ROS 1 a ROS_IP vagy a ROS_HOSTNAME alapján választja ki a meghirdetett gépidentitását, ha valamelyik be van állítva, egyébként a gép saját névfeloldására esik vissza. Vizsgálja meg a ténylegesen elindított folyamat környezetét, mert egy systemd-egység, egy konténer vagy egy második terminál más értéket hordozhat, mint a héj, amelyben a tesztje működött.

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

A gépnév-meghirdetés csak akkor működik, ha minden partner a szándékolt elérhető címre oldja fel azt a nevet. Ha ez a név csak a robot saját hálózatán belül oldódik fel, az alagút túloldalán lévő munkafizika semmilyen módon nem tudja használni, és a DNS-utótagot nem kényszerítő VPN még rosszabbá teszi az eltérést. Ha a topológia útvonalazott, kisebb változtatás a ROS_IP-ot az alagút címére állítani. Bármit is választ, rögzítse mindkét vég számára, mert az identitásban egyet nem értő közzétevő és feliratkozó tárgyalni fog, majd nem tud kapcsolódni.

Álljon meg itt, ha a meghirdetett URI olyan címet használ, amelyre egyetlen partner sem tud útvonalazni. Semmilyen tűzfalmunka nem javítja meg azt a nevet, amely a rossz interfészre oldódik fel.

3. lépés: tegye a meghirdetett címet feloldhatóvá és útvonalazottá

Az URI-t kézben tartva a feliratkozó gépéről tesztelje az elérhetőséget, nem a robotról. A TCPROS-port a tárgyalás során választódik ki, ezért a hasznos korai teszt az XMLRPC-port, a hasznos késői teszt pedig a létrejött socket. Az egyirányú útvonal gyakori hiba az útvonalazott VPN-eken, és a visszaút ugyanolyan fontos, mint az odaút.

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

Az útvonalazott TUN-interfész a robot Ethernet-szegmensének kiterjesztése nélkül szállítja ezeket az IP-beszélgetéseket, amit a távoli üzemeltető általában szeretne. Ha valami a veremben inkább a broadcastra vagy a multicastra támaszkodik, ezt a követelményt külön kell értékelni; az alagút TAP-pá alakítása egyetlen eszköz kedvéért minden résztvevő számára szélesíti a hálózatot.

Álljon meg itt, ha az útvonal vagy a visszaút hiányzik. A közzétevő, amely a saját gépén válaszol, de a munkafizikáról nem érhető el, útvonalazási problémával küzd, nem ROS-problémával.

4. lépés: engedélyezze a partnerek beszélgetését, és figyeljen meg egy témát

Csak azokat a portokat nyissa meg, amelyekre a tárgyalt beszélgetésnek szüksége van, és minden szabályt a meghirdetett résztvevőkre korlátozzon. A master hallgatója nem továbbító a témák hasznos terheléséhez, ezért csak annak engedélyezése zárva hagyja a közzétevő végpontját. Tartsa a ROS-hallgatókat a privát VPN határán, ahelyett hogy a nyilvános internetre tenné ki őket.

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

Figyeljen meg egy ártalmatlan témát a valódi közzétevőtől a valódi feliratkozóig, és erősítse meg a meghirdetett végpontot és a válaszútvonalat is. Egyetlen üzenet bizonyítja, hogy az útvonal működik; az állandó ütem bizonyítja, hogy nyitva marad. Tartsa a beavatkozók vezérlését és a biztonsági ellenőrzéseket ezen a csak hálózatra vonatkozó teszten kívül, mert egy működő téma nem igazol egy működő robotot. Rögzítse a ROS verzióját és a megfigyelt végpontpárt, hogy a következő ember meg tudja különböztetni a topológiaváltozást a regressziótól.

Az ellenőrzőlista akkor kész, amikor a meghirdetett URI elérhető a feliratkozóról, a tárgyalt port csak annak a partnernek van nyitva, egy meghirdetett téma folyik, és a környezeti értékek mindkét géphez rögzítve vannak. A régi ROS 1 ezen a területen nem kap javításokat, ezért a feljegyzés az a rész, amely az emberek váltása után is működik.

Kapcsolódó cikkek