ROS 2 w sieci bezprzewodowej: ustawienia DDS QoS dla zespołów robotów mobilnych

Zespoły robotów mobilnych często komunikują się niezawodnie w laboratorium, a następnie opracowują opóźnione polecenia, brak aktualizacji czujników lub powolne przywracanie działania w przypadku zmiany tras siatki. A Bezprzewodowa siatka ROS 2 zwiększa zmienną przepustowość, utratę pakietów i zmianę liczby przeskoków, podczas gdy DDS może retransmitować lub kolejkować dane, które są już nieaktualne. Ustawienia QoS pomagają kontrolować niezawodność, historię, głębokość, trwałość, termin i długość życia każdego tematu, ale niezgodne zasady wydawcy i subskrybenta mogą całkowicie uniemożliwić dostarczanie.

Kluczem jest wiedza, które strumienie wymagają każdej próbki, a które tylko najnowszej, i jak zapobiec przytłaczaniu łącza odzyskiwania dużymi ładunkami.

Zacznij od ruchu, a nie od menu QoS

Zdecyduj, czy ważniejsza jest świeżość czy kompletność

Zacznij od pytania, co się stanie, gdy wiadomość zaginie i co się stanie, jeśli dotrze z opóźnieniem. Skany LiDAR, ramki kamer, odometria, aktualizacje lokalizacji i telemetria ruchu są stale wymieniane. Utrata jednej próbki może być akceptowalna, natomiast dostarczenie jej po kilku nowszych próbkach może zakłócić lokalne decyzje lub zmarnować czas przetwarzania.

Przejścia misji, przydziały zadań, zmiany konfiguracji, zdarzenia związane z bezpieczeństwem i niektóre transfery map wiążą się z różnymi wymaganiami. Brakujące dyskretne zdarzenie może pozostawić roboty w niespójnych stanach roboczych, dlatego ograniczona retransmisja może być uzasadniona. To rozróżnienie ma większe znaczenie niż sam rodzaj ładunku: polecenie małej prędkości może być niebezpieczne, gdy jest nieaktualne, podczas gdy migawka dużej mapy może pozostać przydatna po pewnym opóźnieniu.

Klasyfikacja ruchu według aktualności i kompletności zapobiega typowemu błędowi sieci bezprzewodowej ROS 2 — ustawiając każdy temat jako NIEZAWODNY, ponieważ niezawodność brzmi bezpieczniej. Niezawodny system DDS zatrzymuje niepotwierdzone próbki i retransmituje brakujące dane, tworząc obciążenie, którego unika się w przypadku komunikacji opartej na najlepszych staraniach. Dlatego standardowy profil danych z czujnika ROS 2 wykorzystuje niezawodność typu best-effort przy mniejszej kolejce, gdzie terminowa dostawa ma zazwyczaj większe znaczenie niż otrzymanie każdego odczytu.

Każdemu tematowi przypisz budżet realizacji

Każdy temat dotyczący wielu robotów wymaga czterech limitów: maksymalnego użytecznego wieku wiadomości, akceptowalnego współczynnika strat, wymaganej częstotliwości aktualizacji i maksymalnego czasu przywracania po rozłączeniu. Limity te przekształcają niejasne oczekiwania, takie jak „niskie opóźnienia”, w wymagania, które można przetestować. Strumień poleceń może wymagać ograniczenia wieku mierzonego w dziesiątkach milisekund, podczas gdy migawka mapy może tolerować sekundy, jeśli robot będzie nadal bezpiecznie działał ze swoją lokalną kopią.

Oszacuj oferowany ładunek na podstawie rozmiaru seryjnego ładunku, częstotliwości publikacji i liczby miejsc docelowych. Następnie porównaj tę liczbę ze zmierzoną wydajnością wielu przeskoków, a nie z nominalną szybkością transmisji danych radia. Pozostaw miejsce na potwierdzenia, retransmisje, ruch związany z odkryciem, ruch związany z zarządzaniem trasami i równoczesnych wydawców.

Trzymaj ruch wewnętrzny robota poza współdzieloną siatką

Nie każdy temat ROS 2 powinien przekraczać granice robotów. Surowe obrazy z kamery, pełne chmury punktów, dane debugowania i pośrednie wyniki percepcji często należą do robota, który je produkuje. Publikowanie wyłącznie wykryć, śladów obiektów, planów lokalnych, zredukowanej liczby chmur lub zmian map zmniejsza zapotrzebowanie na współdzielony kanał bez zmiany zachowania DDS.

