ROS 2 su una VPN: la scoperta non è il percorso dei dati

Due nodi ROS 2 agli estremi opposti di una VPN possono elencare i topic l’uno dell’altro e comunque non consegnare un solo messaggio. La scoperta e i dati utente sono scambi separati con percorsi separati, e un server di scoperta non inoltra i payload. Verificare l’uno e presumere l’altro è il modo in cui i team finiscono per sostituire il middleware quando il tunnel semplicemente non ha mai trasportato i dati. La procedura seguente separa i due risultati prima di qualsiasi sostituzione.

Ciò che il server di scoperta trasporta davvero

In Fast DDS, un Discovery Server distribuisce informazioni sugli endpoint: chi pubblica, chi si iscrive e quale QoS ciascuno si aspetta. Una volta che i peer si conoscono, i dati utente viaggiano direttamente tra loro invece che attraverso quel server. Raggiungere il server dimostra che il broker delle presentazioni risponde, nulla di più. Una VPN instradata ha ancora bisogno di un percorso funzionante in entrambe le direzioni tra gli indirizzi annunciati dai peer.

Questa distinzione spiega anche i guasti parziali, in cui i peer esistenti continuano a scambiare dati mentre la nuova scoperta smette di funzionare. Trattateli come due indagini.

Leggete l’RMW che i nodi usano davvero

ROS 2 può caricare middleware diversi, e una variabile esportata nella vostra shell non raggiunge i processi avviati altrove. Interrogate il sistema in esecuzione invece della cronologia del terminale.

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

Una variabile non impostata di solito significa il valore predefinito installato, che può differire tra macchine dello stesso esperimento. Il report nomina anche la distribuzione e il middleware in uso, quindi confrontateli su entrambi i lati del tunnel prima di presumere che coincidano. Il demone della riga di comando di ROS memorizza lo stato nella cache, quindi riavviatelo dopo aver cambiato l’ambiente invece di lasciare che un demone obsoleto risponda per la vecchia configurazione. Annotate la distribuzione e l’RMW di entrambi gli host nelle note del test finché la sessione è aperta.

Provate scoperta e dati come due risultati

Scegliete un topic innocuo e misurate la presentazione separatamente dalla consegna. Il comando info elenca endpoint e QoS, mentre echo dimostra se un messaggio attraversa davvero il collegamento.

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

La comparsa di endpoint nell’output di info è un risultato di scoperta. L’arrivo di un messaggio al sottoscrittore è un risultato di trasporto, e solo il secondo esercita il percorso di cui l’applicazione ha bisogno. Quando la scoperta funziona e echo va in timeout, ispezionate gli indirizzi annunciati e la rotta di ritorno invece del servizio di scoperta. Eseguite entrambi i comandi da ogni host, perché una rotta VPN asimmetrica spesso si rivela solo da un lato.

Cambiate una dipendenza alla volta

Quando il percorso dei dati fallisce, evitate di modificare middleware, modalità di scoperta e dimensione dei messaggi nella stessa sessione, perché nessun risultato potrà più essere attribuito. L’RMW Zenoh è un’alternativa legittima, ma il suo router diventa un’altra dipendenza che deve essere raggiungibile attraverso il tunnel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Con quell’RMW il router trasporta la scoperta nella disposizione predefinita di Jazzy, e lì la scoperta multicast è disattivata, quindi la dipendenza appartiene alle vostre note e non a un’ipotesi presa in prestito da un altro middleware. Mantenete fisso il carico di lavoro mentre cambiate un’impostazione, poi ripetete il test echo e registrate direzione, frequenza dei messaggi e condizioni del collegamento. Ripetete il confronto due volte per distinguere un miglioramento reale da una riconnessione fortunata. Se una modifica migliora la scoperta mentre la consegna resta identica, avete spostato il servizio di presentazione, non il percorso dei dati.