ROS 2 printr-o VPN: descoperirea nu este calea datelor

Două noduri ROS 2 la capete opuse ale unei VPN pot lista subiectele celuilalt și totuși nu pot livra niciun mesaj. Descoperirea și datele utilizatorului sunt schimburi separate cu căi separate, iar un server de descoperire nu retransmite încărcăturile. Verificarea uneia și presupunerea celeilalte este modul în care echipele ajung să înlocuiască middleware-ul când tunelul pur și simplu nu a transportat niciodată datele. Procedura de mai jos separă cele două rezultate înainte de a schimba ceva.

Ce transportă de fapt serverul de descoperire

În Fast DDS, un Discovery Server distribuie informații despre punctele terminale: cine publică, cine se abonează și ce QoS așteaptă fiecare. După ce partenerii se cunosc, datele utilizatorului călătoresc direct între ei, nu prin acel server. A ajunge la server dovedește că intermediarul prezentărilor răspunde, și nimic mai mult. O VPN rutată are în continuare nevoie de o cale funcțională în ambele direcții între adresele pe care partenerii le anunță.

Această distincție explică și eșecurile parțiale, în care partenerii existenți continuă să facă schimb de date în timp ce descoperirea nouă nu mai funcționează. Tratați-le ca două investigații.

Citiți RMW-ul pe care nodurile îl folosesc cu adevărat

ROS 2 poate încărca middleware diferit, iar o variabilă exportată în shell-ul dvs. nu ajunge la procesele pornite în altă parte. Întrebați sistemul care rulează, nu istoricul terminalului.

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

O variabilă nesetată înseamnă de obicei valoarea implicită instalată, care poate diferi între mașinile din același experiment. Raportul numește și distribuția și middleware-ul utilizate, așa că comparați-le pe ambele părți ale tunelului înainte de a presupune că se potrivesc. Daemonul liniei de comandă ROS memorează starea în cache, așa că reporniți-l după ce schimbați mediul în loc să lăsați un daemon învechit să răspundă pentru configurația veche. Notați distribuția și RMW-ul ambelor gazde în notele testului cât timp sesiunea este deschisă.

Testați descoperirea și datele ca două rezultate

Alegeți un subiect inofensiv și măsurați prezentarea separat de livrare. Comanda info listează punctele terminale și QoS, în timp ce echo dovedește dacă un mesaj traversează într-adevăr legătura.

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

Apariția punctelor terminale în ieșirea info este un rezultat al descoperirii. Sosirea unui mesaj la abonat este un rezultat al transportului, și doar al doilea testează calea de care are nevoie aplicația. Când descoperirea funcționează și echo expiră, inspectați adresele anunțate și ruta de întoarcere în locul serviciului de descoperire. Rulați ambele comenzi de pe fiecare gazdă, deoarece o rută VPN asimetrică se dezvăluie adesea doar dintr-o parte.

Schimbați o singură dependență o dată

Când calea datelor eșuează, evitați să modificați middleware-ul, modul de descoperire și dimensiunea mesajelor în aceeași sesiune, deoarece după aceea niciun rezultat nu mai poate fi atribuit. RMW Zenoh este o alternativă legitimă, dar routerul său devine o altă dependență care trebuie să fie accesibilă prin tunel.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

În acel RMW, routerul transportă descoperirea în aranjamentul implicit Jazzy, iar descoperirea multicast este dezactivată acolo, așa că dependența aparține notițelor dvs. și nu unei presupuneri împrumutate de la alt middleware. Păstrați sarcina de lucru fixă în timp ce schimbați o setare, apoi repetați testul echo și notați direcția, rata mesajelor și condițiile legăturii. Repetați comparația de două ori pentru a separa o îmbunătățire reală de o reconectare norocoasă. Dacă o modificare îmbunătățește descoperirea în timp ce livrarea rămâne aceeași, ați mutat serviciul de prezentare, nu calea datelor.