ROS 2 over een VPN: ontdekking is niet het datapad

Twee ROS 2-nodes aan weerszijden van een VPN kunnen elkaars topics opsommen en toch geen enkel bericht afleveren. Ontdekking en gebruikersgegevens zijn gescheiden uitwisselingen met gescheiden paden, en een ontdekkingsserver stuurt geen payloads door. Het ene controleren en het andere aannemen is hoe teams middleware vervangen terwijl de tunnel de gegevens simpelweg nooit heeft gedragen. De procedure hieronder scheidt de twee resultaten voordat er iets wordt vervangen.

Wat de ontdekkingsserver werkelijk draagt

In Fast DDS verdeelt een Discovery Server informatie over eindpunten: wie publiceert, wie abonneert en welke QoS elk verwacht. Zodra peers elkaar kennen, reizen gebruikersgegevens rechtstreeks tussen hen in plaats van via die server. De server bereiken bewijst dat de bemiddelaar van de introducties antwoordt, en niets meer. Een gerouteerde VPN heeft nog steeds een werkend pad in beide richtingen nodig tussen de adressen die de peers aankondigen.

Dat onderscheid verklaart ook gedeeltelijke storingen, waarbij bestaande peers gegevens blijven uitwisselen terwijl nieuwe ontdekking stopt met werken. Behandel ze als twee onderzoeken.

Lees de RMW die de nodes echt gebruiken

ROS 2 kan verschillende middleware laden, en een variabele die in uw shell wordt geëxporteerd, bereikt geen processen die elders zijn gestart. Vraag het draaiende systeem in plaats van uw terminalgeschiedenis.

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

Een niet-ingestelde variabele betekent meestal de geïnstalleerde standaard, die kan verschillen tussen machines in hetzelfde experiment. Het rapport noemt ook de distributie en de gebruikte middleware, dus vergelijk ze aan beide zijden van de tunnel voordat u aanneemt dat ze overeenkomen. De ROS-opdrachtregeldaemon cachet de status, dus herstart hem na een wijziging van de omgeving in plaats van een verouderde daemon voor de oude configuratie te laten antwoorden. Noteer de distributie en RMW van beide hosts in de testnotities zolang de sessie open is.

Test ontdekking en gegevens als twee resultaten

Kies een onschadelijk topic en meet de introductie apart van de aflevering. Het commando info somt eindpunten en QoS op, terwijl echo bewijst of één bericht de verbinding echt oversteekt.

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

Dat eindpunten in de info-uitvoer verschijnen is een ontdekkingsresultaat. Dat een bericht de abonnee bereikt is een transportresultaat, en alleen het tweede beproeft het pad dat de toepassing nodig heeft. Wanneer ontdekking werkt en echo een time-out krijgt, onderzoek dan de aangekondigde adressen en de terugroute in plaats van de ontdekkingsdienst. Voer beide commando's vanaf elke host uit, want een asymmetrische VPN-route openbaart zich vaak maar vanaf één kant.

Wijzig één afhankelijkheid tegelijk

Wanneer het datapad faalt, vermijd dan om middleware, ontdekkingsmodus en berichtgrootte in dezelfde sessie te wijzigen, omdat daarna geen resultaat meer kan worden toegeschreven. De Zenoh RMW is een legitiem alternatief, maar de router ervan wordt een extra afhankelijkheid die via de tunnel bereikbaar moet zijn.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Onder die RMW draagt de router ontdekking in de standaard Jazzy-indeling, en multicast-ontdekking is daar uitgeschakeld, dus de afhankelijkheid hoort in uw notities in plaats van in een aanname die van andere middleware is geleend. Houd de workload vast terwijl u één instelling wijzigt, herhaal dan de echo-test en noteer richting, berichtsnelheid en verbindingsomstandigheden. Voer de vergelijking twee keer uit om een echte verbetering van een gelukkige herverbinding te scheiden. Als een wijziging ontdekking verbetert terwijl de aflevering gelijk blijft, hebt u de introductiedienst verplaatst, niet het datapad.