ROS 2 over en VPN: opdagelse er ikke datastien

To ROS 2-noder i hver sin ende af en VPN kan liste hinandens emner og alligevel ikke levere én enkelt besked. Opdagelse og brugerdata er separate udvekslinger med separate stier, og en opdagelsesserver videresender ikke nyttelast. At kontrollere det ene og antage det andet er, hvordan teams ender med at udskifte middleware, når tunnelen blot aldrig har båret dataene. Proceduren nedenfor adskiller de to resultater, før noget udskiftes.

Hvad opdagelsesserveren faktisk bærer

I Fast DDS fordeler en Discovery Server information om endepunkter: hvem der publicerer, hvem der abonnerer, og hvilken QoS hver især forventer. Når peers kender hinanden, rejser brugerdata direkte mellem dem i stedet for gennem den server. At nå serveren beviser, at introduktionernes mægler svarer, og intet mere. En routet VPN har stadig brug for en fungerende sti i begge retninger mellem de adresser, som peers annoncerer.

Den forskel forklarer også delvise fejl, hvor eksisterende peers fortsætter med at udveksle data, mens ny opdagelse holder op med at virke. Behandl dem som to undersøgelser.

Læs den RMW, noderne faktisk bruger

ROS 2 kan indlæse forskellige middleware, og en variabel, der eksporteres i din shell, når ikke processer, der er startet et andet sted. Spørg det kørende system i stedet for din terminalhistorik.

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

En ikke-sat variabel betyder normalt den installerede standard, som kan variere mellem maskiner i det samme eksperiment. Rapporten angiver også distributionen og den anvendte middleware, så sammenlign dem på begge sider af tunnelen, før du antager, at de matcher. ROS-kommandolinjens dæmon cacher tilstand, så genstart den efter ændring af miljøet i stedet for at lade en forældet dæmon svare for den gamle konfiguration. Skriv begge værters distribution og RMW i testnoterne, mens sessionen er åben.

Test opdagelse og data som to resultater

Vælg et ufarligt emne, og mål introduktion separat fra levering. Kommandoen info viser endepunkter og QoS, mens echo beviser, om én besked faktisk krydser linket.

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

At endepunkter optræder i info-outputtet er et opdagelsesresultat. At en besked ankommer til abonnenten er et transportresultat, og kun det andet tester den sti, som applikationen har brug for. Når opdagelse virker, og echo får timeout, skal du undersøge de annoncerede adresser og returruten i stedet for opdagelsestjenesten. Kør begge kommandoer fra hver vært, fordi en asymmetrisk VPN-rute ofte kun afslører sig fra den ene side.

Skift én afhængighed ad gangen

Når datastien fejler, skal du undgå at ændre middleware, opdagelsestilstand og beskedstørrelse i samme session, da intet resultat bagefter kan tilskrives. Zenoh RMW er et legitimt alternativ, men dets router bliver endnu en afhængighed, som skal kunne nås gennem tunnelen.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Under den RMW bærer routeren opdagelse i standard Jazzy-arrangementet, og multicast-opdagelse er deaktiveret der, så afhængigheden hører i dine noter frem for i en antagelse lånt fra en anden middleware. Hold arbejdsbelastningen fast, mens du ændrer én indstilling, og gentag derefter echo-testen, og registrer retning, beskedrate og linkforhold. Kør sammenligningen to gange for at skelne en reel forbedring fra en heldig genopkobling. Hvis en ændring forbedrer opdagelsen, mens leveringen er den samme, har du flyttet introduktionstjenesten, ikke datastien.