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 и запишете посоката, честотата на съобщенията и условията на връзката. Повторете сравнението два пъти, за да отделите истинско подобрение от щастливо повторно свързване. Ако промяна подобри откриването, а доставката остане същата, сте преместили услугата за запознанства, а не пътя на данните.