Ten etap filtrowania jest szczególnie przydatny w sieci bezprzewodowej ROS 2 składającej się z wielu robotów, gdzie jeden niepotrzebny strumień o dużej szybkości może zużywać pojemność potrzebną do realizacji kilku tematów koordynacyjnych. Usunięcie ruchu zwykle tworzy bardziej przewidywalny system niż próba ochrony przeciążonego łącza za pomocą głębszych kolejek i dodatkowych ponownych prób.

Praktyczne profile QoS dla typowych tematów dotyczących floty

Strumienie czujników i stan często odświeżany

Tematy dotyczące czujników i stanów o dużej częstotliwości zwykle wymagają najnowszej dostępnej próbki, a nie pełnej sekwencji historycznej. Praktyczny profil początkowy to BEST_EFFORT, VOLATILE i KEEP_LAST z głębokością od jednego do pięciu. Głębokość pierwsza odpowiada danym, które są natychmiast zastępowane, podczas gdy nieco większa kolejka może absorbować krótkie opóźnienia w harmonogramie wywołań zwrotnych bez tworzenia długich zaległości.

LIFESPAN może dodać kolejne zabezpieczenie, powodując wygaśnięcie wiadomości po upływie ich okresu przydatności. DEADLINE służy innemu celowi: wyraża oczekiwany odstęp między wiadomościami i może wywołać zdarzenie, gdy to oczekiwanie nie zostanie spełnione. Żadna z zasad nie zwiększa przepustowości łącza, ale obie sprawiają, że nieaktualne lub przerwane strumienie są łatwiejsze do wykrycia i obsługi.

Dokładny profil powinien odzwierciedlać konsumenta. Lokalny węzeł omijania przeszkód może wymagać częstych skanowań przy minimalnym wieku, podczas gdy pulpit nawigacyjny floty może zaakceptować niższą częstotliwość aktualizacji. Wysyłanie obu danych przez tę samą siatkę bezprzewodową ROS 2 nie oznacza, że ​​wymagają one identycznych ustawień niezawodności, głębokości lub żywotności.

Polecenia i zdarzenia koordynacyjne wymagają innego traktowania

Polecenia ciągłe i dyskretne zdarzenia koordynacyjne nie powinny mieć wspólnego profilu domyślnego. Strumienie prędkości, sterowania i korekcji formacji są odświeżane wielokrotnie, więc stare próbki nie powinny stać w kolejce za retransmisją. Płytka historia, krótka żywotność i limit czasu na poziomie aplikacji zapewniają, że robot zatrzyma się lub przejdzie w zdefiniowany tryb awaryjny, gdy znikną nowe polecenia.

Akceptacja zadań, zmiany trybu działania i przejścia misji mogą wymagać NIEZAWODNEGO dostarczenia, ponieważ każde zdarzenie zmienia stan współdzielony. Nawet wtedy historia musi pozostać ograniczona. Odtwarzanie długiej sekwencji zastąpionych poleceń po przywróceniu trasy może być bardziej szkodliwe niż zgłaszanie zakłóceń i ponowna synchronizacja bieżącego stanu misji.

Niezawodność DDS to tylko jedna warstwa ochrony. Każdy robot mobilny powinien wymuszać wygaśnięcie lokalnych poleceń, ograniczenia ruchu i zachowanie związane z utratą komunikacji niezależnie od sieci. Siatka bezprzewodowa ROS 2 może poprawić zasięg i odporność tras, ale nie może zdecydować, czy stare polecenie jest nadal bezpieczne.

Mapy, konfiguracja i roboty dołączające późno

Użyj RELIABLE z TRANSIENT_LOCAL, gdy robot dołączający lub ponownie łączący potrzebuje najnowszego opublikowanego stanu. Aktualne mapy, geoogrodzenia, współdzielone tryby pracy i migawki konfiguracji często pasują do tego wzorca. KEEP_LAST(1) jest zwykle bardziej odpowiedni niż zachowywanie każdej wersji, ponieważ tylko najnowszy pełny obraz stanu pozostaje istotny operacyjnie.

KEEP_ALL powinien być zarezerwowany dla danych, których pełna sekwencja jest rzeczywiście istotna i których wymagania dotyczące zasobów są znane. Przechowywanie całej pamięci podlega ograniczeniom zasobów oprogramowania pośredniego, więc nie jest to nieograniczona gwarancja. Trwałość przejściowo-lokalna sprawia również, że wydawca jest odpowiedzialny za przechowywanie próbek w przypadku subskrypcji, które dołączają później.

