ROS 2 и DDS интероперабельность: практическое руководство для бесшовной интеграции

ROS 2 полагается на DDS для своего базового коммуникационного слоя, однако достижение безупречной интероперабельности между нативным DDS-развертыванием и ROS 2 может все еще ставить тонкие вызовы. Это руководство дистиллирует практические шаги и конфигурационные твики, которые доказали свою эффективность по состоянию на «Bouncy Bolson» (июль 2018) ROS 2 релиз, помогая командам избегать общих подводных камней и использовать полную мощь Connext DDS внутри ROS 2.

Текущее состояние ROS 2

ROS 2 — быстро эволюционирующий фреймворк, и будущие релизы могут ввести дополнительные нюансы интероперабельности. Однако, когда вы запускаете ROS 2 с rmw_connext_cpp RMW-слоем, вы все еще используете нативный стек Connext DDS. Это означает, что вы сохраняете все передовые функции Connext — такие как гранулярный QoS-контроль и мульти-транспортная поддержка — наслаждаясь высшими абстракциями ROS 2.

Ключевые настройки интероперабельности

Имена топиков и партиции

ROS 2 кодирует неймспейс топика либо в имени топика, либо в DDS-партиции. Все пользовательские топики ROS 2 находятся в неймспейсе «rt» (ROS Topic). В DDS это представлено как:

Типы данных топиков

Когда Connext RMW слой активен, ROS 2 анонсирует каждый «rt/*» топик с общим типом сериализации. В результате, чистое DDS-приложение, публикующее оригинальный, строго-типизированный данные, будет испытывать QoS mismatch и не сможет подключиться.

Самое прямое решение — подавить автоматическую публикацию type-code от ROS 2 участников. Добавьте файл USER_QOS_PROFILES.xml в директорию, запускающую ваши ROS 2 узлы. Минимальная конфигурация, скрывающая type code и отключающая sharing type object, выглядит так:

Не стесняйтесь настраивать настройку надежности под ваше приложение; пример выше использует «Best Effort» как отправную точку.

Помните, что этот QoS-файл применяется только к ROS 2 узлам, запущенным из той же директории. Если нужны изолированные конфигурации, поместите посвященный USER_QOS_PROFILES.xml рядом с каждой папкой запуска узла.

Выбор транспорта

Когда DDS-система и ROS 2-система делят одну сеть, предупреждения о отсутствующих или неподдерживаемых транспортах (например, udpv6 недоступен на участнике, поддерживающем только udpv4) могут появляться. Чтобы избежать таких предупреждений и обеспечить надежную связность, конфигурируйте транспортные предпочтения явно.

1. Определите разрешенные транспорты в USER_QOS_PROFILES.xml добавлением <transport_builtin> маски внутри <participant_qos>:

<participant_qos> <transport_builtin> <mask>UDPV4|SHMEM</mask> </transport_builtin> </participant_qos> 

2. Создайте файл NDDS_DISCOVERY_PEERS в директории запуска и перечислите адреса пиров, которые вы хотите обнаружить. Запятая-разделенный пример, отключающий multicast discovery:

localhost,192.168.1.12,shmem:// 

Выбор RMW-слоя в ROS 2

Всегда устанавливайте переменную окружения RMW_IMPLEMENTATION в rmw_connext_cpp перед запуском ROS 2 узлов:

export RMW_IMPLEMENTATION=rmw_connext_cpp 

Или передайте её инлайн при запуске узла:

RMW_IMPLEMENTATION=rmw_connext_cpp ros2 run demo_nodes_cpp talker 

Неограниченные последовательности и строки

Некоторые ROS 2 топики содержат неограниченные последовательности или строки. Если ваше DDS-приложение должно потреблять или публиковать эти топики, включите «Unbounded Support» в генераторе DDS кода. Обратитесь к документации RTI для того, как переключить эту опцию во время генерации кода.

Следующие шаги с RTI

Мы покроем временный пробел в текущем наборе функций ROS 2 — запись и воспроизведение данных топика — в следующей части этой серии. Тем временем, если вы готовы развернуть надежное, DDS-подкрепленное ROS 2 решение, обратитесь к нашим RTI экспертам. Мы поможете вам тонко настроить вашу конфигурацию и ускорить time-to-market.