Jo wurkstasjon berikt de ROS 1-master oer de tunnel en toant noch altyd in lege list mei ûnderwerpen. Dat patroan is gewoan, om’t masterregistraasje en ûnderwerptransport twa ferskillende petearen binne, en allinnich it earste troch de master giet. De checklist hjirûnder rint it twadde petear troch: it einpunt dat in publisearrer oankundiget, it adres dat in abonnent berikke moat, en de tastimming dy’t it pear prate lit. Alles hjir jildt allinnich foar de âlde ROS 1, waans Noetic-stipefinster yn maaie 2025 einige.

Stap 1: bewize dat de masterferbining net de ûnderwerpferbining is

Begjin mei te skieden wat wurket fan wat net wurket. In slagge rostopic list bewist dat jo shell de XMLRPC-poarte fan de master berikke kin en dat de master ûnderwerpen ken; it seit neat oer de fraach oft in abonnent de publisearrer berikke kin. De trije opdrachten hjirûnder meitsje it ferskil sichtber, en se binne allegear allinnich-lêze.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

De útfier fan rostopic info neamt de node-URI fan de publisearrer, dat is in XMLRPC-adres op de host fan de publisearrer. Dat adres is itjinge jo abonnent dêrnei oproppe sil, dus it moat berikber wêze fan wêr’t de abonnent ek rint. As it wiist nei in ynterface dy’t allinnich op it eigen LAN fan de robot bestiet, slagget de mastersyktocht en komme de gegevens nea oan.

Stap 2: lês it oankundige einpunt fan de node sels

ROS 1 kiest syn oankundige hostidentiteit út ROS_IP of ROS_HOSTNAME as ien fan beiden ynsteld is, en falt oars werom op de namme-oplossing fan de host sels. Undersykje it omjouwing fan it proses dat eins start is, om’t in systemd-ienheid, in container of in twadde terminal in oare wearde drage kin as de shell dêr’t jo test yn wurke.

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

In hostnamme-oankundiging wurket allinnich as elk peer dy namme oplost nei it bedoelde berikbere adres. As dy namme allinnich binnen it eigen netwurk fan de robot oplost, hat in wurkstasjon oan de oare kant fan de tunnel gjin manier om it te brûken, en in VPN dy’t gjin DNS-efterheaksel skoot makket de misferhâlding slimmer. ROS_IP op it tunneladres sette is de lytsere feroaring as de topology rûtber is. Hokker jo ek kieze, skriuw it foar beide einen op, om’t in publisearrer en in abonnent dy’t it oer identiteit net iens binne ûnderhannelje sille en dan net ferbine kinne.

Stop hjir as de oankundige URI in adres brûkt dêr’t gjin peer nei rûtberje kin. Gjin hoemannichte firewallwurk sil in namme reparearje dy’t nei it ferkearde ynterface oplost.

Stap 3: meitsje it oankundige adres oplosber en rûtber

Mei de URI yn ’e hân, test berikberens fan de host fan de abonnent ynstee fan fan de robot. De TCPROS-poarte wurdt by de ûnderhanneling keazen, dus de nuttige iere test is de XMLRPC-poarte en de nuttige lettere test is de festige socket. In rûte dy’t allinnich yn ien rjochting bestiet is in gewoane fout op rûtbere VPN’s, en it werompaad jildt likefolle as it foarpaad.

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

In rûtber TUN-ynterface ferfiert dizze IP-petearen sûnder it Ethernet-segment fan de robot út te wreidzjen, wat in ôfstânsoperator meastal wol. As eat yn ’e stapel ynstee dêrfan ôfhinklik is fan broadcast of multicast, moat dy eask apart beoardiele wurde; de tunnel nei TAP omsette om ien ark te befredigjen wreidet it netwurk foar elke dielnimmer út.

Stop hjir as de rûte of it werompaad ûntbrekt. In publisearrer dy’t op syn eigen host antwurdet mar net fan it wurkstasjon berikt wurde kin, hat in rûtprobleem, net in ROS-probleem.

Stap 4: tastean it peer-petear en besjoch ien ûnderwerp

Iepenje allinnich de poarten dy’t it ûnderhannele petear nedich hat, en behein elke regel ta de oankundige dielnimmers. De harker fan de master is gjin trochjouwer foar ûnderwerpfracht, dus allinnich dy tastean lit it einpunt fan de publisearrer sletten. Hâld de ROS-harkers op de grins fan it privee VPN ynstee fan se oan it iepenbiere ynternet bleat te stellen.

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

Besjoch ien harmless ûnderwerp fan de echte publisearrer nei de echte abonnent en befêstigje sawol it oankundige einpunt as it antwurdpaad. Ien berjocht bewist dat it paad wurket; in stabile tichtens bewist dat it iepen bliuwt. Hâld actuatorbestjoering en feiligenschecks bûten dizze test dy’t allinnich it netwurk oangiet, om’t in wurkjend ûnderwerp gjin wurkjende robot sertifisearret. Skriuw de ROS-ferzje en it einpuntpear op dat jo sjoen hawwe, sadat de folgjende persoan in topologyferoaring fan in regression skiede kin.

De checklist is klear as de oankundige URI fan de abonnent berikber is, de ûnderhannele poarte allinnich foar dat peer iepen is, ien oankundige ûnderwerp streamt, en de omjouwingswearden foar beide hosts opskreaun binne. Alde ROS 1 krijt gjin reparaasjes op dit mêd, dus it ferslach is it diel dat wurkjen bliuwt nei’t de minsken feroarje.

Relatearre artikelen