5 Le système d’exploitation des robots (ROS1&2) : Paradigmes de programmation et déploiement

            David St-Onge and Damith Herath

Table des matières

5.1 Objectifs d’apprentissage

5.2 Introduction

         Une perspective industrielle : Entretien avec  Alexandre Vannobel, chef d’équipe, équipe Kortex Applications Kinova Inc.

5.3 Pourquoi ROS ?

5.4 Qu’est-ce que ROS ?

5.4.1 ROS1 et 2 : ROSCore par rapport à DDS

          5.4.2 ROS Industrial

5.5 Fonctionnalités clés du noyau

5.5.1 Protocoles de communication

5.5.2 Lancer et exécuter

5.5.3 Sacs ROS

5.5.4 Transformations et visualisation

5.6 Fonctionnalités supplémentaires utiles

5.6.1 Perception ROS et pilotes matériels

5.6.2 Navigation ROS et MoveIt !

5.6.3 Simulateur Gazebo

5.7 Linux pour la robotique

5.8 Résumé du chapitre

5.9 Questions de révision

5.10 Lectures supplémentaires

Références

5.2 Introduction

Nous prévoyons que la plupart des lecteurs de ce livre cherchent à développer un nouveau robot ou à en adapter un pour des tâches spécifiques. Comme nous l’avons mentionné dans l’introduction, le contenu de ce livre aborde tous les aspects nécessaires pour comprendre “ce qu’il faut faire”, en offrant un aperçu de différentes approches pour répondre à la question “comment peut-on le faire”. Si vous ne le savez pas déjà, vous vous rendrez rapidement compte à travers ce livre que la conception de robots fait appel à de nombreuses disciplines différentes. La quantité de connaissances requises pour déployer un système robotique peut parfois sembler écrasante. Cependant, de nombreux problèmes individuels ont déjà été résolus, y compris la mise en place d’écosystèmes logiciels permettant de simuler puis de déployer nos robots de manière transparente. Des ensembles d’outils et des bibliothèques avancées sont certainement intégrés dans les solutions propriétaires des principaux fabricants de systèmes robotiques (comme ABB RobotStudio et le simulateur DJI UAV), mais est-ce que tout le monde peut bénéficier des décennies de recherche publique pour leurs propres robots? C’est un problème récurrent dans de nombreux domaines, et différentes bibliothèques ont été créées pour regrouper des algorithmes spécifiques tels que la vision (OpenCV) et l’apprentissage automatique (TensorFlow). Le Robot Operating System (ROS) est une solution source ouverte qui répond à ce besoin crucial de partage pour la détection, le contrôle, la planification, la simulation et le déploiement des robots. Il ne faut pas confondre ROS avec une simple bibliothèque, car il s’agit d’un écosystème logiciel (le concept de système d’exploitation peut être trop fort) qui facilite l’intégration, la maintenance et le déploiement de nouvelles fonctionnalités et de nouveaux matériels, depuis la phase de simulation jusqu’au déploiement physique. Même si ROS permet l’exécution du même code à partir de plusieurs langages populaires, son utilisation nécessite une bonne compréhension des concepts sous-jacents de son infrastructure (et, honnêtement, un peu de pratique). ROS est réputé pour sa courbe d’apprentissage abrupte, en particulier pour les développeurs qui ne sont pas familiers avec la conception logicielle. Ce chapitre a pour objectif de vous fournir un aperçu de ROS et d’établir les bases nécessaires pour son utilisation, sans se limiter à une version spécifique (seuls quelques exemples de code sont fournis).

Étant donné que ROS est principalement conçu pour fonctionner sur le système d’exploitation Linux, nous conclurons le chapitre par un bref aperçu des outils fondamentaux de Linux qui sont utiles aux roboticiens et aux développeurs utilisant ROS.

5.3 Pourquoi ROS?

Avant de plonger dans l’utilisation de ROS, il est important de comprendre ses origines, car elles ont influencé de nombreuses décisions de conception, y compris la nécessité de redéfinir tout l’écosystème pour les applications industrielles et décentralisées avec ROS2. ROS a joué un rôle majeur dans les avancées récentes en robotique, et son histoire est aussi importante que n’importe quel travail présenté dans le chapitre 1.

Tout a commencé avec deux doctorants à Stanford : Eric Berger et Keenan Wyrobek. Au début de leurs recherches vers 2005, ils avaient tous les deux besoin d’une plateforme robotique pour déployer et tester leurs avancées scientifiques : la conception d’un robot personnel à sécurité intrinsèque (Wyrobek et al, 2008). Dans leur quête de la meilleure plateforme robotique, ils ont fini par échanger avec plusieurs chercheurs, chacun développant son propre matériel et logiciel. La quantité de travail redondant les a laissés perplexes. Ils affirmeront par la suite que 90% du travail des roboticiens consiste à réécrire du code et à construire des prototypes, comme le montre la Figure 5-1. Ils se sont engagés à transformer la situation en développant une nouvelle pile logicielle commune et un robot physique polyvalent appelé PR1. La collecte de fonds et la promotion de leur idée ne sont pas abordées en détail ici, mais il convient de mentionner qu’ils ont dû faire des efforts considérables pour gagner en crédibilité (Wyrobek, 2017). Pendant leur séjour à Stanford, ils ont réussi à créer le tout premier prototype du PR1, accompagné de sa pile logicielle modulaire (inspiré de Switchyard par Nate Kenig). Ils ont validé sa polyvalence en organisant un concours de codage étudiant et en effectuant une démonstration en interne avec un robot de nettoyage de salon.

La vision de Berger et Wyrobek d’un système d’exploitation universel pour les robots a immédiatement suscité l’intérêt de Scott Hassan, un entrepreneur milliardaire de la Silicon Valley. à l’époque, Scott Hassan était à la tête du laboratoire de recherche Willow Garage, axé sur les véhicules autonomes.

Figure 5-1 : Bande dessinée commandée auprès de Willow Garage, à Jorge Cham, pour illustrer le temps perdu en Recherche et développement en robotiques

