ROS 2 över en VPN: upptäckt är inte datavägen

Två ROS 2-noder i var sin ände av en VPN kan lista varandras ämnen och ändå inte leverera ett enda meddelande. Upptäckt och användardata är separata utbyten med separata vägar, och en upptäcktsserver vidarebefordrar inte nyttolast. Att kontrollera det ena och anta det andra är hur team till slut byter ut middleware när tunneln helt enkelt aldrig bar data. Proceduren nedan skiljer de två resultaten åt innan något byts ut.

Vad upptäcktsservern faktiskt bär

I Fast DDS distribuerar en Discovery Server information om slutpunkter: vem som publicerar, vem som prenumererar och vilken QoS var och en förväntar sig. När parterna känner varandra reser användardata direkt mellan dem i stället för genom den servern. Att nå servern bevisar att förmedlaren av presentationerna svarar, och inget mer. En routad VPN behöver fortfarande en fungerande väg i båda riktningarna mellan de adresser som parterna annonserar.

Den skillnaden förklarar också delvisa fel, där befintliga parter fortsätter att utbyta data medan ny upptäckt slutar fungera. Behandla dem som två utredningar.

Läs RMW:n som noderna faktiskt använder

ROS 2 kan läsa in olika middleware, och en variabel som exporteras i ditt skal når inte processer som startas någon annanstans. Fråga det körande systemet i stället för din terminalhistorik.

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

En variabel som inte är satt betyder vanligtvis det installerade standardvärdet, som kan skilja sig mellan maskiner i samma experiment. Rapporten namnger också distributionen och middlewaren som används, så jämför dem på båda sidor av tunneln innan du antar att de stämmer. ROS-kommandoradjets daemon cachar tillstånd, så starta om den efter att du ändrat miljön i stället för att låta en inaktuell daemon svara för den gamla konfigurationen. Skriv båda värdarnas distribution och RMW i testanteckningarna medan sessionen är öppen.

Testa upptäckt och data som två resultat

Välj ett ofarligt ämne och mät presentationen separat från leveransen. Kommandot info listar slutpunkter och QoS, medan echo bevisar om ett meddelande faktiskt korsar länken.

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

Att slutpunkter visas i info-utdata är ett upptäcktsresultat. Att ett meddelande når prenumeranten är ett transportresultat, och bara det andra prövar den väg som applikationen behöver. När upptäckten fungerar och echo får timeout, undersök de annonserade adresserna och returvägen i stället för upptäcktstjänsten. Kör båda kommandona från varje värd, eftersom en asymmetrisk VPN-väg ofta bara avslöjar sig från ena sidan.

Ändra ett beroende i taget

När datavägen misslyckas, undvik att ändra middleware, upptäcktsläge och meddelandestorlek i samma session, eftersom inget resultat kan tillskrivas efteråt. Zenoh RMW är ett legitimt alternativ, men dess router blir ett annat beroende som måste vara nåbart genom tunneln.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Under den RMW:n bär routern upptäckt i standardarrangemanget för Jazzy, och multicast-upptäckt är inaktiverat där, så beroendet hör hemma i dina anteckningar i stället för i ett antagande lånat från en annan middleware. Håll arbetsbelastningen fast medan du ändrar en inställning, upprepa sedan echo-testet och registrera riktning, meddelandefrekvens och länkförhållanden. Kör jämförelsen två gånger för att skilja en verklig förbättring från en lycklig återanslutning. Om en ändring förbättrar upptäckten medan leveransen är densamma, har du flyttat presentationstjänsten, inte datavägen.