ROS 2 VPN-en át: a felderítés nem az adatút

Két ROS 2 csomópont a VPN ellentétes végein listázhatja egymás témáit, és mégsem továbbít egyetlen üzenetet sem. A felderítés és a felhasználói adatok külön cserék, külön utakkal, és egy felderítési kiszolgáló nem továbbít hasznos terhelést. Az egyik ellenőrzése és a másik feltételezése az, ahogy a csapatok végül lecserélik a middleware-t, amikor az alagút egyszerűen soha nem szállította az adatokat. Az alábbi eljárás szétválasztja a két eredményt, mielőtt bármit lecserélnének.

Amit a felderítési kiszolgáló valójában szállít

A Fast DDS-ben a Discovery Server a végpontokról terjeszt információt: ki tesz közzé, ki iratkozik fel, és milyen QoS-t vár el mindegyik. Miután a partnerek tudnak egymásról, a felhasználói adatok közvetlenül közöttük utaznak, nem azon a kiszolgálón keresztül. A kiszolgáló elérése azt bizonyítja, hogy a bemutatkozások közvetítője válaszol, és semmi többet. Az útválasztott VPN-nek továbbra is szüksége van működő útra mindkét irányban a partnerek által hirdetett címek között.

Ez a megkülönböztetés a részleges hibákat is megmagyarázza, amikor a meglévő partnerek továbbra is cserélnek adatokat, miközben az új felderítés leáll. Kezelje ezeket két külön vizsgálatként.

Olvassa ki az RMW-t, amelyet a csomópontok valóban használnak

A ROS 2 különböző middleware-eket tölthet be, és a héjban exportált változó nem ér el máshol indított folyamatokat. A futó rendszert kérdezze, ne a terminál előzményeit.

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

A be nem állított változó általában a telepített alapértelmezést jelenti, amely ugyanazon kísérlet gépei között eltérhet. A jelentés a használt disztribúciót és middleware-t is megnevezi, ezért hasonlítsa össze őket az alagút mindkét oldalán, mielőtt feltételezi, hogy megegyeznek. A ROS parancssori démonja gyorsítótárazza az állapotot, ezért indítsa újra a környezet módosítása után, ahelyett hogy egy elavult démon válaszolna a régi konfigurációért. Jegyezze fel mindkét gazdagép disztribúcióját és RMW-jét a tesztjegyzetekbe, amíg a munkamenet nyitva van.

Tesztelje a felderítést és az adatokat két eredményként

Válasszon egy ártalmatlan témát, és mérje a bemutatkozást külön a kézbesítéstől. Az info parancs felsorolja a végpontokat és a QoS-t, míg az echo bizonyítja, hogy egy üzenet tényleg átkel-e a kapcsolaton.

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

Az, hogy a végpontok megjelennek az info kimenetében, felderítési eredmény. Az, hogy egy üzenet megérkezik az előfizetőhöz, szállítási eredmény, és csak a második gyakorolja azt az utat, amelyre az alkalmazásnak szüksége van. Amikor a felderítés működik, és az echo időtúllépést ad, vizsgálja meg a hirdetett címeket és a visszautat a felderítési szolgáltatás helyett. Mindkét parancsot futtassa minden gazdagépről, mert az aszimmetrikus VPN-útvonal gyakran csak az egyik oldalról fedi fel magát.

Egy időben egy függőséget változtasson

Amikor az adatút meghibásodik, kerülje a middleware, a felderítési mód és az üzenetméret megváltoztatását ugyanabban a munkamenetben, mert utána semmilyen eredmény nem tulajdonítható. A Zenoh RMW legitim alternatíva, de az útválasztója még egy függőséggé válik, amelynek elérhetőnek kell lennie az alagúton át.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Ezen RMW alatt az útválasztó viszi a felderítést a Jazzy alapértelmezett elrendezésében, és a multicast felderítés ott le van tiltva, ezért a függőség a jegyzeteibe tartozik, nem egy másik middleware-től kölcsönzött feltételezésbe. Tartsa a számítási terhelést rögzítve, miközben egy beállítást módosít, majd ismételje meg az echo tesztet, és jegyezze fel az irányt, az üzenetsebességet és a kapcsolat feltételeit. Kétszer futtassa az összehasonlítást, hogy a valódi javulást elválassza egy szerencsés újracsatlakozástól. Ha egy változtatás javítja a felderítést, miközben a kézbesítés változatlan marad, akkor a bemutatkozási szolgáltatást mozdította el, nem az adatutat.