Utilisation de Fast DDS Discovery Server comme protocole de découverte [contribution de la communauté]
Objectif : Ce didacticiel montre comment lancer les nœuds ROS 2 à l’aide du protocole de découverte Fast DDS Discovery Server.
Niveau du didacticiel : Avancé
Durée : 20 minutes
Table des matières
Arrière-plan
À partir de ROS 2 Eloquent Elusor, le protocole Fast DDS Discovery Server est une fonctionnalité qui offre un mécanisme de découverte dynamique centralisé, par opposition au mécanisme distribué utilisé par défaut dans DDS. Ce didacticiel explique comment exécuter certains exemples ROS 2 à l’aide de la fonctionnalité Fast DDS Discovery Server en tant que communication de découverte.
Afin d’obtenir plus d’informations sur la configuration de découverte disponible, veuillez consulter la documentation suivante ou lisez la Documentation spécifique au serveur Fast DDS Discovery.
Le Simple Discovery Protocol est le protocole standard défini dans le standard DDS. Cependant, il présente des inconvénients connus dans certains scénarios.
Il ne s’adapte pas efficacement, car le nombre de paquets échangés augmente considérablement à mesure que de nouveaux nœuds sont ajoutés.
Il nécessite des capacités de multidiffusion qui peuvent ne pas fonctionner de manière fiable dans certains scénarios, par ex. Wifi.
Le Fast DDS Discovery Server fournit une architecture client-serveur qui permet aux nœuds de se connecter les uns aux autres à l’aide d’un serveur intermédiaire. Chaque nœud fonctionne comme un * client de découverte *, partageant ses informations avec un ou plusieurs * serveurs de découverte * et recevant des informations de découverte de celui-ci. Cela réduit le trafic réseau lié à la découverte et ne nécessite pas de capacités de multidiffusion.
Ces serveurs de découverte peuvent être indépendants, dupliqués ou connectés entre eux afin de créer une redondance sur le réseau et éviter d’avoir un point de défaillance unique.
Serveur de découverte DDS rapide v2
La dernière version de ROS 2 Foxy Fitzroy (décembre 2020) comprenait une nouvelle version, la version 2 du Fast DDS Discovery Server. Cette version inclut une nouvelle fonctionnalité de filtrage qui réduit davantage le nombre de messages de découverte envoyés. Cette version utilise le sujet des différents nœuds pour décider si deux nœuds souhaitent communiquer, ou s’ils peuvent être laissés sans correspondance (c’est-à-dire ne pas se découvrir). La figure suivante montre la diminution des messages de découverte :
Cette architecture réduit considérablement le nombre de messages envoyés entre le serveur et les clients. Dans le graphique suivant, la réduction du trafic réseau au cours de la phase de découverte pour la démonstration RMF Clinic est indiquée :
Afin d’utiliser cette fonctionnalité, le serveur de découverte peut être configuré à l’aide de la Configuration XML pour les participants. Il est également possible de configurer le serveur de découverte à l’aide de l’outil fastdds <https://fast-dds.docs.eprosima.com/en/v2.1.0/fastddscli/cli/cli.html#discovery> __ et une variable d’environnement, qui est l’approche utilisée dans ce tutoriel. Pour une explication plus détaillée sur la configuration du serveur de découverte, consultez la documentation du serveur Fast DDS Discovery <https://fast-dds.docs.eprosima.com/en/v2.1.0/fastdds/discovery/discovery_server.html# découverte-serveur>`__.
Conditions préalables
Ce tutoriel suppose que vous avez un ROS 2 Foxy (ou plus récent) installation. Si votre installation utilise une version de ROS 2 inférieure à Foxy, vous ne pouvez pas utiliser l’outil fastdds. Ainsi, afin d’utiliser le serveur de découverte, vous pouvez mettre à jour votre référentiel pour utiliser une version différente de Fast DDS, ou configurer le serveur de découverte à l’aide de la configuration Fast DDS XML QoS.
Exécutez ce didacticiel
La démo talker-listener ROS 2 crée un nœud talker qui publie un message « hello world » toutes les secondes, et un nœud listener qui écoute ces messages.
En sourcing ROS 2 vous aurez accès à l’outil CLI fastdds. Cet outil donne accès à l”outil de découverte, qui peut être utilisé pour lancer un serveur de découverte. Ce serveur gérera le processus de découverte pour les nœuds qui s’y connectent.
Important
N’oubliez pas de source ROS 2 dans chaque nouveau terminal ouvert.
Configurer le serveur de découverte
Commencez par lancer un serveur de découverte avec l’id 0, le port 11811 (port par défaut) et en écoutant sur toutes les interfaces disponibles.
Ouvrez un nouveau terminal et exécutez :
fastdds discovery --server-id 0
Lancer le nœud d’écoute
Exécutez la démo de l’écouteur, pour écouter le sujet /chatter.
Dans un nouveau terminal, définissez la variable d’environnement ROS_DISCOVERY_SERVER sur l’emplacement du serveur de découverte. (N’oubliez pas de sourcer ROS 2 dans chaque nouveau terminal)
export ROS_DISCOVERY_SERVER=127.0.0.1:11811
Lancez le nœud d’écoute. Utilisez l’argument --remap __node:=listener_discovery_server pour changer le nom du nœud pour ce tutoriel.
ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_discovery_server
Cela créera un nœud ROS 2, qui créera automatiquement un client pour le serveur de découverte et se connectera au serveur créé précédemment pour effectuer la découverte, plutôt que d’utiliser la multidiffusion.
Lancer le nœud de locuteur
Ouvrez un nouveau terminal et définissez la variable d’environnement ROS_DISCOVERY_SERVER comme précédemment afin que le nœud démarre un client de découverte.
export ROS_DISCOVERY_SERVER=127.0.0.1:11811
ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_discovery_server
Vous devriez maintenant voir le locuteur publier des messages « hello world », et l’auditeur recevoir ces messages.
Démontrer l’exécution de Discovery Server
Jusqu’à présent, rien ne prouve que cet exemple et l’exemple standard de locuteur-auditeur fonctionnent différemment. Pour le démontrer clairement, exécutez un autre nœud qui n’est pas connecté au serveur de découverte. Exécutez un nouvel écouteur (écoute dans le sujet /chatter par défaut) dans un nouveau terminal et vérifiez qu’il n’est pas connecté au talker déjà en cours d’exécution.
ros2 run demo_nodes_cpp listener --ros-args --remap __node:=simple_listener
Le nouveau nœud d’écoute ne devrait pas recevoir les messages « hello world ».
Pour enfin vérifier que tout fonctionne correctement, un nouveau locuteur peut être créé à l’aide du protocole de découverte simple (le mécanisme de découverte distribuée par défaut de DDS) pour la découverte.
ros2 run demo_nodes_cpp talker --ros-args --remap __node:=simple_talker
Vous devriez maintenant voir le nœud simple_listener recevoir les messages « hello world » de simple_talker mais pas les autres messages de talker_discovery_server.
Outil de visualisation rqt_graph
L’outil rqt_graph peut être utilisé pour vérifier les nœuds et la structure de cet exemple. N’oubliez pas que pour utiliser rqt_graph avec le protocole de serveur de découverte (c’est-à-dire pour voir les nœuds listener_discovery_server et talker_discovery_server), la variable d’environnement ROS_DISCOVERY_SERVER doit être définie avant de la lancer.
Cas d’utilisation avancés
Les sections suivantes présentent différentes fonctionnalités du serveur de découverte qui vous permettent de créer un serveur de découverte robuste sur le réseau.
Redondance de serveur
En utilisant l’outil fastdds, plusieurs serveurs de découverte peuvent être créés. Les clients de découverte (nœuds ROS) peuvent se connecter à autant de serveurs que vous le souhaitez. Cela permet d’avoir un réseau redondant qui fonctionnera même si certains serveurs ou nœuds s’arrêtent de manière inattendue. La figure ci-dessous montre une architecture simple qui assure la redondance des serveurs.
Dans plusieurs terminaux, exécutez le code suivant pour établir une communication avec des serveurs redondants.
fastdds discovery --server-id 0 --ip-address 127.0.0.1 --port 11811
fastdds discovery --server-id 1 --ip-address 127.0.0.1 --port 11888
--server-id N signifie serveur avec id N. Lorsque vous référencez les serveurs avec ROS_DISCOVERY_SERVER, le serveur 0 doit être en première place et le serveur 1 en deuxième place.
export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888"
ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker
export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888"
ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener
Maintenant, si l’un de ces serveurs tombe en panne, il y aura toujours une capacité de découverte disponible et les nœuds continueront à se découvrir.
Serveur de sauvegarde
Le serveur Fast DDS Discovery permet de créer un serveur avec une fonctionnalité de sauvegarde. Cela permet au serveur de restaurer le dernier état qu’il a enregistré en cas d’arrêt.
Dans différents terminaux, exécutez le code suivant pour établir une communication avec un serveur sauvegardé.
fastdds discovery --server-id 0 --ip-address 127.0.0.1 --port 11811 --backup
export ROS_DISCOVERY_SERVER="127.0.0.1:11811"
ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker
export ROS_DISCOVERY_SERVER="127.0.0.1:11811"
ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener
Plusieurs fichiers de sauvegarde sont créés dans le répertoire de travail du serveur de découverte (le répertoire dans lequel il a été lancé). Les deux fichiers SQLite et les deux fichiers json contiennent les informations nécessaires pour démarrer un nouveau serveur et restaurer l’état du serveur défaillant en cas de panne, évitant ainsi que le processus de découverte ne se reproduise, et sans perdre information.
Cloisons de découverte
La communication avec les serveurs de découverte peut être divisée pour créer des partitions virtuelles dans les informations de découverte. Cela signifie que deux points de terminaison ne se connaîtront que s’il existe un serveur de découverte partagé ou un réseau de serveurs de découverte entre eux. Nous allons exécuter un exemple avec deux serveurs indépendants. La figure suivante montre l’architecture.
Avec ce schéma Listener 1 sera connecté à Talker 1 et Talker 2, car ils partagent Server 1. Listener 2 se connectera avec Talker 1 car ils partagent Server 2. Mais Listener 2 n’entendra pas les messages de Talker 2 car ils ne partagent aucun serveur de découverte ou serveurs de découverte, y compris indirectement via des connexions entre serveurs de découverte redondants.
Exécutez le premier serveur à l’écoute sur localhost avec le port par défaut de 11811.
fastdds discovery --server-id 0 --ip-address 127.0.0.1 --port 11811
Dans un autre terminal, exécutez le deuxième serveur en écoutant sur localhost en utilisant un autre port, dans ce cas le port 11888.
fastdds discovery --server-id 1 --ip-address 127.0.0.1 --port 11888
Maintenant, exécutez chaque nœud dans un terminal différent. Utilisez la variable d’environnement ROS_DISCOVERY_SERVER pour décider à quel serveur ils sont connectés. Sachez que les ids doivent correspondre à.
export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888"
ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_1
export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888"
ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_1
export ROS_DISCOVERY_SERVER="127.0.0.1:11811"
ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_2
export ROS_DISCOVERY_SERVER=";127.0.0.1:11888"
ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_2
Nous devrions voir comment Listener 1 reçoit des messages des deux nœuds locuteurs, tandis que Listener 2 est dans une partition différente de Talker 2 et ne reçoit donc pas de messages de celui-ci.
Note
Une fois que deux points de terminaison (nœuds ROS) se sont découverts, ils n’ont pas besoin du réseau de serveurs de découverte entre eux pour écouter les messages de l’autre.
Comparez Fast DDS Discovery Server avec Simple Discovery Protocol
Afin de comparer les nœuds en cours d’exécution à l’aide du protocole de découverte simple (le mécanisme DDS par défaut pour la découverte distribuée) ou du serveur de découverte, deux scripts qui exécutent un locuteur et de nombreux écouteurs et analysent le trafic réseau pendant ce temps sont fournis. Pour cette expérience, tshark doit être installé sur votre système. Le fichier de configuration est obligatoire pour éviter d’utiliser le mode intraprocess.
Note
Ces scripts nécessitent une fonctionnalité de fermeture de serveur de découverte qui n’est disponible qu’à partir de versions plus récentes que la version fournie dans ROS 2 Foxy. Pour utiliser cette fonctionnalité, compilez ROS 2 avec Fast DDS v2.1.0 ou supérieur.
Les fonctionnalités de ces scripts sont des références à des fins avancées et leur étude est laissée à l’utilisateur.
Exécutez le script bash avec le chemin du fichier setup.bash vers la source ROS 2 comme argument. Cela générera la trace du trafic pour une découverte simple. Exécutez le même script avec le second argument SERVER. Il générera la trace pour l’utilisation du serveur de découverte.
Note
Selon votre configuration de tcpdump, ce script peut nécessiter des privilèges sudo pour lire le trafic sur votre périphérique réseau.
Une fois les deux exécutions terminées, exécutez le script Python pour générer un graphique similaire à celui ci-dessous.
$ export FASTRTPS_DEFAULT_PROFILES_FILE="no_intraprocess_configuration.xml"
$ sudo bash generate_discovery_packages.bash ~/ros2_foxy/install/local_setup.bash
$ sudo bash generate_discovery_packages.bash ~/ros2_foxy/install/local_setup.bash SERVER
$ python3 discovery_packets.py
Ce graphique est le résultat d’une exécution spécifique de l’expérience. Le lecteur peut exécuter les scripts et générer ses propres résultats à des fins de comparaison. On peut facilement voir que le trafic réseau est réduit lors de l’utilisation du service de découverte.
La réduction du trafic résulte du fait que chaque nœud ne s’annonce pas et attend une réponse de tous les autres nœuds du réseau. Cela crée une énorme quantité de trafic dans les grandes architectures. La réduction de cette méthode augmente avec le nombre de nœuds, ce qui rend cette architecture plus évolutive que l’approche du protocole de découverte simple.
Le nouveau Fast DDS Discovery Server v2 est disponible depuis Fast DDS v2.0.2, en remplacement de l’ancien serveur de découverte. Dans cette nouvelle version, les nœuds qui ne partagent pas de sujets ne se découvriront automatiquement pas, enregistrant toutes les données de découverte nécessaires pour les connecter et leurs points de terminaison. L’expérience ci-dessus ne montre pas ce cas, mais même ainsi, la réduction massive du trafic peut être appréciée en raison des sujets d’infrastructure cachés des nœuds ROS 2.