Kompatybilność należy sprawdzić po obu stronach. Wydawca dokładający wszelkich starań nie jest w stanie zadowolić niezawodnego subskrybenta, a wydawca niestabilny nie może zaspokoić tymczasowej subskrypcji lokalnej. Niezawodni wydawcy mogą obsługiwać subskrybentów korzystających z najlepszych usług, podczas gdy wydawcy lokalni mogą wysyłać nowe wiadomości do niestabilnych subskrybentów. Zachowane dostarczanie historyczne wymaga zgodnych ustawień przejściowych i lokalnych.

Zatrzymaj duże wiadomości przed przejęciem łącza

Zmniejsz fragmentację przed dodaniem ponownych prób

Obrazy, siatki obłożenia i gęste chmury punktów są dzielone na wiele jednostek transportowych przed przejściem przez sieć. Kiedy duży datagram UDP jest pofragmentowany w warstwie IP, utrata jednego fragmentu uniemożliwia odtworzenie całego datagramu. Pozostałe fragmenty mogą zajmować bufory jądra aż do wygaśnięcia, co sprawia wrażenie, że połączenie zostało zablokowane i blokuje nowszy ruch.

Degradacja dużego ładunku w bezprzewodowych połączeniach ROS 2 jest zwykle kojarzona z trzema połączonymi mechanizmami: nadmierną fragmentacją protokołu IP, nieefektywnym synchronizacją retransmisji i przeciążonymi przerwami bufora. Zmiany parametrów DDS zgodne ze standardami mogą zmniejszyć te efekty bez konieczności stosowania innego protokołu aplikacji.

Zmierz rzeczywisty współczynnik MTU ścieżki w całej sieci bezprzewodowej ROS 2, w tym szyfrowanie, tunele, interfejsy wirtualne i każdy routowany segment. Jeśli pozwala na to konfiguracja transportu, zmniejsz rozmiar komunikatu RTPS lub UDP na tyle, aby uniknąć fragmentacji warstwy sieci. Wartość obliczona na podstawie 1500-bajtowej jednostki MTU sieci Ethernet jest jedynie hipotezą wyjściową, ponieważ nagłówki i enkapsulacja mogą zmniejszyć użyteczny rozmiar.

Utrzymuj kolejki historii mniejsze niż okno odzyskiwania

W przypadku przerwania trasy niezawodny wydawca może kontynuować generowanie wiadomości, podczas gdy potwierdzenia przestają przychodzić. Niepotwierdzone próbki gromadzą się w historii do momentu osiągnięcia limitów zasobów. Kiedy łączność zostanie przywrócona, przywrócona ścieżka musi jednocześnie przenosić bieżące publikacje, kontrolować ruch i zachować zaległości.

Wybierz głębokość historii spośród liczby próbek, które pozostaną przydatne po ponownym połączeniu. Strumień stanu 20 Hz z użytecznym wiekiem 250 milisekund rzadko potrzebuje kilkudziesięciu próbek ustawionych w kolejce; większość z nich byłaby już nieaktualna. Stan wymienny powinien faworyzować najnowszą próbkę, podczas gdy istotne sekwencje zdarzeń wymagają ograniczonego planu odzyskiwania.

Duże i wiarygodne próbki wymagają dodatkowej kontroli: czy najsłabsza oczekiwana trasa może opróżnić kolejkę bez opóźniania bieżącego ruchu? Dogłębna historia może zmniejszyć natychmiastową utratę danych, ale zwiększa również wykorzystanie pamięci, czas odzyskiwania i prawdopodobieństwo gwałtownego wzrostu ruchu po awarii. Nadmiernie przechowywana historia może powodować rozrywanie buforów, które pogarszają zatory po przywróceniu łączności.

Uważaj na impulsy retransmisji

Niezawodny system DDS wykorzystuje wymianę impulsów i potwierdzeń w celu identyfikacji brakujących próbek i uruchomienia retransmisji. Rzadkie cykle odzyskiwania mogą spowodować kumulację kilku strat, zanim zostaną ponownie przesłane, powodując powstawanie krótkich impulsów przekraczających chwilową pojemność łącza. Okresy pulsu, fragmentacja i interwały retransmisji również ściśle ze sobą współdziałają w stratnych warunkach bezprzewodowych.

Testuj czas retransmisji w oparciu o interwał publikacji każdego tematu, zamiast stosować jedną wartość dla całej floty. Zmierz opóźnienie odzyskiwania, opóźnienie końcowe, jitter, obciążenie pakietu sterującego i obciążenie procesora po każdej zmianie. Szybsza sygnalizacja odzyskiwania może zmniejszyć opóźnienia i rozmiar serii, ale nadmierny ruch kontrolny może zużywać przetwarzanie i przepustowość.

