Теми на ROS 1 през VPN: следвайте обявената крайна точка

Регистрацията в master на ROS 1 не пренася данни за теми. Прочетете обявения URI на възела, направете този адрес маршрутизируем и след това разрешете порта на публикуващия.

Работната ви станция достига master на ROS 1 през тунела и все още показва празен списък с теми. Този модел е често срещан, защото регистрацията в master и преносът на теми са два различни разговора и само първият минава през master. Контролният списък по-долу проследява втория разговор: крайната точка, която публикуващият обявява, адресът, до който абонатът трябва да достигне, и разрешението, което позволява на двойката да говори. Всичко тук е ограничено до стария ROS 1, чийто прозорец за поддръжка на Noetic приключи през май 2025 г.

Стъпка 1: докажете, че връзката с master не е връзката с темата

Започнете, като отделите работещото от неработещото. Успешният rostopic list доказва, че вашата обвивка достига порта XMLRPC на master и че master знае за теми; той не казва нищо за това дали абонатът може да достигне до публикуващия. Трите команди по-долу правят разликата видима и всички те са само за четене.

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

Изходът на rostopic info посочва URI на възела на публикуващия, който е адрес XMLRPC на хоста на публикуващия. Този адрес е този, който вашият абонат ще извика след това, затова трябва да е достъпен отвсякъде, където работи абонатът. Ако той сочи към интерфейс, който съществува само в LAN на самия робот, търсенето в master успява, а данните никога не пристигат.

Стъпка 2: прочетете обявената крайна точка от самия възел

ROS 1 избира обявената си идентичност на хост от ROS_IP или ROS_HOSTNAME, когато един от тях е зададен, и в противен случай се връща към собственото разрешаване на имена на хоста. Прегледайте средата на процеса, който действително е стартиран, защото systemd unit, контейнер или втори терминал могат да носят различна стойност от обвивката, в която тестът ви е проработил.

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

Обявяването на име на хост работи само ако всеки партньор разрешава това име до предвидения достъпен адрес. Ако това име се разрешава само вътре в собствената мрежа на робота, работна станция от другата страна на тунела няма как да го използва, а VPN, който не изтласква DNS суфикс, прави несъответствието още по-лошо. Задаването на ROS_IP на адреса на тунела е по-малката промяна, когато топологията е маршрутизирана. Кое и да изберете, запишете го за двата края, защото публикуващ и абонат, които не са съгласни за идентичността, ще преговарят и след това няма да се свържат.

Спрете тук, ако обявеният URI използва адрес, до който никой партньор не може да маршрутизира. Никаква работа по защитната стена няма да поправи име, което се разрешава до грешния интерфейс.

Стъпка 3: направете обявения адрес разрешим и маршрутизиран

С URI в ръка тествайте достъпността от хоста на абоната, а не от робота. Портът TCPROS се избира по време на преговорите, така че полезният ранен тест е портът XMLRPC, а полезният по-късен тест е установеният сокет. Маршрут, който съществува само в една посока, е честа повреда при маршрутизирани VPN и обратният път е също толкова важен, колкото и пътят напред.

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

Маршрутизираният интерфейс TUN пренася тези IP разговори, без да разширява Ethernet сегмента на робота, което обикновено е това, което иска отдалечен оператор. Ако нещо в стека зависи вместо това от broadcast или multicast, това изискване трябва да се оцени самостоятелно; превръщането на тунела в TAP, за да се удовлетвори един инструмент, разширява мрежата за всеки участник.

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

Стъпка 4: разрешете разговора между партньорите и наблюдавайте една тема

Отворете само портовете, които са нужни на договорения разговор, и ограничете всяко правило до обявените участници. Слушателят на master не е ретранслатор за полезния товар на темите, затова разрешаването само на него оставя крайната точка на публикуващия затворена. Дръжте слушателите на ROS на границата на частния VPN, вместо да ги излагате на публичния интернет.

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

Наблюдавайте една безобидна тема от истинския публикуващ до истинския абонат и потвърдете както обявената крайна точка, така и пътя на отговора. Едно съобщение доказва, че пътят работи; стабилната честота доказва, че остава отворен. Дръжте управлението на задвижването и проверките за безопасност извън този тест само за мрежата, защото работеща тема не удостоверява работещ робот. Запишете версията на ROS и двойката крайни точки, които наблюдавахте, за да може следващият човек да различи промяна в топологията от регресия.

Контролният списък е завършен, когато обявеният URI е достъпен от абоната, договореният порт е отворен само за този партньор, една обявена тема тече и стойностите на средата са записани за двата хоста. Старият ROS 1 няма да получава поправки в тази област, така че записът е частта, която продължава да работи, след като хората се сменят.

Подобни статии