Subiecte ROS 1 prin VPN: urmați punctul final anunțat

Stația dumneavoastră de lucru ajunge la masterul ROS 1 prin tunel și afișează în continuare o listă goală de subiecte. Acest tipar este obișnuit deoarece înregistrarea la master și transportul subiectelor sunt două conversații diferite, iar doar prima trece prin master. Lista de verificare de mai jos parcurge a doua conversație: punctul final pe care îl anunță un publicator, adresa la care trebuie să ajungă un abonat și permisiunea care lasă perechea să vorbească. Totul aici se referă doar la ROS 1 vechi, a cărui fereastră de suport pentru Noetic s-a încheiat în mai 2025.

Pasul 1: demonstrați că conexiunea la master nu este conexiunea la subiect

Începeți prin a separa ce funcționează de ce nu funcționează. Un rostopic list reușit demonstrează că shell-ul dumneavoastră ajunge la portul XMLRPC al masterului și că masterul cunoaște subiectele; nu spune nimic despre dacă un abonat poate ajunge la publicator. Cele trei comenzi de mai jos fac această distincție vizibilă, și toate sunt doar pentru citire.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Ieșirea comenzii rostopic info numește URI-ul nodului publicatorului, care este o adresă XMLRPC pe gazda publicatorului. Aceasta este adresa pe care abonatul dumneavoastră o va apela în continuare, deci trebuie să fie accesibilă de oriunde rulează abonatul. Dacă indică o interfață care există doar în LAN-ul robotului însuși, căutarea în master reușește și datele nu ajung niciodată.

Pasul 2: citiți punctul final anunțat din nodul însuși

ROS 1 își alege identitatea de gazdă anunțată din ROS_IP sau ROS_HOSTNAME când unul dintre ele este setat, iar altfel revine la rezoluția de nume a gazdei însăși. Inspectați mediul procesului care a fost efectiv lansat, deoarece o unitate systemd, un container sau un al doilea terminal pot purta o valoare diferită de cea a shell-ului în care a funcționat testul dumneavoastră.

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

Un anunț de nume de gazdă funcționează doar dacă fiecare partener rezolvă acel nume la adresa accesibilă dorită. Dacă acel nume este rezolvat doar în rețeaua proprie a robotului, o stație de lucru de cealaltă parte a tunelului nu are cum să îl folosească, iar un VPN care nu împinge niciun sufix DNS agravează nepotrivirea. Setarea ROS_IP la adresa tunelului este schimbarea mai mică atunci când topologia este rutată. Orice ați alege, notați-l pentru ambele capete, deoarece un publicator și un abonat care nu sunt de acord asupra identității vor negocia și apoi nu se vor putea conecta.

Opriți-vă aici dacă URI-ul anunțat folosește o adresă către care niciun partener nu poate ruta. Nicio muncă la firewall nu va repara un nume care se rezolvă la interfața greșită.

Pasul 3: faceți adresa anunțată rezolvabilă și rutată

Cu URI-ul în mână, testați accesibilitatea din gazda abonatului și nu din robot. Portul TCPROS este ales în timpul negocierii, deci testul timpuriu util este portul XMLRPC, iar testul târziu util este socketul stabilit. O rută care există doar într-o singură direcție este o defecțiune obișnuită pe VPN-urile rutate, iar calea de întoarcere contează la fel de mult ca cea de ducere.

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

O interfață TUN rutată transportă aceste conversații IP fără a extinde segmentul Ethernet al robotului, ceea ce de obicei dorește un operator la distanță. Dacă ceva din stivă depinde în schimb de broadcast sau multicast, acea cerință trebuie evaluată separat; transformarea tunelului în TAP pentru a satisface un singur instrument lărgește rețeaua pentru fiecare participant.

Opriți-vă aici dacă lipsește ruta sau calea de întoarcere. Un publicator care răspunde pe propria gazdă, dar nu este accesibil de pe stația de lucru, are o problemă de rutare, nu o problemă ROS.

Pasul 4: permiteți conversația dintre parteneri și urmăriți un subiect

Deschideți doar porturile de care are nevoie conversația negociată și limitați fiecare regulă la participanții declarați. Ascultătorul masterului nu este un releu pentru încărcătura subiectelor, așa că permiterea doar a acestuia lasă punctul final al publicatorului închis. Țineți ascultătorii ROS la granița VPN-ului privat în loc să îi expuneți la internetul public.

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

Urmăriți un subiect inofensiv de la publicatorul real la abonatul real și confirmați atât punctul final anunțat, cât și calea de răspuns. Un singur mesaj demonstrează că calea funcționează; un ritm stabil demonstrează că rămâne deschisă. Țineți controlul actuatoarelor și verificările de siguranță în afara acestui test doar de rețea, deoarece un subiect funcțional nu certifică un robot funcțional. Notați versiunea ROS și perechea de puncte finale observată, pentru ca următoarea persoană să poată distinge o schimbare de topologie de o regresie.

Lista de verificare este încheiată când URI-ul anunțat este accesibil din abonat, portul negociat este deschis doar pentru acel partener, un subiect declarat circulă și valorile de mediu sunt notate pentru ambele gazde. ROS 1 vechi nu va primi corecturi în această zonă, așa că înregistrarea este partea care continuă să funcționeze după ce oamenii se schimbă.