ROS – Robot Operating System

Qu’est ce que ROS ?

Comme son nom l’indique, ROS (Robot Operating System) est un système d’exploitation pour robots. De même que les systèmes d’exploitation pour PC, serveurs ou appareils autonomes, ROS est un système d’exploitation complet pour la robotique de service.

Il est composé d’un ensemble de logiciels libres open source permettant de développer des logiciels pour la robotique.

ROS est un méta système d’exploitation, quelque chose entre le système d’exploitation et le middleware.

Il fournit des services proches d’un système d’exploitation :

• Abstraction du matériel
• Gestion de la concurrence
• Gestion des processus

ROS fournit aussi des fonctionnalités de haut niveau :

• Appels asynchrones
• Appels synchrones
• Base de données centralisée de données
• Système de paramétrage du robot

De l’intérêt d’un OS pour les robots

Avant les OS robotiques, chaque concepteur de robot, chaque chercheur en robotique passait un temps non négligeable à concevoir matériellement son robot ainsi que le logiciel embarqué associé. Cela demandait des compétences en mécanique, électronique et programmation embarquée.

Généralement, les programmes ainsi conçus correspondaient plus à de la programmation embarquée, proche de l’électronique, qu’à de la robotique proprement dite, telle que nous pouvons la rencontrer aujourd’hui dans la robotique de service. La réutilisation des programmes était non triviale car fortement liés au matériel sous-jacent.

L’idée principale d’un OS robotique est d’éviter de réinventer la roue à chaque fois et de proposer des fonctionnalités standardisées faisant abstraction du matériel, tout comme un OS classique pour PC, d’où l’analogie de nom.

ROS se positionne donc comme un facilitateur de projets robotiques. Les chercheurs ou les ingénieurs des pôles R&D ne passent plus de temps à créer un nouvel écosystème pour chaque nouveau projet en robotique. Cela représente également une économie financière.

ROS a un effet d’accélérateur en R&D en réduisant les coûts et le “time to market”. Pour les structures ou département souhaitant lancer un nouveau prototype rapidement, ou qui ont besoin de combler un retard technologique, c’est très intéressant.

Un autre avantage de l’OS robotique comme ROS est de rassembler des savoir-faire de différentes disciplines. En effet, concevoir et programmer un robot, c’est :

• Gérer le matériel en écrivant les pilotes
• Gérer la mémoire et les processus
• Gérer la concurrence et la fusion de données
• Proposer des algorithmes de raisonnement abstrait faisant largement appel à l’intelligence artificielle

La robotique nécessite donc des compétences très différentes, compétences généralement hors de portée d’une seule personne.

ROS abaisse le niveau technique requis pour travailler sur des projets robotiques. Cela peut permettre à de nombreuses entreprises de plus facilement se lancer en robotique, ou concevoir des systèmes complexes plus rapidement.

L’histoire de ROS

Il existe de nombreux framework robotiques réalisés dans une optique précise, à des fins de prototypage. ROS a été voulu plus généraliste même si ses concepteurs pensent qu’il n’est pas l’OS ultime capable de tout faire.

Avant 2007, année de création du middleware ROS, les roboticiens ne disposaient pas d’architecture logicielle embarquée standard. Il s’agit donc d’une avancée importante.

ROS est développé et maintenu par une société californienne, Willow Garage, fondée en 2006 par Scott Hassan, un des premiers employés de Google qui a participé au développement de la technologie du moteur de recherche et qui est aussi à l’origine des Yahoo Groups (en fait de eGroups qui est devenu Yahoo Groups). Le PDG de Willow Garage est Steeve Cousin, un ancien d’IBM.

Willow Garage est une société privée qui entretient des liens étroits avec l’université de Stanford qui est proche géographiquement de Willow Garage (à Palo Alto en Californie).

Willow Garage se présente comme un laboratoire de recherche et un incubateur technologique pour la robotique personnelle, centré sur la recherche plus que sur les profits (au moins au début).

Willow Garage développe aussi bien du logiciel avec ROS que du matériel avec leurs robots PR2et TurtleBot. Dans tous les cas, ce qui est produit est open source (licences BSD). Leur idée est que si l’on souhaite voir arriver les robots dans nos foyers, il faut pour cela accélérer les recherches en fournissant des bases hardware et software solides et qui soient open source.

Il semblerait que Willow Garage veuille bâtir la communauté de la robotique plutôt que la robotique en elle-même. Interrogé par le magazine l’Expansion, Scott Hassan indique que ses objectifs sont identiques à ceux d’Irobot mais que la stratégie pour y parvenir est différente.

