ROS 2 przez VPN: wykrywanie to nie ścieżka danych

Dwa węzły ROS 2 na przeciwnych końcach VPN mogą wyliczać swoje tematy i mimo to nie dostarczyć ani jednej wiadomości. Wykrywanie i dane użytkownika to osobne wymiany z osobnymi ścieżkami, a serwer wykrywania nie przekazuje ładunków. Sprawdzenie jednego i założenie drugiego to sposób, w jaki zespoły zaczynają wymieniać middleware, gdy tunel po prostu nigdy nie przenosił danych. Poniższa procedura rozdziela oba wyniki, zanim cokolwiek zostanie wymienione.

Co serwer wykrywania faktycznie przenosi

W Fast DDS Discovery Server rozprowadza informacje o punktach końcowych: kto publikuje, kto subskrybuje i jakiego QoS oczekuje każdy. Gdy partnerzy się znają, dane użytkownika podróżują bezpośrednio między nimi, a nie przez ten serwer. Dotarcie do serwera dowodzi, że pośrednik zapoznań odpowiada, i nic więcej. Routowany VPN nadal potrzebuje działającej ścieżki w obu kierunkach między adresami ogłaszanymi przez partnerów.

Ta różnica wyjaśnia też częściowe awarie, w których istniejący partnerzy nadal wymieniają dane, a nowe wykrywanie przestaje działać. Traktuj je jako dwa osobne dochodzenia.

Odczytaj RMW, którego węzły naprawdę używają

ROS 2 może ładować różne middleware, a zmienna wyeksportowana w twojej powłoce nie dociera do procesów uruchomionych gdzie indziej. Pytaj działający system, a nie historię terminala.

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

Nieustawiona zmienna zwykle oznacza zainstalowaną wartość domyślną, która może się różnić między maszynami w tym samym eksperymencie. Raport podaje też dystrybucję i używane middleware, więc porównaj je po obu stronach tunelu, zanim założysz, że są zgodne. Demon wiersza poleceń ROS buforuje stan, więc zrestartuj go po zmianie środowiska, zamiast pozwalać nieaktualnemu demonowi odpowiadać za starą konfigurację. Zapisz dystrybucję i RMW obu hostów w notatkach testowych, dopóki sesja jest otwarta.

Testuj wykrywanie i dane jako dwa wyniki

Wybierz nieszkodliwy temat i mierz zapoznanie osobno od dostarczenia. Polecenie info wylicza punkty końcowe i QoS, a echo dowodzi, czy jedna wiadomość rzeczywiście przechodzi przez łącze.

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

Pojawienie się punktów końcowych w wyniku info to wynik wykrywania. Dotarcie wiadomości do subskrybenta to wynik transportu i tylko ten drugi testuje ścieżkę potrzebną aplikacji. Gdy wykrywanie działa, a echo przekracza limit czasu, zbadaj ogłoszone adresy i trasę powrotną, a nie usługę wykrywania. Uruchom oba polecenia z każdego hosta, ponieważ asymetryczna trasa VPN często ujawnia się tylko z jednej strony.

Zmieniaj jedną zależność naraz

Gdy ścieżka danych zawodzi, unikaj zmiany middleware, trybu wykrywania i rozmiaru wiadomości w tej samej sesji, ponieważ później nie da się przypisać żadnego wyniku. RMW Zenoh jest legalną alternatywą, ale jego router staje się kolejną zależnością, która musi być osiągalna przez tunel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

W tym RMW router przenosi wykrywanie w domyślnym układzie Jazzy, a wykrywanie multicast jest tam wyłączone, więc zależność należy do twoich notatek, a nie do założenia zapożyczonego z innego middleware. Utrzymuj stałe obciążenie, zmieniając jedno ustawienie, następnie powtórz test echo i zapisz kierunek, szybkość wiadomości i warunki łącza. Powtórz porównanie dwa razy, aby oddzielić rzeczywistą poprawę od szczęśliwego ponownego połączenia. Jeśli zmiana poprawia wykrywanie, a dostarczanie pozostaje takie samo, przeniosłeś usługę zapoznań, a nie ścieżkę danych.