Au fil du temps, le ROS (rebaptisé ainsi par Willow Garage en référence à la pile logicielle inspirée par Berger-Wyrobek-Koenig) et les activités de relations publiques sont devenus la principale préoccupation de Willow Garage, impliquant des investissements de plusieurs millions de dollars. Ces ressources considérables ont clairement contribué à la croissance rapide de ROS, notamment en soutenant financièrement une formidable équipe d’ingénieurs. Cependant, il y avait déjà une poignée de projets source ouverte pour la robotique à l’époque, y compris Player/Stage (Gerkey et al, 2003), la boîte à outils de navigation Carnegie Mellon (CARMEN) (Montemerlo et al, 2003), Microsoft Robotics Studio (Jackson, 2007), OROCOS (Bruyninckx, 2001), YARP (Metta et al, 2006), et plus récemment le Lightweight Communications and Marshalling (LCM) (Huang et al, 2010), ainsi que d’autres systèmes (Kramer and Scheutz, 2007). Ces systèmes offrent des interfaces communes permettant le partage et la réutilisation de code, mais ils n’ont pas connu le même niveau de succès durable que ROS. L’argent seul ne pouvait pas garantir le succès de ROS; il avait besoin d’une communauté solide pour prospérer.

Dans la Silicon Valley, des individus se trouvent dans un lieu secret, travaillant sur un projet qui pourrait éventuellement ne jamais voir le jour. Ils peuvent ou non être capables d’en parler. C’est une expérience totalement différente de celle que nous vivons ici, où nous avons la possibilité d’écrire du code toute la journée, tous les jours, et de le partager avec le monde. – Brian Gerkey, PDG d’Open Robotics (Huet, 2017)

La communauté ROS est aujourd’hui clairement ce qui rend ROS unique ^[1], puissante et incontournable lorsqu’on est impliqué dans la robotique. Suite au témoignage de Berker (Wyrobek, 2017), ils ont bâti cette communauté en utilisant trois stratégies :

1. En impliquant les autres acteurs majeurs de la robotique source ouverte dès le début de la définition de ROS, ils ont réussi à obtenir leur soutien. Ces individus sont ensuite devenus les tout premiers ambassadeurs de ROS.

2. Par la suite, un programme étendu de stages a été lancé, accueillant des doctorants, des boursiers postdoctoraux, des professeurs et des ingénieurs de l’industrie provenant du monde entier. Tous ont apporté leur contribution à ROS et l’ont utilisé dans leurs propres travaux. Selon Berker, Willow Garage a accueilli à un moment donné un nombre considérable de stagiaires, dépassant même celui des employés, avec des centaines d’entre eux.

3. Suite à un appel concurrentiel, ils ont offert onze de leurs premiers prototypes PR2, exécutant exclusivement ROS, à des grands laboratoires de recherche du monde entier. Les nouveaux propriétaires des robots devaient s’engager à contribuer de manière significative à la base de code de ROS et à fournir des preuves montrant que leur institution leur permettait de partager publiquement leurs recherches.

Regrettablement, en 2013, Willow Garage a connu sa dissolution malgré la popularité croissante de ROS et son utilisation répandue à travers le monde. Cependant, cela ne signifiait pas la fin de ROS et du PR2. Clearpath Robotics a repris le service client du matériel, tandis qu’une nouvelle entité à but non lucratif, l’Open Source Robotics Foundation (OSRF), a pris en charge le développement de logiciels open source. Sous OSRF, ils ont développé le premier ensemble de distributions ROS (Distro), de Medusa Hydro (2013) à Melodic Morenia (2018), mais la fondation grandissait avec de plus en plus de demandes de contrats commerciaux. En 2017, elle se sépare pour créer l’Open Source Robotics Corporation (connue sous le nom d’Open Robotics ^[2]), tandis que la fondation maintient toujours la base de code ROS. Open Robotics a lancé la version la plus récente de ROS1, appelée Noetic, qui marque la première utilisation de Python 3 (alors que toutes les versions précédentes utilisaient Python 2). En plus de cela, ils ont également introduit une toute nouvelle version appelée ROS2.

5.4 Qu’est-ce que ROS?

Vous pourriez vous demander si ROS n’est rien de plus qu’une bibliothèque banale… Qu’est-ce qui le rend si spécial? La réponse est en fait double :

1. Il offre des mécanismes permettant de maintenir et d’étendre le code, notamment l’ajout de nouvelles fonctionnalités.
2. Il crée une connexion entre une vaste communauté d’utilisateurs. Le wiki ROS fournit une réponse plus complète ^[3] :

ROS est un système d’exploitation source ouverte méta-système pour votre robot. Il offre tous les services que vous attendez d’un système d’exploitation, tels que l’abstraction matérielle, le contrôle de périphériques de bas niveau, la mise en oeuvre de fonctionnalités couramment utilisées, la communication de messages entre les processus et la gestion des progiciels. De plus, il met à disposition des outils et des bibliothèques permettant d’acquérir, de créer, d’écrire et d’exécuter du code sur plusieurs ordinateurs.

Figure 5-2 : Structure des dossiers de l’espace de travail ROS à partir des affectations détaillées au Chapitre 9

Nous limiterons notre discussion à une liste de deux éléments et nous survolerons simplement certains concepts fondamentaux du génie logiciel afin de mieux comprendre comment ils se manifestent dans ROS. La mise en oeuvre des meilleures pratiques d’ingénierie logicielle est au coeur de ROS, allant d’une architecture modulaire à un flux de travail complet de développement de code. La notion d’un système d’exploitation peut être quelque peu étirée, car ROS est plus proche d’un middleware : l’interface abstraite vers le matériel (POSIX des robots).

En tant qu’utilisateur de ROS (c’est-à-dire des nondéveloppeurs), il n’est généralement pas nécessaire de connaître en détail la structure interne de ROS. Cependant, il est essentiel d’apprendre les bases afin de l’utiliser correctement. ROS fournit un méta-constructeur, c’est-à-dire un ensemble cohérent d’outils permettant de créer du code dans plusieurs langages pour différentes architectures informatiques et environnements. Dans ROS1, cela se fait catkin (anciennement par rosbuild); tandis que dans ROS2 ament prend le relais. En fin de compte, ce sont des choses très similaires, toutes deux ne sont que des enveloppes de Cmake (Cross-platform Makefile system ^[4]). En tant que développeur Python, vous pourriez penser que ce type de structure n’est pas nécessaire. Cependant, il est important de noter que cela contribue à la portabilité et à la modularité de ROS. La portabilité dans ce contexte se réfère à la facilité de déploiement de votre code dans différents environnements, tant qu’il suit la structure de ROS. Ces différents environnements peuvent être utilisés par d’autres utilisateurs, pour de nouveaux robots ou même pour garantir une compatibilité parfaite avec un environnement de test. Nous aborderons plus en détail l’infrastructure de simulation fournie par ROS dans la section 5.6.3. L’utilisation des outils de construction de ROS permet d’intégrer votre code au reste de l’écosystème ROS. Le méta-constructeur génère les messages personnalisés (sujets), les services et les actions requis par votre noeud (décrits dans la section 5.5.1) et les rend disponibles pour d’autres exécutables (bibliothèques similaires). En outre, ROS ajoutera plusieurs chemins et fichiers à l’environnement pour faciliter l’exécution de votre code et la localisation rapide de vos fichiers, tels que les fichiers de configuration. Le méta-constructeur organise votre espace de travail sur build,devel et src dossiers, comme illustré à la Figure 5-2.

