ROS 2 over en VPN: oppdagelse er ikke datastien

To ROS 2-noder i hver sin ende av en VPN kan liste hverandres emner og likevel ikke levere én eneste melding. Oppdagelse og brukerdata er separate utvekslinger med separate stier, og en oppdagelsesserver videresender ikke nyttelast. Å kontrollere det ene og anta det andre er hvordan team ender opp med å bytte ut middleware når tunnelen rett og slett aldri bar dataene. Prosedyren nedenfor skiller de to resultatene før noe byttes ut.

Hva oppdagelsesserveren faktisk bærer

I Fast DDS distribuerer en Discovery Server informasjon om endepunkter: hvem som publiserer, hvem som abonnerer og hvilken QoS hver forventer. Når partene kjenner hverandre, reiser brukerdata direkte mellom dem i stedet for gjennom den serveren. Å nå serveren beviser at formidleren av introduksjonene svarer, og ikke mer. En rutet VPN trenger fortsatt en fungerende sti i begge retninger mellom adressene partene annonserer.

Den forskjellen forklarer også delvise feil, der eksisterende parter fortsetter å utveksle data mens ny oppdagelse slutter å virke. Behandle dem som to undersøkelser.

Les RMW-en nodene faktisk bruker

ROS 2 kan laste inn ulike middleware, og en variabel som eksporteres i skallet ditt, når ikke prosesser som startes et annet sted. Spør det kjørende systemet i stedet for terminalhistorikken.

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

En variabel som ikke er satt, betyr vanligvis den installerte standardverdien, som kan variere mellom maskiner i samme eksperiment. Rapporten navngir også distribusjonen og middlewaren som brukes, så sammenlign dem på begge sider av tunnelen før du antar at de stemmer. ROS-kommandolinjens daemon cacher tilstand, så start den på nytt etter at du har endret miljøet i stedet for å la en utdatert daemon svare for den gamle konfigurasjonen. Skriv begge vertenes distribusjon og RMW i testnotatene mens økten er åpen.

Test oppdagelse og data som to resultater

Velg et ufarlig emne og mål introduksjonen separat fra levering. Kommandoen info lister endepunkter og QoS, mens echo beviser om én melding faktisk krysser lenken.

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

At endepunkter vises i info-utdata, er et oppdagelsesresultat. At en melding når abonnenten, er et transportresultat, og bare det andre tester stien applikasjonen trenger. Når oppdagelsen virker og echo går ut på tid, undersøk de annonserte adressene og returruten i stedet for oppdagelsestjenesten. Kjør begge kommandoene fra hver vert, fordi en asymmetrisk VPN-rute ofte bare avslører seg fra én side.

Endre én avhengighet om gangen

Når datastien svikter, unngå å endre middleware, oppdagelsesmodus og meldingsstørrelse i samme økt, siden ingen resultat kan tilskrives etterpå. Zenoh RMW er et legitimt alternativ, men ruteren blir en annen avhengighet som må være tilgjengelig gjennom tunnelen.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Under den RMW-en bærer ruteren oppdagelse i standard Jazzy-oppsett, og multicast-oppdagelse er deaktivert der, så avhengigheten hører i notatene dine i stedet for i en antakelse lånt fra en annen middleware. Hold arbeidsbelastningen fast mens du endrer én innstilling, og gjenta deretter echo-testen og registrer retning, meldingsrate og lenkeforhold. Kjør sammenligningen to ganger for å skille en reell forbedring fra en heldig gjenoppkobling. Hvis en endring forbedrer oppdagelsen mens leveringen forblir den samme, har du flyttet introduksjonstjenesten, ikke datastien.