ROS 2 преку VPN: откривањето не е патеката на податоци

Два ROS 2 јазли на спротивните краеви на VPN можат да ги наведат темите на другиот и сепак да не достават ниту една порака. Откривањето и корисничките податоци се одделни размени со одделни патеки, а серверот за откривање не го пренесува корисниот товар. Проверката на едното и претпоставката за другото е причината зошто тимовите го заменуваат middleware-от кога тунелот едноставно никогаш не ги пренел податоците. Постапката подолу ги раздвојува двата резултати пред нешто да се замени.

Што всушност пренесува серверот за откривање

Во Fast DDS Discovery Server дистрибуира информации за крајните точки: кој објавува, кој се претплатува и каков QoS очекува секој. Откако партнерите ќе се запознаат, корисничките податоци патуваат директно меѓу нив, а не преку тој сервер. Доаѓањето до серверот докажува дека посредникот на запознавањата одговара, и ништо повеќе. Рутираниот VPN сѐ уште бара работна патека во двете насоки меѓу адресите што ги објавуваат партнерите.

Оваа разлика ги објаснува и делумните дефекти, каде постоечките партнери продолжуваат да разменуваат податоци додека новото откривање престанува да работи. Третирајте ги како две одделни истраги.

Прочитајте го RMW што јазлите навистина го користат

ROS 2 може да вчита различен middleware, а променливата извезена во вашата обвивка не стигнува до процесите стартувани на друго место. Прашајте го системот што работи, а не историјата на терминалот.

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

Непоставена променлива обично значи инсталираната стандардна вредност, која може да се разликува меѓу машините во истиот експеримент. Извештајот исто така ја наведува дистрибуцијата и middleware-от што се користат, па споредете ги од двете страни на тунелот пред да претпоставите дека се совпаѓаат. Демонот на командната линија на ROS кешира состојба, па рестартирајте го по промена на околината наместо да дозволите застарен демон да одговара за старата конфигурација. Запишете ја дистрибуцијата и RMW-то на двата хоста во белешките за тестот додека сесијата е отворена.

Тестирајте го откривањето и податоците како два резултата

Изберете безопасна тема и мерете го запознавањето одделно од испораката. Командата info ги наведува крајните точки и QoS, додека echo докажува дали една порака навистина ја преминува врската.

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

Појавувањето на крајни точки во излезот на info е резултат на откривањето. Пристигнувањето на порака кај претплатникот е транспортен резултат, и само вториот ја испитува патеката што му е потребна на апликацијата. Кога откривањето работи, а echo истекува, проверете ги објавените адреси и повратната рута наместо услугата за откривање. Извршете ги двете команди од секој хост, бидејќи асиметричната VPN рута често се открива само од едната страна.

Менувајте една зависност одеднаш

Кога патеката на податоците не успее, избегнувајте да менувате middleware, режим на откривање и големина на пораката во истата сесија, бидејќи потоа ниеден резултат не може да се припише. Zenoh RMW е легитимна алтернатива, но неговиот рутер станува уште една зависност што мора да биде достапна преку тунелот.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Под тој RMW рутерот го носи откривањето во стандардниот распоред на Jazzy, а multicast откривањето е оневозможено таму, па зависноста припаѓа во вашите белешки, а не во претпоставка позајмена од друг middleware. Држете го работното оптоварување фиксно додека менувате една поставка, потоа повторете го тестот echo и запишете насока, брзина на пораки и услови на врската. Повторете ја споредбата двапати за да го одвоите вистинското подобрување од среќно повторно поврзување. Ако промената го подобри откривањето додека испораката останува иста, сте ја преместиле услугата за запознавање, а не патеката на податоците.