Jetons un coup d’oeil à cette structure de dossiers ROS. En un clin d’oeil, le dossier build héberge tous les fichiers finaux générés à partir du méta-constructeur tandis que le dossier devel garde une trace des fichiers générés par le processus à des fins de test et de débogage. Le dossier devel comprend également le fichier setup.bash l’essentiel, qui, lorsqu’il provient (#sourcedevel/setup.bash), ajoute l’emplacement des progiciels créés à votre environnement ROS. L’inclusion des systèmes ROS (#source /opt/<ROSDistro>/setup.bash) et de votre espace de travail local est obligatoire pour exécuter tout exécutable utilisant des commandes ROS. L’inclusion de ces étapes fait généralement partie de toutes les procédures d’installation de ROS, que ce soit pour les progiciels maintenus officiellement ou ceux provenant de tiers. Le dossier src est celui que vous utiliserez le plus. Il contient un dossier séparé pour chacun package de votre espace de travail. Le logiciel dans ROS est organisé en progiciels. Un progiciel peut contenir des noeuds ROS, une bibliothèque indépendante de ROS, un ensemble de données, des fichiers de configuration, un logiciel tiers ou tout autre élément qui constitue un module logiquement utile. L’objectif de ces progiciels est de fournir cette fonctionnalité utile de manière conviviale, permettant ainsi une réutilisation facile du logiciel.

Chacun des dossiers du progiciel doit respecter une structure, comme illustré à la Figure 5-2, avec les sous-dossiers : include, launch, src ainsi que ceux facultatifs liés à l’utilisation du code Python (script) et la simulation (models, urdf, worlds). Le include et les dossiers src font partie de la structure commune du code C/C++, le premier pour les entêtes (déclarations) et le second pour le contenu (définitions). launch contient les fichiers lancés discutés dans la section 5.5.2. Les dossiers à l’intérieur src sont packages et chacun peut contenir un ou plusieurs nodes. Les noeuds sont exécutables avec des fonctionnalités dédiées et des entrées et sorties spécifiques (le cas échéant). L’espace de travail illustré à la Figure 5-2 est extrait des devoirs du Projet dans le chapitre 9. Il combine des progiciels tiers d’Intel pour les caméras (realsense-occupancy), de Kinova pour le bras Gen3 lite (ros_kortex), de Clearpath pour la base à roulettes (dingo, dingo_robot, jackal, puma_motor_driver) et des progiciels spécifiques aux affectations (mobile_manip,realsense_simulator, common_gazebo_models).

Pour déployer un espace de travail ROS, vous devez suivre les instructions d’installation de ROS ^[5], puis copiez un noeud tiers (clone un référentiel Git) afin de travailler dessus, ou créez votre propre espace de travail ^[6]. Dans les deux cas, vous finirez par écrire du code dans le dossier du progiciel, par exemple à l’intérieur mobile_manip_ws/src/mobile_manip comme illustré à la Figure 5-2. à l’intérieur de votre progiciel, si un noeud (un fichier exécutable dans script ou code C/C++ dans src) est nouveau, vous devez l’ajouter au fichier de configuration de construction CMakelist.txt à la racine de votre espace de travail pour que votre méta-constructeur soit au courant de l’existence du noeud. Lorsque vous configurez un nouvel environnement ROS, il est important de noter qu’il existe une matrice de compatibilité qui permet d’adapter chaque distribution ROS aux différentes distributions Linux ^[7].

Maintenant que nous avons une meilleure compréhension du fonctionnement du métaconstructeur pour assurer la portabilité (en travaillant avec différents environnements) et la modularité (avec des progiciels et des noeuds), nous pouvons explorer comment cette modularité facilite la connexion à la communauté ROS. Les développeurs ROS ont la possibilité de partager leurs noeuds sur différentes plateformes en ligne, comme GitHub, ou de les rendre officiels en les incluant dans une distribution ROS indexée. . Un progiciel indexé ROS doit respecter scrupuleusement les normes de structure ROS et suivre les bonnes pratiques de programmation telles que les tests unitaires et les commentaires appropriés. Une fois familiarisé avec le processus, il devient facile de télécharger, construire et exécuter des nœuds créés par des contributeurs du monde entier. Cela a contribué à renforcer une communauté, si passionnée qu’elle a créé son propre événement annuel, nommé ROSCon (ROSWorld en 2021 pour la version virtuelle), rassemblant des centaines de développeurs et d’utilisateurs.

La communauté ROS connaît une croissance rapide, avec l’émergence de nouveaux groupes tels que ROS Industrial ^[8], qui se concentre sur le développement de fonctionnalités spécifiques à l’industrie au sein de ROS. Au sein de la communauté ROS, la capacité d’échanger facilement est essentielle, et cela nécessite également une communication fluide entre les logiciels. L’infrastructure de communication de ROS joue un rôle crucial dans la modularité de la plateforme. Une bibliothèque de types de messages extensible assure la compatibilité des formats de données entre tous les noeuds utilisateurs. Les messages, qui sont de simples structures de données, peuvent ensuite être échangés sous forme de sujets ou de services, comme cela sera expliqué plus en détail dans la section suivante 5.5.1.

5.4.1 ROS1 et 2 : ROSCore par rapport à DDS

Les distributions ROS sont régulièrement publiées avec des mises à jour majeures et des améliorations à chaque fois. Depuis 2017, le noyau de ROS a été revu, ce qui a abouti à la sortie de la première distribution stable de ROS2 en 2020, appelée Foxy Fitzroy. La dernière distribution de ROS1, Noetic, bénéficiera officiellement d’une prise en charge jusqu’en mai 2025, et il est possible qu’elle reste active plus longtemps que cela. Cependant, à un certain moment, tous les utilisateurs de ROS devront effectuer la transition vers ROS2. Nous avons rapidement évoqué le nouveau mécanisme de construction de ROS2, ament, et nous discuterons de certains changements de format (par exemple, les fichiers de lancement) dans les sections à venir, mais la principale différence réside dans le coeur, le roscore. Dans ROS1, roscore est un ensemble de noeuds et de programmes qui sont des prérequis pour tout système basé sur ROS. Vous devez avoir un roscore en cours d’exécution pour que les nœuds ROS puissent communiquer. Lancer le roscore (soit automatiquement avec un fichier de lancement soit manuellement avec la commande roscore), démarre le noyau ROS, c’est-à dire le bibliothécaire ROS1. Comme illustré à la Figure 5-3, le maître ROS est celui qui est responsable de l’indexation de tous les noeuds en cours d’exécution (les esclaves) ainsi que leur modalité de communication. En d’autres termes, dans ROS1, sans le ROS Core, les noeuds ne peuvent pas prendre conscience de l’existence des autres noeuds, et encore moins établir une communication entre eux. Cependant, une fois que tous les noeuds sont lancés et conscients les uns des autres, il serait théoriquement possible de fermer le noyau ROS sans que les noeuds ne s’en rendent compte.

Figure 5-3 : Rôle principal de ROS : le bibliothécaire reliant les sujets et les services des noeuds.

En un coup d’oeil : roscore est mort dans ROS2, plus de maître et des esclaves. Dans ROS2, l’infrastructure de communication est essentiellement décentralisée et repose sur une approche de pair à pair grâce au Data Distribution Service (DDS). Contrairement à ROS1 qui avait un point de défaillance unique critique, dans ROS2, aucun noeud ne peut empêcher les autres noeuds de s’exécuter. DDS comprend un protocole de transport de paquets et un service distribué découverte pour récupérer les informations des autres noeuds en cours d’exécution ^[9]. Cela ouvre la porte à une facilitation du développement et du déploiement de systèmes multi-robots, voire même de ce que l’on appelle des essaims robotiques.

Avant de vous lancer dans le monde de ROS, vous devez choisir la version à utiliser. Si vous recherchez davantage de progiciels existants et une API plus stable, optez pour ROS1. Si vous recherchez une stabilité à long terme, de meilleures performances et des algorithmes plus récents, choisissez ROS2. N’essayez pas d’apprendre les deux à partir de rien ! Si vous ne savez toujours pas lequel choisir, ignorez ROS1 et utilisez ROS2, car ROS1 disparaîtra dans quelques années.

5.4.2 ROS-Industrial

Bien que nous limitions nos discussions à ROS1 et ROS 2 dans ce livre, il convient de noter qu’il existe une autre version de ROS appelée ROS-Industrial ou ROS-I ^[10] en abrégé. ROS-I est une initiative délibérée visant à intégrer les fonctionnalités exceptionnelles de ROS dans le domaine de la robotique industrielle. Contrairement aux systèmes robotiques de recherche tels que le PR2, qui sont généralement basés sur une philosophie source ouverte, la plupart des systèmes robotiques commerciaux utilisent des logiciels fermés et propriétaires. Par conséquent, il est extrêmement complexe de développer des projets multiplateformes en utilisant ces systèmes ou d’adapter des systèmes matériels commerciaux existants en dehors de leurs environnements d’origine. C’est cette frustration qui a poussé Shaun Edwards à créer le référentiel initial de ROS-I en collaboration avec la société Yaskawa Motoman Robotics et Willow Garage, alors qu’il travaillait au Southwest Research Institute. L’objectif était de faciliter l’adoption de ROS dans le secteur de la fabrication et de l’automatisation. Au fil du temps, ROS-I a intégré de nombreuses plateformes robotiques commerciales. Les développements fondamentaux de ROS-I sont gérés de manière autonome par plusieurs consortiums industriels, qui exigent une adhésion payante pour participer. Si vous avez une bonne compréhension de ROS, cela vous préparera efficacement à une transition relativement aisée vers ROS-I, si vous envisagez éventuellement de vous aventurer dans le domaine de la robotique commerciale.

5.5 Fonctionnalités clés du noyau

Les prochaines sections fourniront un aperçu des fonctionnalités clés incluses dans ROS. Bien que l’accent soit mis principalement sur ROS1 (les exemples présentés dans le chapitre 18 du projet fonctionnent avec Noetic), les concepts sont également applicables à ROS2, bien que des différences de format soient discutées le cas échéant.

5.5.1 Protocoles de communication

Qu’elle soit décentralisée (ROS2) ou centralisée (ROS1), la communication entre noeuds est structurée en messages ^[11]. La Figure 5-4 montre le Odometry message avec certains des types de messages qu’il contient. Une installation ROS comprend plusieurs bibliothèques de messages, mais les développeurs ont également la possibilité de créer leurs propres messages personnalisés pour leurs noeuds. Lors de l’exécution, la disponibilité de ces structures de données peut être annoncée sur sujets. Les sujets servent essentiellement de noms ou d’étiquettes pour désigner une structure de données spécifique (message) à partir d’un noeud particulier. Un noeud peut publier des données sur plusieurs sujets et également s’abonner à plusieurs sujets simultanément. Les sujets constituent l’un des principaux mécanismes d’échange de données entre les noeuds, permettant ainsi la communication entre différentes parties du système (entre les robots eux-mêmes et avec une station de surveillance terrestre, par exemple). Pour pouvoir partager des informations, un noeud doit annoncer un sujet et ensuite publier du contenu (messages) dedans. La première partie est réalisée dans la section d’initialisation du code du noeud, tandis que la seconde partie est effectuée chaque fois que de nouvelles données doivent être partagées, généralement à l’intérieur de la boucle principale du code à une fréquence fixe. En revanche, les noeuds qui ont besoin du contenu d’un sujet s’y abonneront. L’abonné associé utilisera une fonction de rappel qui sera déclenchée à chaque nouveau message entrant.

Figure 5-4 : Contenu du sujet ROS Odométrie

ROS est livré avec un outil de débogage très pratique pour les sujets, la commande du terminal rostopic (ros2 topic dans ROS2). Il peut être utilisé pour afficher tous les sujets disponibles à partir des noeuds en cours d’exécution : rostopic list (ros2 topic list), pour imprimer le contenu (message) d’un sujet donné : rostopic echo \odom (ros2 topic echo \odom) et pour afficher la fréquence de publication d’un sujet : rostopic hz \odom (ros2 topic hz \odom). Les sujets fonctionnent sur un modèle de communication sans connexion (éditeur/abonné classique), où l’éditeur du message n’a pas connaissance de la présence d’autres noeuds en écoute. ROS fournit également un protocole orienté connexion, pour les appels RPC synchrones les services. Les services se composent d’un client et d’un serveur, et les deux parties reconnaissent les informations reçues lors de chaque transaction. Les sujets et les services utilisent les mêmes conteneurs (types de message) pour les données, mais ils sont mieux adaptés à différentes applications. Par exemple, les sujets sont utiles pour diffuser les lectures d’un capteur, tandis que les services sont plus adaptés pour partager la configuration d’un noeud ou modifier l’état d’un noeud. Enfin, ROS fournit les protocoles d’actions (appels RPC asynchrones), associant sujets et services. Une action de base est composée d’un service d’objectif, d’un service de résultat et d’une rubrique de commentaires. Son format est spécialement conçu pour s’interfacer avec les planificateurs de mission, tels que QGround-Control ^[12].

5.5.2 Lancer et exécuter

Déployer un système ROS, c’est démarrer plusieurs fichiers exécutables, c’est-à-dire noeuds. La commande la plus basique pour le faire est rosrun <package name> <node name> (ros2 run <package name> <node name>), qui est le plus souvent exécutée dans un terminal différent pour chaque noeud. Cependant, dans ROS1, vous avez besoin d’un roscore avant qu’un noeud puisse être exécuté, vous devez donc utiliser la commande roscore préalablement. Utiliser cette stratégie pour démarrer les noeuds individuellement entraînera la nécessité de surveiller simultanément de nombreux onglets de terminal. Cependant, ROS offre une autre méthode pour démarrer plusieurs noeuds en même temps : les fichiers de lancement. Dans ROS1, l’utilisation d’un fichier de lancement permet également le démarrage automatique duroscore.

Figure 5-5 : Exemple de fichier de lancement pour : à gauche, le format XML pour ROS1 et à droite, le format Python nouveau pour ROS2.

Le format du fichier de lancement diffère entre ROS1 et ROS2, comme illustré à la Figure 5-5. ROS1 utilise un fichier XML, tandis que ROS2 encourage l’utilisation de scripts Python (bien que ROS2 continue à prendre en charge le format XML). Cependant, les deux méthodes permettent d’appeler des noeuds avec des paramètres et de les imbriquer avec d’autres fichiers de lancement. Appeler plusieurs noeuds simultanément est très pratique, mais que se passe-t-il si vous avez besoin de deux instances du même noeud, par exemple pour traiter les images de deux caméras? Vous pouvez toujours utiliser la commande rosrun pour lancer les noeuds qui ne sont pas inclus dans le fichier de lancement. Ces nœuds se connecteront automatiquement au même écosystème ROS. Cependant, une fonctionnalité puissante des fichiers de lancement réside dans la balise group, qui permet de contraindre les noeuds à fonctionner dans un espace de noms spécifique. Ainsi, un même noeud peut être lancé plusieurs fois dans des espaces de noms parallèles distincts sans interférer les uns avec les autres. Ceci est essentiel pour simuler des systèmes multi-robots.

5.5.3 Sacs ROS

Imaginons maintenant que vous ayez développé un nouvel algorithme d’évitement de collision basé sur les données de plusieurs capteurs. Vous le déployez sur votre robot et partez en mission avec. Peu importe comment cela se déroule, vous voudrez extraire des mesures de performance et évaluer les problèmes auxquels vous avez été confronté. Cela nécessite un système de journalisation, et heureusement, ROS en propose un robuste et polyvalent, prêt à l’emploi! Le format de sac ROS est un format de journalisation pour stocker les messages ROS dans des fichiers. Les fichiers utilisant ce format sont appelés sacs et portent l’extension de fichier .bag. Les sacs sont enregistrés, relus et généralement manipulés par des outils dans le rosbag (ros2 bag) et rqt_bag (pas d’équivalent encore disponible dans ROS2). Vous pouvez relire vos expériences sur le terrain en rejouant toutes les données des capteurs à leur fréquence réelle (ou en simulant différents taux de publication), en tenant compte de la perte de paquets ou de toute perturbation de l’expérience. rosbags Dispose également d’un API qui offre des fonctionnalités pour analyser, traiter ou exporter rapidement vos données. Par exemple en Python, cela peut ressembler à :

import rosbag

bag = rosbag.Bag(’test.bag’)

for topic , msg, t in bag.read messages(topics=’odom’):

print("Odometry is x={}, y={} and z={} at time {} sec".format(

msg.pose.pose.position.x, msg.pose.pose.position.y, msg.pose.pose.position.z,

t.toSec())

bag.close()

Les Rosbags sont essentiels pour ajuster vos algorithmes et partager vos données expérimentales chronophages avec vos pairs.

5.5.4 Transformations et visualisation

Pouvez-vous concevoir un robot physique qui soit utile sans se déplacer ou sans observer d’autres mouvements ? Toute application pratique dans ROS nécessitera inévitablement un composant capable de surveiller la position d’une pièce, d’un lien de robot ou d’un outil. La manière ROS de traiter le mouvement relatif est englobée dans TF (se transforme). TF permet de rechercher la transformation géométrique entre tous les cadres connectés, même dans le temps. Il vous permet de poser des questions telles que “Quelle était la transformation entre A et B il y a 10 secondes ?”

Figure 5-6 : Visualisation dans RViz d’un flux de caméra fish-eye et des référentiels résultant d’une détection de marqueur fiducial.

Un exemple possible est une caméra, montée sur un robot, suivant des marqueurs dans la scène, comme illustré à la Figure 5-6. Cet exemple montre le cadre d’odométrie du robot (le mouvement de la base mobile – camera_odom_frame), la pose de la caméra (fixée au socle – camera_fisheye2_frame) et la trame de la balise détectée (ETS_target). La balise est détectée dans le camera_fisheye2_frame, et sa pose est extraite et transformée directement dans camera_odom_frame pour visualiser toutes les images ensemble.

Tant que vous avez la position et l’orientation d’un objet (6 degrés de liberté), vous pouvez diffuser son TF en ROS. Par exemple en Python, cela peut ressembler à :

import tf2 ros # Importer la bibliotheque TF

br = tf2 ros.TransformBroadcaster() # creer le diffuseur

t = geometry msgs.msg.TransformStamped() # creer le conteneur de messages

# remplir le message :

t.header.stamp = rospy.Time.now()

t.header.frame id = "world"

t.child frame id = "myrobotframe"

t.transform.translation.x = x

t.transform.translation.y = y

t.transform.translation.z = z

q = tf conversions.transformations.quaternion from euler(psi, phi, theta)

t.transform.rotation.x = q[0]

t.transform.rotation.y = q[1]

t.transform.rotation.z = q[2]

t.transform.rotation.w = q[3]

br.sendTransform(t) # diffuser la transformation

Remarquez dans l’extrait ci-dessus le format de l’orientation (rotation) : ROS, par défaut, nécessite d’utiliser des quaternions. La bibliothèque tf_conversions fournit un outil qui  permet de convertir les matrices de rotation et les angles d’Euler en quaternions, ainsi que de réaliser l’inverse. Pour obtenir des informations plus détaillées sur la représentation mathématique des quaternions, se référer au Chapitre 6. Souvent TF sont utilisés pour définir les relations géométriques fixes entre les parties d’un robot. Vous pouvez utiliser facilement la pose d’un objet détecté par une caméra montée sur votre robot pour générer des commandes appropriées pour les moteurs des roues. Par exemple, en utilisant les informations fournies par la caméra, vous pourriez dire : “Ma caméra détecte une porte à 2 mètres devant, mais elle se trouve à 50 cm de l’axe des roues. Par conséquent, avançons seulement de 1,5 mètre”.

Le spectateur représenté en chiffres 5.6, 5.7 et 5.8 représente RViz, abréviation de visualisation ROS. Il s’agit d’une visionneuse 3D prenant en charge presque tous les types de sujets, à savoir : Nuages de points LiDAR 2D et 3D, flux de caméra et mouvement de cadres de référence dynamiques. Le visualiseur se lance simplement avec rosrun rviz rviz (ou simplement rviz). Puis en utilisant l’interface graphique du bouton ajouter, vous pouvez sélectionner le sujet que vous souhaitez surveiller. Bien que RViz ait été conçu pour surveiller les sujets de votre robot, il peut également héberger des marqueurs interactifs qui peuvent être déplacés dans la fenêtre de visualisation et diffuseront leur position mise à jour dans ROS. Un exemple utilisé pour commander un bras robotique est illustré à la Figure 5-8.

5.6 Fonctionnalités supplémentaires utiles

De nombreuses contributions de la communauté ont été intégrées à la collection d’outils essentiels de ROS, ce qui a grandement contribué à sa popularité. Cette section aborde certains éléments que nous considérons comme étant particulièrement importants pour les robots mobiles et les manipulateurs. Tous ces progiciels sont utilisés dans au moins l’une des missions présentées dans le Chapitre 18 du projet.

5.6.1 Perception ROS et pilotes matériels

Lorsqu’il s’agit de l’intégration matérielle, la même logique s’applique que pour les aspects logiciels mentionnés précédemment : il est inefficace de reproduire ce qui a déjà été fait pour s’interfacer avec chaque composant. Pour les fabricants, il peut être coûteux de développer des pilotes pour différents systèmes d’exploitation et solutions logicielles afin de répondre aux besoins des clients potentiels. Dans ce contexte, ROS joue un rôle de standard en connectant les fabricants à une vaste communauté. Des centaines de fabricants de matériel fournissent des noeuds ROS avec leurs produits, à savoir : SICK, Clearpath, Kinova, Velodyne, Bosch et Intel. Le noeud de pilote développé par le fabricant se concentre généralement sur la communication de bas niveau via les sujets et services compatibles avec ROS. à partir de là, l’utilisation de progiciels ROS pour la perception permet le filtrage, la synchronisation et la visualisation des données. Par exemple, la perception ROS comprend pcl_ros pour gérer les points de nuage. Il inclut des filtres tels que le filtre de grille de voxel et le filtre de passage, ainsi qu’une segmentation géométrique des données permettant d’extraire des plans ou des polygones à partir du nuage de points. Un exemple de point de nuage publié en tant que sujet ROS est illustré à la Figure 5-7. Pour le traitement des images (caméras), cv_bridge et plusieurs autres progiciels apportent les fonctionnalités puissantes de la bibliothèque ouverte OpenCV pour traiter les images dans le code ROS. Celui-ci fournit les algorithmes classiques de détection de contours, de filtrage d’images (flou, etc.) et de génération d’histogrammes. À partir de là, de nombreux algorithmes d’apprentissage automatique ont des enveloppes ROS, tels que le puissant You Only Look Once (YOLO ^[13]) pour la reconnaissance d’objets.

Enfin, ROS perception intègre également un progiciel qui regroupe plusieurs des algorithmes les plus récents pour la localisation et la cartographie simultanées (SLAM), gmapping. Que ce soit avec un LiDAR 2D, un LiDAR 3D, une caméra stéréo ou une seule caméra, ce progiciel est capable de produire une carte approximative de l’environnement exploré par le robot, sans aucune connaissance préalable de la position du robot sur la carte. Ces algorithmes puissants sont désormais essentiels pour tout déploiement de robots mobiles dans un environnement dépourvu de GPS. Bien que de nombreuses autres solutions SLAM plus récentes soient disponibles sur GitHub grâce aux laboratoires de recherche du monde entier, le gmapping est maintenu par l’OSRF. Lorsque l’environnement est connu (une carte 2D est disponible), vous préférerez peut-être utiliser le progiciel ROS pour la localisation adaptative de Monte-Carlo (AMCL). Celui-ci utilise un filtre à particules pour estimer les meilleures positions candidates en simulant vos balayages laser à partir de la carte fournie. C’est la stratégie déployée dans les évaluations 4 et 5 du Chapitre 9 du projet.

Figure 5-7 : Carte de la finale DARPA souterraine 2021 spot-1 réalisée par l’équipe CTUCRAS-NORLAB.

5.6.2 Navigation ROS et MoveIt!

Supposons que la pile de perception nous donne la position du robot et une carte de son environnement. Pour accomplir une mission, le robot devra se déplacer dans cet environnement. Cela peut se faire soit en recherchant une trajectoire optimale pour un robot mobile, soit en calculant une configuration optimale pour que le manipulateur atteigne une pose spécifique avec son outil, par exemple une pince. Pour les robots mobiles, les méthodes traditionnelles de planification de trajectoire se réfèrent généralement au chemin optimal comme étant le chemin le plus court qui peut être calculé à l’aide de divers algorithmes, tels que l’algorithme A*, Dijkstra (Palacz et al (2019)) ou Rapid-Exploring Random Trees -RRT), (des arbres aléatoires à exploration rapide) . Ces algorithmes, parmi de nombreux autres, sont disponibles en tant que progiciels ROS publics prêts à être utilisés.

Pour les manipulateurs, de nombreux solveurs numériques pour la dynamique multicorps ont été développés au cours des dernières décennies, accompagnés de planificateurs de trajectoire qui utilisent soit des algorithmes d’échantillonnage, soit des algorithmes d’optimisation. Ces algorithmes et plusieurs autres ont été intégrés dans l’Open Motion Planning Library ^[14], qui à son tour a été intégrée dans MoveIt! ^[15] Progiciel de planification ROS.

La Figure 5-8 montre MoveIt! en action via RViz à l’aide de marqueurs interactifs. Ces marqueurs peuvent être facilement déplacés vers l’objectif désiré, tandis que le menu de gauche permet à l’utilisateur d’accéder à différents planificateurs et de configurer leurs paramètres. MoveIt! peut également envisager des objets statiques dans la scène pour planifier une solution incluant l’évitement des collisions. Ces objets peuvent être ajoutés manuellement ou importés depuis le simulateur Gazebo.

Figure 5-8 : Manipulateur Kinova Gen3 lite contrôlé par des marqueurs interactifs et planificateur MoveIt! de RViz.

5.6.3 Simulateur Gazebo

La simulation de robots est un outil essentiel dans la boîte à outils de tout roboticien. Un simulateur bien conçu permet de tester rapidement des algorithmes, de concevoir des robots, d’effectuer des tests de régression et de former des systèmes d’intelligence artificielle en utilisant des scénarios réalistes. Gazebo offre une précision et une efficacité remarquables pour la simulation de robots dans des environnements complexes, tant intérieurs qu’extérieurs. Il intègre un moteur physique robuste, de graphiques haute fidélité et d’interfaces pratiques, tant graphiques que programmables. Mieux encore, Gazebo est gratuit, source ouverte et bénéficie d’une communauté dynamique, tout comme ROS.

Figure 5-9 : Vue du simulateur Gazebo avec le manipulateur mobile de la mission du Chapitre 18 du projet

Le simulateur Gazebo peut charger n’importe quel maillage dans obj ou formatdae, puis l’utiliser avec une dynamique réaliste pour simuler les mouvements et les collisions du robot. Tout comme ROS, Gazebo est un système modulaire qui permet la personnalisation des modules d’extension de simulation pour la dynamique et la simulation de données de capteur spécifiques. Plusieurs fabricants proposent des modules d’extension (par ex. les caméras Intel) et les modèles (par ex. robots Kinova) pour simuler leur matériel dans Gazebo. La Figure 5-9 montre un environnement de simulation du projet du Chapitre 18, comprenant des caméras Intel, le manipulateur Kinova Gen3 lite entièrement actionné, la base mobile Clearpath Dingo à entraînement différentiel et un monde composé de murs, de meubles et de portes fonctionnelles.

Gazebo est de loin le simulateur le plus populaire parmi les utilisateurs de ROS, cependant, il peut manquer de réalisme et devenir assez lourd à exécuter lorsqu’il s’agit de simuler un grand nombre de robots (comme des essaims). Pour répondre à cette première limitation, Gazebo est progressivement remplacé par Ignition ^[16]. Néanmoins, les développeurs en machine learning basé sur la vision préféreront des environnements plus réalistes comme Unreal ^[17] et Unité ^[18] (qui comprend un module d’extension ROS ^[19]). Pour ce dernier, les roboticiens en essaim utiliseront des simulateurs dédiés, comme ARGoS ^[20] (qui dispose aussi d’un module d’extension ROS ^[21]).

5.7 Linux pour la robotique

IDE Nous avons mentionné précédemment que ROS n’est pas exactement un système d’exploitation, mais plutôt un middleware. Cependant, plusieurs utilisateurs l’appellent le Linux pour la robotique (Wyrobek, 2017). Ce nom comporte une part de vérité, car ROS étend le système d’exploitation Linux aux applications robotiques. Jusqu’à ROS2, il était principalement conçu pour fonctionner correctement sur Linux. Par conséquent, la plupart des utilisateurs de ROS doivent avoir une certaine familiarité avec l’environnement Linux.

Nous tiendrons pour acquis que vous démarrez sur un ordinateur déjà configuré avec Linux (Dell vend des ordinateurs certifiés préchargés avec Linux ^[22]), ou que vous savez lancer une machine virtuelle Linux sous Windows ou OSX (les machines virtuelles ne sont pas recommandées pour les expériences matérielles et les simulations nécessitant des ressources informatiques intensives).

Comme nous l’avons mentionné précédemment, lors de l’installation de ROS sur un système Linux, examinez d’abord la matrice de compatibilité ROS-Linux ^[23]. Dans toutes les distributions Linux, il sera nécessaire d’utiliser des commandes dans un terminal pour effectuer différentes actions. Il est également essentiel de connaître les commandes de base dans un terminal Linux pour le développement embarqué, car les ordinateurs de bord les plus couramment utilisés (par ex., RaspberryPi, NVidia) exécuteront une version de Linux et seront accessibles via une session de terminal distant (par ex., ssh). Les commandes de terminal les plus essentielles sont :

• ˆcd : Change Directory. cd .. est utilisée pour accéder au répertoire parent.
• ˆls : List Files. ls -la : affichera tous les fichiers (ceux cachés aussi) avec leurs propriétés (autorisations et taille).
• ˆmv : MoVe file.
• ˆcp : CoPy file.
• ˆrm : ReMove file.
• ˆdf : Disk Filesystem (disk usage). df -h permet d’afficher l’utilisation de la mémoire sur tous les disques dans un format lisible.
• ˆreset : pour supprimer toutes les sorties de l’écran du terminal et supprimer toutes les modifications apportées aux variables d’environnement locales.

Pour éditer et compiler votre code ROS, il est recommandé d’utiliser un environnement de développement intégré (IDE) qui facilite la recherche des bons noms et définitions de fonctions, ainsi que la compilation et le débogage de votre code. Les environnements de développement intégrés (IDE) sont comme des lunettes : il est nécessaire de les essayer pour trouver celui qui correspond le mieux à vos besoins. De nombreux IDE sont disponibles pour Python (Atom, Eclipse, PyCharm, etc.) et C/C++ (Visual Code, CLion). Certains experts Linux préfèrent les éditeurs de texte hautement configurables tels que Sublime, Emacs et Vim, pour lesquels des modules d’extension et des tutoriels sont disponibles pour ROS. Cependant, la majorité des développeurs ROS semblent préférer Eclipse pour son interface conviviale, sa prise en charge de plusieurs langages de programmation et son module d’extension ROS parfaitement intégré. D’autres options plus récentes attirent l’attention : Microsoft Visual Code, ou sa version ROS source ouverte, Roboware, et le ROS Development Studio (RDS) basé sur le Web. Bien qu’ils aient tous des avantages et des inconvénients, ils font tous essentiellement la même chose. Si vous recherchez un IDE, nous vous suggérons VS Code. Si vous voulez juste un éditeur de code, nous aimons Sublime Text.

5.10 Lectures supplémentaires

La meilleure façon d’apprendre ROS est de jouer avec. Wiki ROS ^[24] est un excellent endroit pour commencer à en savoir davantage sur les progiciels de base. Le wiki ROS propose également plusieurs tutoriels de base pour vous exercer sur les sujets, les services, les actions et les fichiers de lancement en C++ ou en Python. Si vous recherchez une extension de ce chapitre avec des explications approfondies sur les fonctionnalités de ROS, le livre en ligne gratuit de Jason M. O’Kane intitulé A Gentle Introduction to ROS ^[25]est une ressource parfaite. Pour ceux qui préfèrent les livres physiques offrant une couverture complète de tous les composants de ROS, ainsi que des exemples détaillés, nous recommandons le livre de Quigley, Gerkey et Smart, Programming Robots with ROS. Malheureusement, il y a encore un manque de bons livres spécifiques à ROS2, mais la documentation officielle en ligne reste une excellente ressource ^[26].

RÉFÉRENCES

Bruyninckx H (2001) Open robot control software: the orocos project. In: Proceedings 2001 ICRA. IEEE International Conference on Robotics and Automation (Cat. No.01CH37164), vol 3, pp 2523–2528 vol.3, DOI 10.1109/ROBOT.2001.933002  https://doi.org/10.1109/ROBOT.2001.933002

Gerkey BP, Vaughan RT, Howard A (2003) The player/stage project: Tools for multi-robot and distributed sensor systems. In: In Proceedings of the 11th International Conference on Advanced Robotics, pp 317–323   https://www.researchgate.net/publication/2876085_The_PlayerStage_Project_Tools_for_Multi-Robot_and_Distributed_Sensor_Systems

Huang AS, Olson E, Moore DC (2010) LCM: Lightweight communications and marshalling.In: 2010 IEEE/RSJ International Conference on Intelligent Robots and Systems, pp 4057–4062, DOI 10.1109/IROS.2010.5649358 , https://people.csail.mit.edu/albert/pubs/2010-huang-olson-moore-lcm-iros.pdf

Huet E (2017) The not-so-secret code that powers robots around the globe. Bloomberg The Quint  https://www.bloomberg.com/news/articles/2017-05-17/the-not-so-secret-code-that-powers-robots-around-the-globe

Jackson J (2007) Microsoft robotics studio: A technical introduction. IEEE Robotics Automation Magazine 14(4):82–87, DOI 10.1109/M-RA.2007.905745  https://doi.org/10.1109/M-RA.2007.905745

Kramer J, Scheutz M (2007) Development environments for autonomous mobile robots: A survey. Autonomous Robots 22(2):101–132, DOI 10.1007/s10514-006-9013-8 , http://dx.doi.org/10.1007/s10514-006-9013-8

Metta G, Fitzpatrick P, Natale L (2006) Yarp: Yet another robot platform. International Journal of Advanced Robotic Systems 3(1):8, DOI 10.5772/5761, URL,  https://doi.org/10.5772/5761

Montemerlo M, Roy N, Thrun S (2003) Perspectives on standardization in mobile robot programming: the carnegie mellon navigation (carmen) toolkit. In: Proceedings 2003 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2003) (Cat.No.03CH37453), vol 3, pp 2436–2441 vol.3, DOI 10.1109/IROS.2003.1249235, https://doi.org/10.1109/IROS.2003.1249235

