ROS 1 temos per VPN: sekite paskelbtą galinį tašką

Jūsų darbo stotis pasiekia ROS 1 master per tunelį ir vis tiek rodo tuščią temų sąrašą. Šis modelis įprastas, nes master registracija ir temų perdavimas yra du skirtingi pokalbiai, ir tik pirmasis eina per master. Toliau pateiktas kontrolinis sąrašas eina per antrąjį pokalbį: galinis taškas, kurį skelbia leidėjas, adresas, kurį prenumeratorius turi pasiekti, ir leidimas, kuris leidžia porai kalbėtis. Viskas čia taikoma tik senajai ROS 1 versijai, kurios Noetic palaikymo laikotarpis baigėsi 2025 metų gegužę.

1 žingsnis: įrodykite, kad master ryšys nėra temų ryšys

Pradėkite atskirdami tai, kas veikia, nuo to, kas neveikia. Sėkmingas rostopic list įrodo, kad jūsų apvalkalas pasiekia master XMLRPC prievadą ir kad master žino temas; jis nieko nesako apie tai, ar prenumeratorius gali pasiekti leidėją. Trys toliau pateiktos komandos padaro šį skirtumą matomą, ir visos yra tik skaitymo.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

rostopic info išvestis nurodo leidėjo mazgo URI, kuris yra XMLRPC adresas leidėjo pagrindiniame kompiuteryje. Šį adresą jūsų prenumeratorius kvies toliau, todėl jis turi būti pasiekiamas iš bet kur, kur veikia prenumeratorius. Jei jis rodo į sąsają, kuri egzistuoja tik paties roboto LAN tinkle, master paieška pavyksta, o duomenys niekada neatkeliauja.

2 žingsnis: perskaitykite paskelbtą galinį tašką iš paties mazgo

ROS 1 pasirenka savo skelbiamą pagrindinio kompiuterio tapatybę iš ROS_IP arba ROS_HOSTNAME, kai vienas iš jų nustatytas, o kitu atveju grįžta prie paties kompiuterio vardų skyrimo. Išnagrinėkite aplinką proceso, kuris iš tikrųjų buvo paleistas, nes systemd įrenginys, konteineris ar antras terminalas gali turėti kitokią reikšmę nei apvalkalas, kuriame jūsų testas veikė.

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

Pagrindinio kompiuterio vardo skelbimas veikia tik jei kiekvienas partneris išsprendžia tą vardą į numatytą pasiekiamą adresą. Jei tas vardas sprendžiamas tik pačio roboto tinkle, darbo stotis kitoje tunelio pusėje neturi jokio būdo juo naudotis, o VPN, kuris nestumia jokios DNS priesagos, dar labiau pablogina neatitikimą. Kai topologija maršrutizuota, ROS_IP nustatymas į tunelio adresą yra mažesnis pakeitimas. Kad ir ką pasirinktumėte, užrašykite tai abiem galams, nes leidėjas ir prenumeratorius, kurie nesutaria dėl tapatybės, derėsis ir po to negalės prisijungti.

Sustokite čia, jei paskelbtas URI naudoja adresą, į kurį nė vienas partneris negali maršrutizuoti. Joks ugniasienės darbas nepataisys vardo, kuris sprendžiamas į neteisingą sąsają.

3 žingsnis: padarykite paskelbtą adresą išsprendžiamą ir maršrutizuotą

Turėdami URI, patikrinkite pasiekiamumą iš prenumeratoriaus kompiuterio, o ne iš roboto. TCPROS prievadas pasirenkamas derybų metu, todėl naudingas ankstyvas testas yra XMLRPC prievadas, o naudingas vėlyvas testas yra užmegztas lizdas. Maršrutas, kuris egzistuoja tik viena kryptimi, yra dažnas gedimas maršrutizuotuose VPN, o grįžimo kelias svarbus tiek pat, kiek kelias pirmyn.

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

Maršrutizuota TUN sąsaja perduoda šiuos IP pokalbius neišplėsdama roboto Ethernet segmento, ko paprastai nori nuotolinis operatorius. Jei kas nors kamiene priklauso nuo transliacijos ar multicast, tas reikalavimas turi būti vertinamas atskirai; tunelio pavertimas TAP, siekiant patenkinti vieną įrankį, išplečia tinklą kiekvienam dalyviui.

Sustokite čia, jei trūksta maršruto ar grįžimo kelio. Leidėjas, kuris atsako savo kompiuteryje, bet jo nepasiekia darbo stotis, turi maršrutizavimo problemą, o ne ROS problemą.

4 žingsnis: leiskite partnerių pokalbį ir stebėkite vieną temą

Atidarykite tik tuos prievadus, kurių reikia suderėtam pokalbiui, ir apribokite kiekvieną taisyklę paskelbtais dalyviais. Master klausytojas nėra temų naudingosios apkrovos retransliatorius, todėl leidus tik jį, leidėjo galinis taškas lieka uždarytas. Laikykite ROS klausytojus privačios VPN riboje, o ne atskleiskite juos viešajam internetui.

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

Stebėkite vieną nekenksmingą temą nuo tikro leidėjo iki tikro prenumeratoriaus ir patvirtinkite ir paskelbtą galinį tašką, ir atsakymo kelią. Viena žinutė įrodo, kad kelias veikia; pastovus dažnis įrodo, kad jis lieka atviras. Laikykite pavarų valdymą ir saugos patikras už šio tik tinklo testo ribų, nes veikianti tema nesertifikuoja veikiančio roboto. Užrašykite ROS versiją ir pastebėtą galinių taškų porą, kad kitas žmogus galėtų atskirti topologijos pokytį nuo regresijos.

Kontrolinis sąrašas baigtas, kai paskelbtas URI pasiekiamas iš prenumeratoriaus, suderėtas prievadas atidarytas tik tam partneriui, viena paskelbta tema teka ir aplinkos reikšmės užrašytos abiem kompiuteriams. Senoji ROS 1 šioje srityje nebegaus taisymų, todėl įrašas yra ta dalis, kuri veikia ir po to, kai žmonės pasikeičia.