Żadna regulacja taktowania nie jest w stanie uratować bezprzewodowej siatki ROS 2, której stałe oferowane obciążenie przekracza użyteczną wydajność. Gdy łącze pozostaje nasycone, ponowne próby zwiększają ruch na już przeciążonej ścieżce.

Zdecyduj, kiedy zamiast tego zmienić ładunek

Strojenie QoS powinno zakończyć się tam, gdzie architektura aplikacji staje się większym problemem. Jeśli na kanale dominują strumienie wizualne, zmniejsz rozdzielczość obrazu, jakość kodowania lub liczbę klatek na sekundę. Przycinaj lub próbkuj chmury punktów przed transmisją i publikuj ślady obiektów, wyniki przemierzania tras lub aktualizacje map lokalnych, gdy członkowie zespołu nie potrzebują nieprzetworzonych obserwacji.

Obróbka krawędzi często zapewnia najczystsze rozwiązanie. Każdy robot może lokalnie przechowywać dane z czujników o dużej przepustowości i rozpowszechniać tylko te informacje, które są potrzebne do koordynacji. Nie jest to kompromis w zakresie niezawodności DDS; jest to świadoma decyzja o dopasowaniu zapotrzebowania na komunikację do fizycznej wydajności sieci komórkowej.

Przetestuj profil na ruchomych robotach, a nie tylko na stole warsztatowym

Odtwórz trasy i awarie, jakie napotka flota

Stały test jednego przeskoku nie może reprezentować mobilnej siatki bezprzewodowej ROS 2. Walidacja powinna obejmować najkrótszą trasę, maksymalną planowaną liczbę przeskoków, przemieszczanie się pomiędzy pozycjami przekaźników, rosnące zakłócenia, asymetryczny ruch, krótkie i długie przerwy, ponowne połączenie, późne dołączenie i równoczesne publikowanie przez kilka robotów.

Nagraj więcej niż przeciętne opóźnienie. Przydatne pomiary obejmują:

●  Częstotliwość otrzymanych aktualizacji i wskaźnik utraty wiadomości.

●  Wiek wiadomości, średnie opóźnienie, opóźnienie końcowe i fluktuacja.

●  Czas wykrycia lub ponownego połączenia po zmianie ścieżki.

●  Wzrost kolejki zapisu i odczytu podczas przerwy.

●  Czas wymagany do usunięcia przydatnych zatrzymanych danych.

●  Użycie procesora i pamięci zarówno u wydawców, jak i subskrybentów.

Oceń każdy wynik w porównaniu z utworzonym wcześniej budżetem na dostawę. Temat lokalizacji może się nie powieść, ponieważ częstotliwość jego aktualizacji spada poniżej wymagań kontrolnych, nawet jeśli ostatecznie dotrze każda próbka. I odwrotnie, transfer mapy może zakończyć się pomimo większego opóźnienia, jeśli zakończy się w dozwolonym oknie odzyskiwania.

Użyj telemetrii siatki, aby wyjaśnić zachowanie DDS

Metryki ROS 2 ujawniają, czego doświadcza aplikacja, a telemetria mesh pomaga wyjaśnić, dlaczego tak się stało. Porównaj wydajność tematu z liczbą przeskoków, zmianami topologii, siłą sygnału, stosunkiem sygnału do szumu, ruchem wysyłającym i pobierającym oraz czasem zmiany trasy. Korelacja obu warstw uniemożliwia zespołom obwinianie QoS za zmianę ścieżki radiowej lub obwinianie siatki za niezgodne ustawienia wydawcy i subskrybenta.

Moduły WDS MIMOmesh OEM/ODM i lekkie jednostki powietrzne wykorzystują architekturę typu all-IP z rozproszonym, dynamicznym routingiem bez centrum i trybami przekaźnika wieloskokowego. Ich funkcje zarządzania siecią zapewniają informacje o topologii, natężeniu pola, współczynniku SNR, ruchu, odległości węzła i stanie operacyjnym, które inżynierowie mogą porównać z opóźnieniami, stratami i zachowaniem kolejek ROS 2.

Szybkość transmisji danych produktu i wartości opóźnień pojedynczego przeskoku powinny pozostać punktami odniesienia dla planowania, a nie gwarantowaną wydajnością aplikacji. Rzeczywiste kompleksowe zachowanie obejmuje również głębokość trasy, zajętość kanału, odzyskiwanie pakietów, serializację, kolejki oprogramowania pośredniczącego i przetwarzanie węzłów. w ruch siatki bezprzewodowej ROS 2 , zmierzona dobra wydajność na najsłabszej trasie operacyjnej powinna wpłynąć na współczynnik publikacji i ograniczenia historii.

