ROS 1 -aiheet VPN:n yli: seuraa ilmoitettua päätepistettä
ROS 1 -master-rekisteröinti ei kuljeta aihetietoja. Lue ilmoitettu solmun URI, tee siitä osoitteesta reititettävä ja salli sitten julkaisijan portti.
Työasemasi tavoittaa ROS 1 -masterin tunnelin kautta ja näyttää silti tyhjän aiheluettelon. Tämä kuvio on yleinen, koska master-rekisteröinti ja aiheiden siirto ovat kaksi eri keskustelua, ja vain ensimmäinen kulkee masterin kautta. Alla oleva tarkistuslista käy läpi toisen keskustelun: päätepisteen, jonka julkaisija ilmoittaa, osoitteen, johon tilaajan on päästävä, ja luvan, joka päästää parin puhumaan. Kaikki tässä koskee vain vanhaa ROS 1:tä, jonka Noetic-tukiaika päättyi toukokuussa 2025.
Vaihe 1: todista, ettei master-yhteys ole aiheyhteys
Aloita erottamalla toimiva siitä, mikä ei toimi. Onnistunut rostopic list todistaa, että kuorisi tavoittaa masterin XMLRPC-portin ja että master tuntee aiheet; se ei kerro mitään siitä, pääseekö tilaaja julkaisijaan. Kolme alla olevaa komentoa tekevät eron näkyväksi, ja kaikki ovat vain lukemista varten.
echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter
rostopic info-komennon tuloste nimeää julkaisijan solmun URI:n, joka on XMLRPC-osoite julkaisijan isännässä. Tätä osoitetta tilaajasi kutsuu seuraavaksi, joten sen on oltava tavoitettavissa kaikkialta, missä tilaaja toimii. Jos se osoittaa liitäntään, joka on olemassa vain robotin omassa LAN-verkossa, master-haku onnistuu eivätkä tiedot koskaan saavu.
Vaihe 2: lue ilmoitettu päätepiste solmusta itsestään
ROS 1 valitsee ilmoitetun isäntänsä identiteetin ROS_IP- tai ROS_HOSTNAME-muuttujasta, kun jompikumpi on asetettu, ja palaa muuten isännän omaan nimiratkaisuun. Tutki prosessin ympäristö, joka tosiasiassa käynnistettiin, sillä systemd-yksikkö, kontti tai toinen pääte voi kantaa eri arvoa kuin se kuori, jossa testisi toimi.
echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host
Isäntänimen ilmoitus toimii vain, jos jokainen vertaisasema ratkaisee tämän nimen aiottuun tavoitettavissa olevaan osoitteeseen. Jos nimi ratkeaa vain robotin omassa verkossa, tunnelin toisella puolella olevalla työasemalla ei ole mitään tapaa käyttää sitä, ja VPN, joka ei työnnä yhtään DNS-liitettä, pahentaa epäsuhtaa. ROS_IP-muuttujan asettaminen tunnelin osoitteeseen on pienempi muutos, kun topologia on reititetty. Minkä tahansa valitsetkin, kirjaa se molemmille päille, sillä julkaisija ja tilaaja, jotka ovat eri mieltä identiteetistä, neuvottelevat ja epäonnistuvat sitten yhdistämään.
Pysähdy tähän, jos ilmoitettu URI käyttää osoitetta, johon mikään vertaisasema ei voi reitittää. Mikään palomuurityö ei korjaa nimeä, joka ratkeaa väärään liitäntään.
Vaihe 3: tee ilmoitetusta osoitteesta ratkeava ja reititetty
Kun URI on käsissäsi, testaa tavoitettavuutta tilaajan isännästä eikä robotista. TCPROS-portti valitaan neuvottelun aikana, joten hyödyllinen varhainen testi on XMLRPC-portti ja hyödyllinen myöhäinen testi on muodostettu socket. Reitti, joka on olemassa vain yhteen suuntaan, on yleinen vika reititetyissä VPN:issä, ja paluupolku merkitsee yhtä paljon kuin menopolku.
ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2
Reititetty TUN-liitäntä kuljettaa nämä IP-keskustelut laajentamatta robotin Ethernet-segmenttiä, mitä etäoperaattori yleensä haluaa. Jos jokin pinossa riippuu sen sijaan lähetyksestä tai multicastista, tätä vaatimusta on arvioitava erikseen; tunnelin muuttaminen TAP:iksi yhden työkalun tyydyttämiseksi laajentaa verkkoa jokaiselle osallistujalle.
Pysähdy tähän, jos reitti tai paluupolku puuttuu. Julkaisijalla, joka vastaa omassa isännässään mutta jota ei tavoiteta työasemasta, on reititysongelma, ei ROS-ongelma.
Vaihe 4: salli vertaisten keskustelu ja seuraa yhtä aihetta
Avaa vain ne portit, jotka neuvoteltu keskustelu tarvitsee, ja rajaa jokainen sääntö ilmoitettuihin osallistujiin. Masterin kuuntelija ei ole aiheiden hyötykuorman välittäjä, joten vain sen salliminen jättää julkaisijan päätepisteen suljetuksi. Pidä ROS-kuuntelijat yksityisen VPN:n rajalla sen sijaan, että altistaisit ne julkiselle internetille.
rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker
Seuraa yhtä vaaratonta aihetta todelliselta julkaisijalta todelliselle tilaajalle ja vahvista sekä ilmoitettu päätepiste että vastauspolku. Yksi viesti todistaa, että polku toimii; vakaa tahti todistaa, että se pysyy auki. Pidä toimilaitteiden ohjaus ja turvatarkistukset tämän vain verkkoa koskevan testin ulkopuolella, sillä toimiva aihe ei todista toimivaa robottia. Kirjaa ROS-versio ja havaitsemasi päätepisteiden pari, jotta seuraava henkilö voi erottaa topologian muutoksen regressiosta.
Tarkistuslista on valmis, kun ilmoitettu URI on tilaajan tavoitettavissa, neuvoteltu portti on auki vain sille vertaisasemalle, yksi ilmoitettu aihe virtaa ja ympäristön arvot on kirjattu molemmille isännille. Vanha ROS 1 ei saa korjauksia tällä alueella, joten kirjaus on se osa, joka jatkaa toimintaansa sen jälkeen, kun ihmiset vaihtuvat.