Palacz W, ´Slusarczyk G, Strug B, Grabska E (2019) Indoor robot navigation using graph models based on bim/ifc. In: International Conference on Artificial Intelligence and Soft Computing, Springer, pp 654–665 http://dx.doi.org/10.1007/978-3-030-20915-5_58

Wyrobek K (2017) The origin story of ros, the linux of robotics. IEEE Spectrum //spectrum.ieee.org/the-origin-story-of-ros-the-linux-of-robotics

Wyrobek KA, Berger EH, Van der Loos HM, Salisbury JK (2008) Towards a personal robotics development platform: Rationale and design of an intrinsically safe personal robot. In: 2008 IEEE International Conference on Robotics and Automation, pp 2165–2170, DOI10.1109/ROBOT.2008.4543527

Liste des figures

Figure 5-1 : Bande dessinée commandée auprès de Willow Garage, à Jorge Cham, pour illustrer le temps perdu en Recherche et développement en robotiques

Figure 5-2 : Structure des dossiers de l’espace de travail ROS à partir des affectations détaillées au Chap. 18

Figure 5-3 : Rôle principal de ROS : le bibliothécaire reliant les sujets et les services des noeuds.

Figure 5-4 : Contenu du sujet ROS Odométrie

Figure 5-5 : Exemple de fichier de lancement pour : à gauche, le format XML pour ROS1 et à droite, le format Python nouveau pour ROS2.

Figure 5-6 : Visualisation dans RViz d’un flux de caméra fish-eye et des référentiels résultant d’une détection de marqueur fiducial

Figure 5-7 : Carte de la finale DARPA souterraine 2021 spot-1 réalisée par l’équipe CTUCRAS-NORLAB.

Figure 5-8 : Manipulateur Kinova Gen3 lite contrôlé par des marqueurs interactifs et planificateur MoveIt! de RViz.

Figure 5-9 : Vue du simulateur Gazebo avec le manipulateur mobile de la mission du Chapitre 18 du projet