Tematy ROS 1 przez VPN: podążaj za ogłoszonym punktem końcowym

Rejestracja w masterze ROS 1 nie przenosi danych tematów. Odczytaj ogłoszony URI węzła, uczyń ten adres trasowalnym, a następnie zezwól na port wydawcy.

Twoja stacja robocza dociera do mastera ROS 1 przez tunel i nadal pokazuje pustą listę tematów. Ten wzorzec jest częsty, ponieważ rejestracja w masterze i transport tematów to dwie różne rozmowy, a tylko pierwsza przechodzi przez mastera. Poniższa lista kontrolna przechodzi drugą rozmowę: punkt końcowy ogłaszany przez wydawcę, adres, do którego musi dotrzeć subskrybent, oraz uprawnienie, które pozwala parze rozmawiać. Wszystko tutaj dotyczy tylko starego ROS 1, którego okno wsparcia Noetic zakończyło się w maju 2025.

Krok 1: udowodnij, że połączenie z masterem to nie połączenie z tematem

Zacznij od rozdzielenia tego, co działa, od tego, co nie działa. Udane rostopic list dowodzi, że twoja powłoka dociera do portu XMLRPC mastera i że master zna tematy; nie mówi nic o tym, czy subskrybent może dotrzeć do wydawcy. Trzy poniższe polecenia czynią tę różnicę widoczną, a wszystkie są tylko do odczytu.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Wyjście rostopic info podaje URI węzła wydawcy, czyli adres XMLRPC na hoście wydawcy. To ten adres twój subskrybent wywoła następnie, więc musi być osiągalny z dowolnego miejsca, w którym działa subskrybent. Jeśli wskazuje interfejs istniejący tylko w sieci LAN samego robota, wyszukiwanie w masterze się udaje, a dane nigdy nie docierają.

Krok 2: odczytaj ogłoszony punkt końcowy z samego węzła

ROS 1 wybiera ogłaszaną tożsamość hosta z ROS_IP lub ROS_HOSTNAME, gdy któryś z nich jest ustawiony, a w przeciwnym razie wraca do własnego rozwiązywania nazw hosta. Sprawdź środowisko procesu, który został faktycznie uruchomiony, ponieważ jednostka systemd, kontener lub drugi terminal mogą nieść inną wartość niż powłoka, w której zadziałał twój test.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

Ogłoszenie nazwy hosta działa tylko wtedy, gdy każdy partner rozwiązuje tę nazwę na zamierzony osiągalny adres. Jeśli ta nazwa jest rozwiązywana tylko w sieci samego robota, stacja robocza po drugiej stronie tunelu nie ma jak jej użyć, a VPN, który nie wypycha żadnego sufiksu DNS, pogarsza niezgodność. Ustawienie ROS_IP na adres tunelu to mniejsza zmiana, gdy topologia jest trasowana. Cokolwiek wybierzesz, zapisz to dla obu końców, ponieważ wydawca i subskrybent, którzy nie zgadzają się co do tożsamości, będą negocjować, a potem nie zdołają się połączyć.

Zatrzymaj się tutaj, jeśli ogłoszony URI używa adresu, do którego żaden partner nie może trasować. Żadna praca z zaporą nie naprawi nazwy, która rozwiązuje się na niewłaściwy interfejs.

Krok 3: uczyń ogłoszony adres rozwiązywalnym i trasowanym

Mając URI w ręku, testuj osiągalność z hosta subskrybenta, a nie z robota. Port TCPROS jest wybierany podczas negocjacji, więc użytecznym wczesnym testem jest port XMLRPC, a użytecznym późnym testem jest ustanowione gniazdo. Trasa istniejąca tylko w jednym kierunku to częsta usterka w trasowanych VPN, a droga powrotna liczy się tak samo jak droga tam.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

Trasowany interfejs TUN przenosi te rozmowy IP bez rozszerzania segmentu Ethernet robota, czego zwykle chce operator zdalny. Jeśli coś w stosie zależy zamiast tego od rozgłaszania lub multicastu, to wymaganie trzeba ocenić osobno; zamiana tunelu na TAP, aby zadowolić jedno narzędzie, poszerza sieć dla każdego uczestnika.

Zatrzymaj się tutaj, jeśli brakuje trasy lub drogi powrotnej. Wydawca, który odpowiada na własnym hoście, ale nie jest osiągalny ze stacji roboczej, ma problem z trasowaniem, a nie problem z ROS.

Krok 4: zezwól na rozmowę partnerów i obserwuj jeden temat

Otwórz tylko te porty, których potrzebuje wynegocjowana rozmowa, i ogranicz każdą regułę do zadeklarowanych uczestników. Nasłuch mastera nie jest przekaźnikiem ładunku tematów, więc zezwolenie tylko jemu pozostawia punkt końcowy wydawcy zamknięty. Trzymaj nasłuchy ROS na granicy prywatnego VPN, zamiast wystawiać je do publicznego internetu.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Obserwuj jeden nieszkodliwy temat od prawdziwego wydawcy do prawdziwego subskrybenta i potwierdź zarówno ogłoszony punkt końcowy, jak i drogę odpowiedzi. Jedna wiadomość dowodzi, że droga działa; stabilne tempo dowodzi, że pozostaje otwarta. Trzymaj sterowanie siłownikami i kontrole bezpieczeństwa poza tym testem dotyczącym tylko sieci, ponieważ działający temat nie certyfikuje działającego robota. Zapisz wersję ROS i zaobserwowaną parę punktów końcowych, aby następna osoba mogła odróżnić zmianę topologii od regresji.

Lista kontrolna jest gotowa, gdy ogłoszony URI jest osiągalny od subskrybenta, wynegocjowany port jest otwarty tylko dla tego partnera, jeden zadeklarowany temat płynie, a wartości środowiska są zapisane dla obu hostów. Stary ROS 1 nie otrzyma poprawek w tym obszarze, więc zapis jest tą częścią, która działa dalej po zmianie ludzi.

Powiązane artykuły