ROS 2 et Interopérabilité DDS : Guide Pratique pour Intégration Seamless

ROS 2 repose sur DDS pour sa couche communication sous-jacente, yet achieving flawless interopérabilité entre un déploiement DDS natif et ROS 2 peut encore poser subtle challenges. Ce guide distille les practical steps et configuration tweaks qui ont proven effective as of the "Bouncy Bolson" (July 2018) ROS 2 release, helping teams avoid common pitfalls et leverage full power de Connext DDS within ROS 2.

Current State of ROS 2

ROS 2 est un framework rapidly evolving, et future releases may introduce additional interopérabilité nuances. Cependant, quand vous run ROS 2 avec le rmw_connext_cpp RMW layer, vous utilisez encore le native Connext DDS stack. Cela signifie vous retenez all de Connext's advanced features – tel que fine-grained QoS control et multi-transport support – tout en profitant des higher-level abstractions de ROS 2.

Key Interoperability Settings

Topic Names & Partitions

ROS 2 encode le namespace d'un topic dans soit le topic name soit la DDS partition. Tous ROS 2 user topics résident dans le namespace "rt" (ROS Topic). En DDS ceci est représenté comme :

Topic Data Types

Quand le Connext RMW layer est actif, ROS 2 advertise every "rt/*" topic avec un generic serialization type. En résultat, une pure DDS application qui publish l'original, strongly-typed data expérimentera un QoS mismatch et ne peut pas connecter.

Le remède le plus straightforward est de suppress l'automatic type-code publication depuis ROS 2 participants. Ajoutez un fichier USER_QOS_PROFILES.xml au directory qui launch vos ROS 2 nodes. Une configuration minimal qui cache le type code et désactive type object sharing ressemble à ceci :

N'hésitez pas à ajuster le reliability setting pour suit votre application ; l'exemple above utilise "Best Effort" comme starting point.

Rappelez-vous que ce QoS file s'applique seulement aux ROS 2 nodes started from the same directory. Si vous avez besoin configurations isolées, placez un dedicated USER_QOS_PROFILES.xml next to each node's launch folder.

Transport Selection

Quand un DDS system et un ROS 2 system partagent le même network, warnings about missing ou unsupported transports (ex: udpv6 not available sur participant qui only supports udpv4) peuvent apparaître. Pour éviter tels warnings et assurer connectivité fiable, configurez transport preferences explicitly.

1. Define the allowed transports dans USER_QOS_PROFILES.xml en ajoutant un <transport_builtin> mask inside <participant_qos> :

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

2. Créez un fichier NDDS_DISCOVERY_PEERS dans le launch directory et listez les peer addresses vous souhaitez discover. Exemple comma-separated qui désactive multicast discovery :

localhost,192.168.1.12,shmem:// 

Choosing the RMW Layer in ROS 2

Always set the RMW_IMPLEMENTATION environment variable à rmw_connext_cpp before starting ROS 2 nodes :

export RMW_IMPLEMENTATION=rmw_connext_cpp 

Ou passez-le inline quand launching a node :

RMW_IMPLEMENTATION=rmw_connext_cpp ros2 run demo_nodes_cpp talker 

Unbounded Sequences & Strings

Quelques ROS 2 topics contiennent unbounded sequences ou strings. Si votre DDS application needs to consume ou publish these topics, enable "Unbounded Support" dans le DDS code generator. Référez-vous à la documentation RTI pour how to toggle this option during code generation.

Next Steps with RTI

Nous couvrirons un temporary gap dans le current ROS 2 feature set – record et replay de topic data – dans le next installment de cette series. En attendant, si vous êtes ready to deploy a robust, DDS-backed ROS 2 solution, reach out to our RTI experts. Nous vous aiderons à fine-tune votre configuration et accelerate time-to-market.