Argomenti ROS 1 su VPN: seguire l’endpoint annunciato

La vostra workstation raggiunge il master di ROS 1 attraverso il tunnel e mostra comunque un elenco di argomenti vuoto. Questo schema è comune perché la registrazione al master e il trasporto degli argomenti sono due conversazioni diverse, e solo la prima passa dal master. La lista di controllo qui sotto percorre la seconda conversazione: l’endpoint che un editore annuncia, l’indirizzo che un sottoscrittore deve poter raggiungere e il permesso che lascia parlare la coppia. Tutto qui riguarda solo il vecchio ROS 1, la cui finestra di supporto per Noetic è terminata a maggio 2025.

Passo 1: dimostrate che la connessione al master non è la connessione agli argomenti

Iniziate separando ciò che funziona da ciò che non funziona. Un rostopic list riuscito dimostra che la vostra shell raggiunge la porta XMLRPC del master e che il master conosce gli argomenti; non dice nulla sulla possibilità che un sottoscrittore raggiunga l’editore. I tre comandi qui sotto rendono visibile la distinzione, e sono tutti di sola lettura.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

L’output di rostopic info indica l’URI del nodo dell’editore, cioè un indirizzo XMLRPC sull’host dell’editore. È l’indirizzo che il vostro sottoscrittore chiamerà successivamente, quindi deve essere raggiungibile da dovunque venga eseguito il sottoscrittore. Se punta a un’interfaccia che esiste solo sulla LAN del robot stesso, la ricerca sul master riesce e i dati non arrivano mai.

Passo 2: leggete l’endpoint annunciato dal nodo stesso

ROS 1 sceglie la propria identità host annunciata da ROS_IP o ROS_HOSTNAME quando uno dei due è impostato, e altrimenti ricade sulla risoluzione dei nomi dell’host stesso. Ispezionate l’ambiente del processo realmente avviato, perché un’unità systemd, un contenitore o un secondo terminale possono portare un valore diverso da quello della shell in cui il vostro test ha funzionato.

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

Un annuncio di nome host funziona solo se ogni pari risolve quel nome verso l’indirizzo raggiungibile previsto. Se quel nome si risolve solo all’interno della rete propria del robot, una workstation dall’altra parte del tunnel non ha modo di usarlo, e una VPN che non spinge alcun suffisso DNS peggiora la discrepanza. Impostare ROS_IP sull’indirizzo del tunnel è la modifica più piccola quando la topologia è instradata. Qualunque scelta facciate, annotatela per entrambe le estremità, perché un editore e un sottoscrittore che non concordano sull’identità negozieranno e poi non riusciranno a connettersi.

Fermatevi qui se l’URI annunciata usa un indirizzo verso cui nessun pari può instradare. Nessun lavoro sul firewall correggerà un nome che si risolve sull’interfaccia sbagliata.

Passo 3: rendete l’indirizzo annunciato risolvibile e instradato

Con l’URI in mano, provate la raggiungibilità dall’host del sottoscrittore invece che dal robot. La porta TCPROS viene scelta durante la negoziazione, quindi il test precoce utile è la porta XMLRPC e il test tardivo utile è il socket stabilito. Una rotta che esiste solo in una direzione è un guasto comune sulle VPN instradate, e il percorso di ritorno conta quanto quello di andata.

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

Un’interfaccia TUN instradata trasporta queste conversazioni IP senza estendere il segmento Ethernet del robot, che di solito è ciò che vuole un operatore remoto. Se qualcosa nello stack dipende invece da broadcast o multicast, quel requisito va valutato a parte; convertire il tunnel in TAP per soddisfare un solo strumento allarga la rete per ogni partecipante.

Fermatevi qui se manca la rotta o il percorso di ritorno. Un editore che risponde sul proprio host ma non è raggiungibile dalla workstation ha un problema di instradamento, non un problema di ROS.

Passo 4: consentite la conversazione tra pari e osservate un argomento

Aprite solo le porte necessarie alla conversazione negoziata, e limitate ogni regola ai partecipanti dichiarati. L’ascoltatore del master non è un relè per il carico degli argomenti, quindi consentire solo quello lascia chiuso l’endpoint dell’editore. Tenete gli ascoltatori ROS al confine della VPN privata invece di esporli a internet pubblico.

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

Osservate un argomento innocuo dall’editore reale al sottoscrittore reale e confermate sia l’endpoint annunciato sia il percorso di risposta. Un solo messaggio dimostra che il percorso funziona; una frequenza stabile dimostra che resta aperto. Tenete il controllo degli attuatori e i controlli di sicurezza fuori da questo test solo di rete, perché un argomento che funziona non certifica un robot che funziona. Annotate la versione di ROS e la coppia di endpoint osservata, così la persona successiva può distinguere un cambio di topologia da una regressione.

La lista di controllo è finita quando l’URI annunciata è raggiungibile dal sottoscrittore, la porta negoziata è aperta solo per quel pari, un argomento dichiarato scorre e i valori d’ambiente sono scritti per entrambi gli host. Il vecchio ROS 1 non riceverà correzioni in quest’area, quindi il registro è la parte che continua a funzionare dopo il cambio delle persone.