4 raisons de croire au succès de Willow Garage d’après le singularityhub :

• Ils souhaitent proposer les moyens de ne plus réinventer la roue afin d’accélérer les recherches en robotique.
• Ils ont les fonds nécessaires.
• Ils ont l’oreille du monde de la recherche.
• Ils veulent favoriser le déploiement de leur technologie gratuitement avant de penser à gagner de l’argent.

L’organisation générale de ROS

La philosophie de ROS se résume dans les 5 grands principes suivants :

• Peer to Peer
• Basé sur des outils (microkernel)
• Multi langages
• Léger
• Gratuit et open source

Reprenons chacun de ces points.

Peer to Peer : Un robot suffisamment complexe est composé de plusieurs ordinateurs ou cartes embarquées reliées par Ethernet ainsi que parfois des ordinateurs externes au robot pour des tâches de calcul intensif. Une architecture peer to peer couplée à un système de tampon (buffering) et un système de lookup (un name service appelé master dans ROS), permet à chacun des acteurs de dialoguer en direct avec un autre acteur, de manière synchrone ou asynchrone en fonction des besoins.

Multi langages : ROS est neutre d’un point de vue langage et peut être programmé en différents langages. La spécification de ROS intervient au niveau message. Les connexions peer to peer sont négociées en XML-RPC qui existe dans un grand nombre de langages. Pour supporter un nouveau langage, soit on rewrappe les classes C++ (ce qui a été fait pour le client Octave par exemple), soit on écrit les classes permettant de générer les messages. Ces messages sont décrits en IDL (Interface Definition Language).

Basé sur des outils : Plutôt qu’un runtime monolithique, ROS a adopté un design microkernel qui utilise un grand nombre de petits outils pour faire le build et le run des différents composants ROS. Lorsque vous parcourrez les tutoriaux ROS, vous apprenez à vous servir de plusieurs commandes permettant de manipuler les nœuds et les messages. Chaque commande est en fait un exécutable. L’avantage de cette solution est qu’un problème sur un executable n’affecte pas les autres, rendant le système plus robuste et évolutif qu’un système basé sur un runtime centralisé.

Léger : Afin de lutter contre le développement d’algorithmes plus ou moins liés avec l’OS robotique et donc difficilement réutilisables ensuite, les développeurs de ROS souhaitent que les pilotes et autres algorithmes soient contenus dans des exécutables indépendants. Cela assure la réutilisabilité maximale et surtout le maintient d’une taille réduite. Ce mécanisme rend ROS facile d’usage, la complexité se trouvant dans les librairies. Cette organisation facilite en plus le test unitaire. Enfin, ROS utilise du code (pilotes et algorithmes) issus d’autres projets open source :

• Simulateur Player/stage
• Librairie de traitement d’image et de vision artificielle : OpenCV
• Algorithme de planification : OpenRave
• …

Pour une liste complète des algorithmes disponibles, rendez-vous sur : http://www.ros.org/wiki/StackList

Gratuit et open source : Nous avons déjà expliqué les raisons de ce choix avant. Notons toutefois que l’architecture choisie est cohérente avec ce choix : ROS passe des données grâce à de la communication interprocess. De ce fait, les modules n’ont pas besoin d’être liés dans un unique process, facilitant ainsi l’usage des différentes licences.

L’écosystème ROS possède des fonctionnalités de partage. ROS permet d’importer et exporter des bibliothèques de logiciels (packages ROS) qui peuvent être chargées et uploadées sur le site www.ros.org. Ces fonctionnalités ont émulé les pratiques collaboratives et le partage de connaissance dans le secteur de la robotique.

Les autres systèmes d’exploitation généralistes pour robots

Citons quelques systèmes d’exploitation ou middleware pour robots :

