À propos des différents fournisseurs ROS 2 DDS/RTPS

ROS 2 est construit sur DDS/RTPS en tant que middleware, qui fournit la découverte, la sérialisation et le transport. Cet article explique en détail la motivation derrière l’utilisation des implémentations DDS et/ou du protocole filaire RTPS de DDS. En résumé, DDS est un middleware de bout en bout qui fournit des fonctionnalités pertinentes pour les systèmes ROS, telles que la découverte distribuée (non centralisée comme dans ROS 1) et le contrôle de différentes options de « qualité de service » pour le transport.

DDS est une norme de l’industrie qui est mise en œuvre par une gamme de fournisseurs, tels que Connext DDS, Fast DDS d’eProsima, `Cyclone DDS d'Eclipse <https://projects.eclipse.org/projects/iot.cyclonedds >`__, ou GurumDDS de GurumNetworks. RTPS (alias DDSI-RTPS) est le protocole filaire utilisé par DDS pour communiquer sur le réseau.

ROS 2 prend en charge plusieurs implémentations DDS/RTPS car il n’est pas nécessairement « taille unique » lorsqu’il s’agit de choisir un fournisseur/une implémentation. De nombreux facteurs peuvent être pris en compte lors du choix d’une implémentation de middleware : des considérations logistiques telles que la licence ou des considérations techniques telles que la disponibilité de la plate-forme ou l’empreinte de calcul. Les fournisseurs peuvent proposer plusieurs implémentations DDS ou RTPS visant à répondre à différents besoins. Par exemple, RTI a quelques variantes de leur implémentation Connext qui varient dans leur objectif, comme une qui cible spécifiquement les microcontrôleurs et une autre qui cible les applications nécessitant des certifications de sécurité spéciales (nous ne prenons en charge que leur version de bureau standard pour le moment).

Afin d’utiliser une implémentation DDS/RTPS avec ROS 2, une interface « ROS Middleware » (a.k.a. rmw interface ou simplement rmw) doit être créé pour implémenter l’interface abstraite du middleware ROS à l’aide de l’API et des outils de l’implémentation DDS ou RTPS. L’implémentation et la maintenance des packages RMW pour la prise en charge des implémentations DDS demandent beaucoup de travail, mais la prise en charge d’au moins quelques implémentations est importante pour garantir que la base de code ROS 2 n’est pas liée à une implémentation particulière, car les utilisateurs peuvent souhaiter changer d’implémentation. sur les besoins de leur projet.

Implémentations RMW prises en charge

Nom du produit

Licence

Mise en œuvre de la RMW

Statut

eProsima Fast DDS

Apache 2

rmw_fastrtps_cpp

Plein soutien. RMW par défaut. Emballé avec des versions binaires.

Éclipse Cyclone DDS

Licence publique Eclipse v2.0

rmw_cyclonedds_cpp

Plein soutien. Emballé avec des versions binaires.

RTI Connecter DDS

commerciale, de recherche

rmw_connextdds

Plein soutien. Prise en charge incluse dans les fichiers binaires, mais Connext installé séparément.

GurumNetworks GurumDDS

commercial

``rmw_gurumds_cp””

Soutien communautaire. Prise en charge incluse dans les fichiers binaires, mais GurumDDS installé séparément.

Pour des informations pratiques sur l’utilisation de plusieurs implémentations RMW, consultez le didacticiel « Working with multiple RMW implementations ».

Plusieurs implémentations RMW

Les versions binaires ROS 2 pour les distributions actuellement actives ont un support intégré pour plusieurs implémentations RMW prêtes à l’emploi (Fast DDS, RTI Connext Pro, Eclipse Cyclone DDS, GurumNetworks GurumDDS). La valeur par défaut est Fast DDS, qui fonctionne sans aucune étape d’installation supplémentaire car nous la distribuons avec nos packages binaires.

D’autres RMW comme Cyclone DDS, Connext ou GurumDDS peuvent être activés en installant des packages supplémentaires, mais sans avoir à reconstruire quoi que ce soit ou à remplacer les packages existants.

Un espace de travail ROS 2 créé à partir de la source peut créer et installer plusieurs implémentations RMW simultanément. Pendant la compilation du code ROS 2 principal, toute implémentation RMW trouvée sera construite si l’implémentation DDS/RTPS appropriée a été installée correctement et si les variables d’environnement appropriées ont été configurées. Par exemple, si le code du package RMW pour RTI Connext DDS est dans l’espace de travail, il sera construit si une installation de Connext Pro de RTI peut également être trouvée .

Dans de nombreux cas, vous constaterez que les nœuds utilisant différentes implémentations RMW sont capables de communiquer, mais ce n’est pas vrai dans toutes les circonstances. Voici une liste des configurations de communication inter-fournisseurs qui ne sont pas prises en charge :

  • DDS rapide <-> Connexion

    • WString publié par Fast DDS ne peut pas être reçu correctement par Connext sur macOS

  • Connext <-> Cyclone DDS

    • ne prend pas en charge la communication pub/sub pour WString

Implémentation RMW par défaut

Si un espace de travail ROS 2 a plusieurs implémentations RMW, Fast DDS est sélectionné comme implémentation RMW par défaut si elle est disponible. Si l’implémentation Fast DDS RMW n’est pas installée, l’implémentation RMW avec le premier identifiant d’implémentation RMW dans l’ordre alphabétique sera utilisée. L’identifiant d’implémentation est le nom du package ROS qui fournit l’implémentation RMW, par ex. rmw_cyclonedds_cpp. Par exemple, si les deux packages ROS rmw_cyclonedds_cpp et rmw_connextdds sont installés, rmw_connextdds serait la valeur par défaut. Si rmw_fastrtps_cpp est installé, ce serait la valeur par défaut.

Consultez le guide pour savoir comment spécifier quelle implémentation RMW doit être utilisée lors de l’exécution des exemples ROS 2.