Темы 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 на хосте публикатора. Именно этот адрес ваш подписчик вызовет следующим, поэтому он должен быть доступен откуда угодно, где работает подписчик. Если он указывает на интерфейс, который существует только в собственной локальной сети робота, поиск в master проходит успешно, а данные так и не приходят.

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

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

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 робота, чего обычно и хочет удалённый оператор. Если что-то в стеке зависит вместо этого от широковещания или multicast, это требование нужно оценивать отдельно; превращение туннеля в TAP ради одного инструмента расширяет сеть для каждого участника.

Остановитесь здесь, если маршрут или обратный путь отсутствует. У публикатора, который отвечает на своём хосте, но недоступен с рабочей станции, проблема маршрутизации, а не проблема ROS.

Шаг 4: разрешите разговор партнёров и наблюдайте одну тему

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

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

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

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

Похожие статьи