ROS 2 over ein VPN: oppdaging er ikkje datastien

To ROS 2-nodar i kvar sin ende av ein VPN kan liste kvarandres emne og likevel ikkje levere éi einaste melding. Oppdaging og brukardata er separate utvekslingar med separate stiar, og ein oppdagingsserver videresender ikkje nyttelast. Å kontrollere det eine og anta det andre er korleis team endar med å byte ut middleware når tunnelen rett og slett aldri bar dataa. Prosedyren nedanfor skil dei to resultata før noko blir bytt ut.

Kva oppdagingsserveren faktisk ber

I Fast DDS distribuerer ein Discovery Server informasjon om endepunkt: kven som publiserer, kven som abonnerer og kva QoS kvar forventar. Når partane kjenner kvarandre, reiser brukardata direkte mellom dei i staden for gjennom den serveren. Å nå serveren beviser at formidlaren av introduksjonane svarar, og ikkje meir. Eit ruta VPN treng framleis ein fungerande sti i begge retningar mellom adressene partane annonserer.

Den skilnaden forklarer også delvise feil, der eksisterande partar held fram med å utveksle data medan ny oppdaging sluttar å verke. Handsama dei som to undersøkingar.

Les RMW-en nodane faktisk brukar

ROS 2 kan laste inn ulike middleware, og ein variabel som blir eksportert i skalet ditt, når ikkje prosessar som blir starta ein annan stad. Spør det køyrande systemet i staden for terminalhistorikken.

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

Ein variabel som ikkje er sett, tyder vanlegvis den installerte standardverdien, som kan variere mellom maskinar i same eksperiment. Rapporten nemner også distribusjonen og middlewaren som blir brukt, så samanlikn dei på begge sider av tunnelen før du antar at dei stemmer. ROS-kommandolinja sin daemon cachar tilstand, så start han på nytt etter at du har endra miljøet i staden for å la ein utdatert daemon svare for den gamle konfigurasjonen. Skriv distribusjonen og RMW-en til begge vertane i testnotata medan økta er open.

Test oppdaging og data som to resultat

Vel eit ufarleg emne og mål introduksjonen separat frå levering. Kommandoen info listar endepunkt og QoS, medan echo beviser om éi melding faktisk kryssar lenkja.

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

At endepunkt viser seg i info-utdata, er eit oppdagingsresultat. At ei melding når abonnenten, er eit transportresultat, og berre det andre testar stien applikasjonen treng. Når oppdaginga verkar og echo går ut på tid, undersøk dei annonserte adressene og returruta i staden for oppdagingstenesta. Køyr begge kommandoane frå kvar vert, fordi ei asymmetrisk VPN-rute ofte berre avslører seg frå éi side.

Endre éin avhengnad om gongen

Når datastien sviktar, unngå å endre middleware, oppdagingsmodus og meldingsstorleik i same økt, sidan ingen resultat kan tilskrivast etterpå. Zenoh RMW er eit legitimt alternativ, men ruteren blir ein annan avhengnad som må vere tilgjengeleg gjennom tunnelen.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Under den RMW-en ber ruteren oppdaging i standard Jazzy-oppsett, og multicast-oppdaging er deaktivert der, så avhengnaden høyrer i notata dine i staden for i ei antaking lånt frå ein annan middleware. Hald arbeidslasta fast medan du endrar éi innstilling, og gjenta deretter echo-testen og registrer retning, meldingsrate og lenkjetilhøve. Køyr samanlikninga to gonger for å skilje ei reell betring frå ei heldig gjenoppkobling. Viss ei endring betrar oppdaginga medan leveringa blir den same, har du flytta introduksjonstenesta, ikkje datastien.