• Microsoft Robotics Developper Studio : système multiplateforme, créé par Microsoft. Il est gratuit et il fournit un outil de simulation. Il n’est cependant compatible qu’avec Windows et se programme avec un langage managé .NET (C# de préférence).
• NAOQi : système robotique réalisé pour le robot NAO par Aldebaran Robotics. Se programme en C++ ou Python. NAOQI est open source.
• URBI : Réalisé par la société française Gostai. Il est open source et propose son propre langage de script (URBIScript). Il se programme en C++ également. URBI est multiplateformes.

Il existe ensuite de nombreux systèmes embarqués spécifiques à un robot en particulier. On sort ici du modèle multiplateforme.

Programmer avec ROS

ROS n’est pas dépendant d’un langage. A ce jour, trois librairies principales ont été définies pour ROS qui permettent de programmer respectivement ROS en Python, en Lisp ou en C++. En plus de ces trois librairies, deux librairies expérimentales sont proposées, qui permettent de programmer ROS en Java ou en Lua.

Un mot sur ROSJAVA et Android
Rosjava est quelque chose qui est différent de la librairie cliente java présente dans ROS et que nous venons de mentionner. Rosjava est une implémentation entièrement en Java de ROS créée et maintenue par Google et Willow Garage. Dans ce cas, au lieu d’avoir une librairie cliente en java qui permet d’accéder au cœur de ROS qui lui est écrit en C++, le projet rosjava a totalement réécrit le cœur de ROS en Java. L’objectif poursuivit par Google est d’avoir une version de ROS totalement compatible avec Android, le système d’exploitation léger de Google. Rosjava permettra de piloter les robots dont le système d’exploitation n’est pas Linux mais Android (même si Android est basé sur Linux).

Les robots compatibles avec ROS

La liste des robots compatibles avec ROS évolue sans cesse. Pour une liste exhaustive, rendez-vous sur le site de Willow Garage : http://www.ros.org/wiki/Robots

Citons tout de même les plus connus : NAO, Lego Mindstorms NXT, IRobot Roomba, TurtleBot et enfin le robot icône de Willow Garage, le fameux robot PR2.

Le système de fichiers de ROS

Les ressources de ROS sont organisées dans une structure hiérarchique sur disque. Deux concepts importants se détachent :

• Le package : C’est l’unité principale d’organisation logicielle de ROS. Un package est un répertoire qui contient les nœuds (nous verrons ci-dessous ce qu’est un nœud), les librairies externes, des données, des fichiers de configuration et un fichier de configuration xml nommé manifest.xml.
• La stack : Une stack est une collection de packages. Elle propose une agrégation de fonctionnalités telles que la navigation, la localisation… Une stack est un répertoire qui contient les répertoires des packages ainsi qu’un fichier de configuration nommé stack.xml.

En plus de ces deux notions très importantes, on relève également la notion de distribution. Une Distribution, comme dans Linux, est un ensemble de stacks versionnées.

Les dernières distributions en date de ROS :

ROS Fuerte, publiée le 23 Avril 2012 ROS Electric Emys, publiée le 30 août 2011 ROS Diamondback, publiée le 2 mars 2011 ROS C Turtle, publiée le 2 août 2010 ROS Box Turtle, publiée le 2 mars 2010

Les notions de base de ROS

Le principe de base d’un OS robotique est de faire fonctionner en parallèle un grand nombre d’exécutables qui doivent pouvoir échanger de l’information de manière synchrone ou asynchrone. Par exemple, un OS robotique doit interroger à une fréquence définie les capteurs du robot (capteur de distance à ultrasons ou infrarouge, capteur de pression, capteur de température, gyroscope, accéléromètre, caméras, microphones…), récupérer ces informations, les traiter (faire ce que l’on appelle la fusion de données), les passer à des algorithmes de traitement (traitement de la parole, vision artificielle, localisation et cartographie simultanée,…) et enfin contrôler les moteurs en retour. Tout ce processus s’effectue en continue et en parallèle. D’autre part, l’OS robotique doit assurer la gestion de la concurrence afin d’assurer l’accès efficace aux ressources du robot.

Nous décrivons ci-dessous les concepts regroupés dans ROS sous le nom de « ROS Computation Graph » et qui permettent d’atteindre ces objectifs. Il s’agit des concepts utilisés par le système en cours de fonctionnement tandis que le « ROS FileSystem » décrit dans le paragraphe précédent correspond aux concepts statiques.

Les nœuds

ROS répond à tout cette problématique grâce à des notions de base simples. La première notion est la notion de nœud.

Dans ROS, un nœud est une instance d’un exécutable. Un nœud peut correspondre à un capteur, un moteur, un algorithme de traitement, de surveillance… Chaque nœud qui se lance se déclare au Master. On retrouve ici l’architecture microkernel où chaque ressource est un noeud indépendant.

Le système de nœuds permet de standardiser des fonctions basiques, et ainsi de développer rapidement des briques technologiques qui pourront être réutilisées, modifiées ou améliorées facilement.

Le Master

Le Master est un service de déclaration et d’enregistrement des nœuds qui permet ainsi à des nœuds de se connaitre et d’échanger de l’information. Le Master est implémenté via XMLRPC.

Le Master comprend une sous-partie très utilisée qui est le Parameter Server. Celui-ci, également implémenté sous forme de XMLRPC, comme son nom l’indique est une sorte de base de données centralisée dans laquelle les nœuds peuvent stocker de l’information et ainsi partager des paramètres globaux.

Les topics

L’échange de l’information s’effectue soit de manière asynchrone via un topic ou de manière synchrone via un service.

Un topic est un système de transport de l’information basé sur le système de l’abonnement / publication (subscribe / publish). Un ou plusieurs nœuds pourront publier de l’information sur un topic et un ou plusieurs nœuds pourront lire l’information sur ce topic. Le topic est en quelque sorte un bus d’information asynchrone un peu comme un flux RSS. Cette notion de bus many-to-many asynchrone est essentielle dans le cas d’un système distribué.

Le topic est typé, c’est-à-dire que le type d’information qui est publiée (le message) est toujours structuré de la même manière. Les nœuds envoient ou reçoivent des messages sur des topics.

Les messages

Un message est une structure de donnée composite. Un message est composé d’une combinaison de types primitifs (chaines de caractères, booléens, entiers, flottants…) et de message (le message est une structure récursive). Par exemple un nœud représentant un servomoteur du robot, publiera certainement son état sur un topic (selon ce que vous aurez programmé) avec un message contenant par exemple un entier représentant la position du moteur, un flottant représentant sa température, un autre flottant représentant sa vitesse…

La description des messages est stockée dans nom_package/msg/monMessageType.msg. Ce fichier décrit la structure des messages.

Les services

Le topic est un mode de communication asynchrone permettant une communication many-to- many. Le service en revanche répond à une autre nécessité, celle d’une communication synchrone entre deux nœuds. Cette notion se rapproche de la notion d’appel de procédure distante (remote procedure call).

La description des services est stockée dans nom_package/srv/monServiceType.srv. Ce fichier décrit les structures de données des requêtes et des réponses.

Les bags

Les « bags » sont des formats pour stocker et rejouer les messages échangés. Ce système permet de collecter par exemple les données mesurées par les capteurs et les rejouer ensuite autant de fois qu’on le souhaite afin de faire de la simulation sur des données réelles. Ce système est également très utile pour déboguer un système a posteriori.

L’outil rxbag permet de visualiser graphiquement les données enregistrées dans les fichiers bag.

URDF

ROS propose d’autres notions que nous pourrons découvrir à l’occasion d’un nouvel article. Citons néanmoins une (autre) contribution intéressante de ROS à la robotique. Il s’agit de l’urdf (Unified Robot Description Format), un format XML permettant de décrire sous la forme d’un fichier standardisé un robot complet. Le robot ainsi décrit peut être statique ou dynamique et des propriétés physiques et de collision peuvent y être ajoutées.

Outre le standard, ROS propose plusieurs outils permettant de générer, parser ou valider ce format.

L’URDF est utilisé par exemple par le simulateur Gazebo pour représenter le robot.

ROS2

A l’origine, ROS a été développé pour le monde académique (recherche, éducation supérieure). Cet écosystème n’est donc pas aligné sur les normes de productions commerciales.

Une nouvelle version, ROS2, a été lancée en 2017. Cette version comble les lacunes de ROS en termes de sécurité et de fiabilité notamment. ROS2 apporte une qualité de service, la prise en charge des systèmes intégrés et des scénarios en temps réel.

Nous avons rédigé un article détaillé intitulé “ROS2 : qu’est-ce qui change par rapport à ROS ?”, que nous vous invitons à lire, si vous souhaitez en savoir plus sur ROS2.

De nombreux outils très utiles dans ROS

Comme nous l’avons dit plus haut, ROS est une collection d’outils et d’algorithmes. Certains sont très utilisés lors de la programmation, de la simulation ou de l’exécution des comportements des robots. Citons quelques outils ou algorithmes que le programmeur de ROS retrouvera souvent :

• Stage : un simulateur 2D
• Gazebo : un simulateur 3D
• Rviz : un système de visualisation 3D (contrairement à Gazebo, il n’inclut pas de moteur physique)
• Le package tf qui permet de manipuler des coordonnées et des transformations (si vous avez déjà eu à faire de la cinématique inverse et à manipuler des matrices, alors ce package va grandement vous faciliter la vie).
• Opencv : traitement d’images
• PointCloudLibrary : reconstruction d’environnement 3D à partir de mesures d’un laser

Les API standards de ROS sont disponibles à l’adresse : http://www.ros.org/wiki/APIs

Ressources

• www.ros.org