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