ROS 2 через VPN: виявлення — не шлях даних

Два вузли ROS 2 на протилежних кінцях VPN можуть перелічувати теми одне одного й усе ж не доставити жодного повідомлення. Виявлення та дані користувача — це окремі обміни з окремими шляхами, а сервер виявлення не передає корисне навантаження. Перевірити одне й припустити інше — так команди починають змінювати проміжне програмне забезпечення, хоча тунель просто ніколи не переносив дані. Процедура нижче розділяє два результати, перш ніж щось буде замінено.

Що насправді переносить сервер виявлення

У Fast DDS Discovery Server поширює відомості про кінцеві точки: хто публікує, хто підписується і якого QoS очікує кожен. Коли партнери знають одне одного, дані користувача йдуть безпосередньо між ними, а не через цей сервер. Досягнення сервера доводить, що посередник знайомств відповідає, і не більше. Маршрутизованому VPN усе ще потрібен робочий шлях в обох напрямках між адресами, які оголошують партнери.

Ця відмінність також пояснює часткові збої, коли наявні партнери продовжують обмінюватися даними, а нове виявлення перестає працювати. Розглядайте їх як два окремі розслідування.

Прочитайте RMW, який вузли насправді використовують

ROS 2 може завантажувати різне проміжне програмне забезпечення, і змінна, експортована у вашій оболонці, не доходить до процесів, запущених в іншому місці. Питайте працюючу систему, а не історію термінала.

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

Незадана змінна зазвичай означає встановлене значення за замовчуванням, яке може відрізнятися між машинами в одному експерименті. Звіт також називає дистрибутив і використовуване проміжне програмне забезпечення, тому порівняйте їх з обох боків тунелю, перш ніж припускати збіг. Демон командного рядка ROS кешує стан, тому перезапустіть його після зміни середовища, а не дозволяйте застарілому демону відповідати за стару конфігурацію. Запишіть дистрибутив і RMW обох хостів у нотатки тесту, поки сеанс відкритий.

Перевірте виявлення й дані як два результати

Виберіть нешкідливу тему й вимірюйте знайомство окремо від доставки. Команда info перелічує кінцеві точки та QoS, а echo доводить, чи справді одне повідомлення перетинає канал.

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

Поява кінцевих точок у виводі info — це результат виявлення. Прибуття повідомлення до підписника — результат транспорту, і лише другий перевіряє шлях, потрібний застосунку. Коли виявлення працює, а echo вичерпує час, досліджуйте оголошені адреси та зворотний маршрут, а не службу виявлення. Запускайте обидві команди з кожного хоста, бо асиметричний маршрут VPN часто виявляється лише з одного боку.

Змінюйте одну залежність за раз

Коли шлях даних не працює, уникайте зміни проміжного програмного забезпечення, режиму виявлення та розміру повідомлення в одному сеансі, оскільки після цього жоден результат не можна буде віднести до причини. Zenoh RMW — законна альтернатива, але його маршрутизатор стає ще однією залежністю, яка має бути доступною через тунель.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

За цього RMW маршрутизатор несе виявлення у стандартній схемі Jazzy, а багатоадресне виявлення там вимкнено, тому залежність належить до ваших нотаток, а не до припущення, запозиченого з іншого проміжного програмного забезпечення. Тримайте робоче навантаження незмінним, поки змінюєте одне налаштування, потім повторіть тест echo і запишіть напрямок, частоту повідомлень і умови каналу. Повторіть порівняння двічі, щоб відокремити реальне покращення від щасливого перепідключення. Якщо зміна покращує виявлення, а доставка залишається такою самою, ви перемістили службу знайомств, а не шлях даних.