Zmień jedną zmienną na raz

Zacznij od potwierdzenia nazw tematów, typów wiadomości i zgodności z QoS. Testuj wykrywanie oddzielnie od przesyłania danych, ponieważ węzeł, który nigdy nie wykrywa swojego partnera, ma inną awarię niż dopasowany punkt końcowy, który traci pakiety. Zdarzenia niezgodnej QoS mogą pomóc aplikacjom wykryć niezgodności zasad, zamiast pozostawiać awarię niewyjaśnioną.

Ustal powtarzalną trasę i schemat poruszania się, a następnie dostosuj jedną zmienną na każdy bieg. Niezależnie zmieniaj niezawodność, głębokość, trwałość, żywotność, częstotliwość publikacji, rozmiar ładunku lub próg fragmentacji. Powtarzanie tego samego scenariusza pozwala określić, czy wyraźna poprawa wynika ze zmiany QoS, czy z lepszej ścieżki radiowej.

Przed testowaniem ustaw warunki zaliczenia. Przykłady obejmują maksymalny wiek dowódcy, minimalną częstotliwość lokalizacji, maksymalny czas, w którym ponownie łączący się robot otrzyma bieżącą mapę oraz limit czasu usuwania zaległości. Ostateczny profil powinien przejść najsłabszą realistyczną trasę, a nie tylko zapewnić imponujące średnie wyniki na stanowisku testowym.

 

Wniosek

Niezawodna komunikacja flotowa zależy od dopasowania zachowania DDS do celu każdego tematu. Świeże strumienie czujników zwykle wymagają płytkich kolejek typu „best-effort”, podczas gdy zdarzenia misji i ponowne łączenie robotów mogą wymagać ograniczonej niezawodności lub trwałości przejściowo-lokalnej. Fragmentacja, wzrost zaległości i zmierzona wydajność wielu przeskoków powinny ukształtować ostateczny profil.

Zespołom budującym siatkę bezprzewodową ROS 2 firma Shenzhen Sinosun Technology Co., Ltd. oferuje moduły MIMOmesh OEM/ODM i lekkie radia powietrzne do wdrożeń mobilnych z wieloma przeskokami. W połączeniu ze zdyscyplinowanymi testami QoS platformy te mogą pomóc w ograniczeniu przestarzałego ruchu, skróceniu odzyskiwania i utrzymaniu współdzielonej przepustowości skupionej na danych przydatnych operacyjnie.

 

Często zadawane pytania

P: Czy ROS 2 nadaje się do bezprzewodowej komunikacji wielu robotów?

O: Tak, ale łącza bezprzewodowe wymagają ustawień QoS dostosowanych do tematu. Niezawodność, głębokość kolejki, trwałość i szybkość ładowania powinny odzwierciedlać utratę pakietów, opóźnienia, mobilność i dostępną przepustowość.

P: Które ustawienie niezawodności QoS działa najlepiej w przypadku sieci bezprzewodowej ROS 2?

O: Dołóż wszelkich starań, aby zapewnić często odświeżane strumienie czujników i ograniczone, niezawodne dostarczanie poleceń, wydarzeń związanych z misjami, map lub danych konfiguracyjnych, których nie można przegapić.

P: Dlaczego wydawcy i subskrybenci ROS 2 czasami nie mogą się połączyć?

Odp.: Niezgodne zasady QoS mogą uniemożliwiać komunikację. Typowe rozbieżności dotyczą ustawień niezawodności, trwałości, terminu lub żywotności pomiędzy profilem oferowanym przez wydawcę a profilem żądanym przez subskrybenta.

P: Jak należy obsługiwać duże komunikaty LiDAR lub kamery w sieci mesh?

O: Zmniejsz rozmiar ładunku, unikaj fragmentacji IP, ograniczaj częstotliwość publikacji i dbaj o to, aby kolejki były płytkie. Lokalne przetwarzanie lub skompresowane dane wyjściowe często działają lepiej niż przesyłanie każdej nieprzetworzonej próbki czujnika.

P: Z jakiej głębokości historii powinny korzystać zespoły robotów mobilnych?

O: Wybierz głębokość zgodnie z czasem życia wiadomości i potrzebami w zakresie odzyskiwania. Użyj głębokości pierwszej dla stanu wymiennego, podczas gdy istotne zdarzenia mogą wymagać większej, ale ściśle ograniczonej kolejki.