Logiciels & applications

ROS en robotique : des capteurs aux commandes, comprendre ce qui relie les modules

25 octobre 2026 Élise Carpentier-Drouin 7 min de lecture

ROS, pour Robot Operating System, est un ensemble de bibliothèques, d’outils et de conventions qui facilite le développement de robots. Il permet de faire communiquer une caméra, un algorithme de navigation et des moteurs sans réécrire toute l’infrastructure logicielle. Malgré son nom, ROS n’est pas un système d’exploitation classique : il fonctionne au-dessus d’un système comme Linux et organise les échanges entre les composants du robot.

Table des matières

Une infrastructure commune plutôt qu’un logiciel qui fait tout

Développé à partir de 2007, ROS répond à une difficulté centrale en robotique : assembler des matériels et des logiciels très différents. Un robot mobile doit acquérir des mesures, estimer sa position, reconnaître des obstacles et commander ses roues. ROS fournit les interfaces nécessaires pour relier ces fonctions, mais ne réalise pas automatiquement chacune d’elles.

Son principe d’abstraction du matériel limite la dépendance des algorithmes à un équipement particulier. Si deux pilotes de caméras exposent des interfaces compatibles, un même traitement d’image peut être réutilisé avec l’une ou l’autre. Cela suppose toutefois de vérifier les formats, les repères et les caractéristiques des données.

Les composants sont regroupés en packages, qui peuvent contenir du code, des configurations, des interfaces de messages ou des fichiers de lancement. L’écosystème open source facilite ainsi la réutilisation de pilotes et d’algorithmes, avec une qualité et une maintenance à évaluer pour chaque package.

En recherche, cette modularité aide à comparer plusieurs méthodes de perception. En logistique, elle relie localisation, planification et déplacement d’un robot mobile. Dans l’industrie ou la robotique domestique, elle facilite l’intégration de capteurs et de fonctions de manipulation. Elle ne dispense jamais de valider le comportement réel ni la sécurité de la machine.

Du capteur à l’actionneur : suivre le trajet des messages

Un système ROS se compose de nœuds, c’est-à-dire de composants logiciels chargés de tâches distinctes. Un nœud peut lire une caméra, un autre détecter des objets et un troisième calculer une commande. Ces traitements peuvent fonctionner sur un même ordinateur ou être répartis entre plusieurs machines.

Schéma d’architecture ROS robotique reliant capteurs, nœuds, topics, RViz, Gazebo et actionneurs

Topics, services et actions répondent à des besoins différents

Un topic est un canal nommé sur lequel un nœud publie des messages typés. D’autres nœuds s’y abonnent sans que le producteur ait besoin de les connaître individuellement. Ce modèle publication-abonnement convient aux flux continus : images, mesures de distance ou estimations de position.

Un service fonctionne en requête-réponse, par exemple pour demander une information ponctuelle. Une action convient plutôt à une opération longue, comme rejoindre une destination, avec suivi de progression et possibilité d’annulation. Les paramètres règlent quant à eux le comportement d’un nœud, tandis que les fichiers de lancement démarrent et configurent plusieurs composants ensemble.

La séparation des modules devient un levier de diagnostic : en enregistrant les messages d’un capteur, on peut rejouer exactement la même scène devant deux versions d’un algorithme. Le robot n’a plus besoin de refaire le parcours pour chaque essai. Cette répétabilité permet de distinguer une régression logicielle d’une variation de lumière, de trajectoire ou d’environnement.

Visualiser n’est pas simuler

RViz affiche les données disponibles : images, nuages de points, trajectoires et repères du robot. Il aide à comprendre ce que le système perçoit. Gazebo simule un robot et son environnement, avec des interactions physiques et des capteurs simulés. Les deux outils sont complémentaires : une simulation peut fournir les données ensuite observées dans RViz.

ROS 1 ou ROS 2 : choisir une base adaptée au projet

Pour un nouveau développement, ROS 2 constitue généralement le point de départ à privilégier. ROS 1 reste présent dans des installations existantes et certains projets de recherche. Le choix dépend surtout des pilotes indispensables, des packages disponibles et des contraintes de maintenance.

Critère	ROS 1	ROS 2
Communication	Découverte reposant sur un maître central	Architecture généralement fondée sur DDS, sans maître central
Python	Client rospy	Client rclpy
Qualité de service	Réglages plus limités	Politiques QoS de fiabilité, d’historique et de durabilité
Temps réel	Contraintes plus difficiles à traiter	Mécanismes mieux adaptés, sans garantie automatique
Sécurité	Protections à construire autour du système	Mécanismes fondés sur DDS Security, à configurer
Choix pratique	Maintien d’un existant compatible	Nouveau projet et architecture distribuée évolutive

ROS utilise principalement Python et C++. Python facilite le prototypage et l’intégration d’algorithmes ; C++ convient notamment aux composants nécessitant un contrôle plus fin des ressources. Le langage ne suffit cependant pas à garantir une faible latence ou un fonctionnement déterministe.

La compatibilité dépend de la distribution ROS choisie. Ubuntu est un environnement courant ; d’autres configurations concernent notamment Debian, RHEL, Windows ou macOS, avec des niveaux de support variables. Il faut vérifier le couple système-distribution ainsi que l’architecture matérielle, par exemple AMD64 ou ARM64, avant d’installer des dépendances.

Un premier démarrage qui permet de vérifier chaque couche

La documentation officielle ROS propose des parcours par distribution. Mieux vaut suivre celui qui correspond exactement à son environnement plutôt que mélanger des commandes issues de tutoriels différents. Une installation minimale suffit pour apprendre la communication ; une installation de bureau apporte davantage d’outils de visualisation.

Choisir une distribution maintenue et vérifier les plateformes ainsi que les pilotes pris en charge.
Installer ROS et charger son environnement dans le terminal utilisé pour les essais.
Lancer les exemples de publication et d’abonnement afin de confirmer que deux nœuds échangent correctement.
Créer un workspace, puis un package Python ou C++ contenant son premier nœud.
Compiler et charger le workspace, puis lancer le nœud et inspecter son topic.

En ROS 2, un premier nœud Python avec rclpy peut publier périodiquement une chaîne de caractères. Les commandes ros2 node list, ros2 topic list et ros2 topic echo /nom_du_topic permettent ensuite de vérifier sa présence et ses messages. Cette étape simple valide l’environnement avant d’ajouter une caméra ou un modèle d’intelligence artificielle.

Si les messages n’arrivent pas, contrôlez d’abord le nom du topic, son type et l’environnement chargé. Sur plusieurs machines, vérifiez aussi le réseau et le domaine ROS. En ROS 2, des politiques QoS incompatibles peuvent empêcher un abonnement de recevoir les données, même lorsque les nœuds sont visibles.

Brancher YOLO, une caméra et la profondeur sans perdre le sens des données

Pour intégrer YOLO, le chemin habituel consiste à recevoir une image ROS, la convertir en tableau exploitable, exécuter la détection ou la segmentation, puis republier les résultats. Un flux couleur peut être diffusé sur /camera/color/image_raw avec le type sensor_msgs/Image. Le modèle de vision est un traitement au sein de cette chaîne, pas un remplacement de ROS.

Avec ROS 2, cv_bridge assure la conversion entre les messages d’image et les représentations utilisées avec OpenCV. Dans des intégrations ROS 1, ros_numpy peut convertir certains messages en tableaux NumPy. Il faut contrôler l’encodage RGB ou BGR pour éviter une interprétation incorrecte des couleurs.

Une image de profondeur fournit une distance par pixel, selon l’encodage et les unités du capteur. Pour associer cette distance à une détection, les images couleur et profondeur doivent être correctement alignées et synchronisées. Une boîte de détection seule ne donne donc pas directement une position fiable dans l’espace.

Les nuages de points, souvent transportés avec sensor_msgs/PointCloud2, décrivent des points en trois dimensions. En ROS 2, sensor_msgs_py.point_cloud2 aide à accéder à leurs données. Avant toute commande du robot, vérifiez les horodatages, les repères et la validité des mesures. Une perception convaincante à l’écran ne suffit pas à garantir une action sûre.