ROS, pour Robot Operating System, est un ensemble gratuit et open source de bibliothèques et d’outils servant à développer des logiciels pour robots. Malgré son nom, ce n’est pas un système d’exploitation comme Windows ou Linux. Il fonctionne par-dessus un tel système, le plus souvent Ubuntu Linux, et donne aux nombreux programmes d’un robot un moyen commun d’échanger des données, de partager des pilotes et de réutiliser le travail des autres.

Ce nom prête beaucoup à confusion, d’où l’intérêt de bien délimiter ce que couvre ROS. Il excelle à organiser tout ce qui se passe à l’intérieur d’un robot : le scanner laser, les roues, la carte, le planificateur. Il couvre bien moins le bâtiment où le robot travaille, avec ses portes, ses ascenseurs, ses capteurs et les personnes qui doivent être prévenues en cas de problème. Savoir où s’arrête l’un et où commence l’autre est une question très concrète pour quiconque déploie des robots hors d’un laboratoire.

L’essentiel

  • ROS est un middleware : un système de messagerie, un ensemble de conventions et une vaste bibliothèque de paquets réutilisables qui tournent sur un système d’exploitation classique.
  • Dans un robot, de petits programmes appelés nœuds publient des flux de données nommés, les topics, et s’y abonnent : un pilote de lidar et un planificateur de navigation écrits par des personnes différentes peuvent ainsi fonctionner ensemble.
  • ROS 2 est la génération actuelle ; ROS 1 est arrivé en fin de vie en mai 2025, et les nouveaux projets démarrent donc sur une version LTS (support à long terme) de ROS 2.
  • ROS coordonne les composants d’un robot. Relier ce robot aux portes, capteurs et alarmes d’un site demande une couche distincte, placée au-dessus.

Qu’est-ce que le Robot Operating System (ROS) ?

Un robot, c’est un assemblage de matériel venu de différents fabricants : un scanner laser d’un fournisseur, des variateurs moteur d’un autre, des caméras, des capteurs de choc, une carte de gestion de batterie. Chaque composant a sa propre interface. Avant ROS, chaque laboratoire et chaque entreprise écrivait son propre code de liaison pour faire dialoguer ces éléments, et presque rien n’était réutilisable sur le robot suivant.

Un système d’exploitation pour robots résout ce problème en se plaçant entre les pilotes matériels et le comportement du robot. Il offre aux programmes une manière standard de s’envoyer des données : le code qui lit le laser n’a pas besoin de savoir qui exploite ses mesures. Il définit des formats de message standard pour les données courantes, comme un balayage laser, une image de caméra ou une consigne de vitesse. Et il fournit des outils pour enregistrer les données, visualiser ce que voit le robot et le simuler avant de passer sur le vrai matériel.

L’appellation « système d’exploitation » est une métaphore. De même qu’un système d’exploitation permet aux applications d’ignorer quel disque ou quelle carte réseau équipe l’ordinateur, ROS permet au logiciel du robot d’ignorer la marque du scanner fixé dessus, du moment qu’un pilote publie le message standard.

ROS est né en 2007, avec des premiers travaux à Stanford et un développement au sein de l’entreprise de robotique Willow Garage. Il est aujourd’hui porté par Open Robotics et l’Open Source Robotics Foundation, avec une large communauté d’entreprises et d’universités qui développent des paquets. Parmi les plus connus figurent Nav2, la pile de navigation pour robots mobiles, et MoveIt, qui planifie les mouvements des bras robotisés.

Comment fonctionne ROS en robotique ?

Le plus simple est de suivre un robot en particulier. Prenons un robot de livraison qui transporte des fournitures dans un couloir d’hôpital.

  1. Un nœud pilote lit le scanner laser et publie chaque balayage sur un topic nommé /scan, environ dix à quarante fois par seconde selon le capteur.
  2. Un nœud de localisation s’abonne à /scan et à l’odométrie des roues, les compare à une carte enregistrée et publie la position où le robot pense se trouver.
  3. La pile de navigation reçoit un objectif, comme « aller au service 3 », planifie un chemin qui contourne les obstacles du dernier balayage et publie des consignes de vitesse sur un topic nommé /cmd_vel.
  4. Un nœud de commande moteur s’abonne à /cmd_vel et convertit ces consignes en vitesses de roues.

Aucun de ces nœuds n’appelle directement les autres. Ils s’accordent seulement sur les noms de topics et les types de messages : pour changer de modèle de scanner laser, il suffit donc de remplacer un nœud pilote.

Les topics conviennent aux flux continus. ROS propose deux autres mécanismes pour d’autres usages. Un service est une requête-réponse rapide, comme « enregistrer la carte actuelle ». Une action est un objectif de longue durée, avec un retour sur sa progression et la possibilité de l’annuler : c’est généralement ainsi qu’on envoie « aller au service 3 ». Les paramètres configurent les nœuds, et les fichiers de lancement démarrent tout un ensemble de nœuds en une seule commande.

Un dernier élément accomplit un gros travail en coulisses : tf2, la bibliothèque de transformations. Chaque capteur est monté à un endroit précis du robot, et chaque carte a sa propre origine. tf2 suit dans le temps les relations entre tous ces repères : quand la caméra voit un obstacle à 1,2 mètre devant et 30 centimètres à gauche, le planificateur peut le convertir en position sur la carte sans que chaque nœud refasse ses propres calculs géométriques.

Autour de ce noyau gravitent les outils du quotidien : RViz pour visualiser en 3D les données des capteurs et les trajectoires prévues du robot, rosbag pour enregistrer et rejouer des topics, et le simulateur Gazebo pour tester un robot dans un monde virtuel.

Dans ROS 2, la couche de messagerie repose sur DDS (Data Distribution Service), une norme industrielle de publication/abonnement. Les nœuds se découvrent sur le réseau sans le processus maître central dont ROS 1 avait besoin, et chaque topic peut porter des réglages de qualité de service, par exemple pour indiquer si les messages perdus doivent être renvoyés.

ROS 1 ou ROS 2 : quelle version choisir ?

La plupart des équipes qui démarrent aujourd’hui savent déjà qu’elles utiliseront ROS. Il leur reste à choisir la génération et la version, et à décider si certaines parties du robot doivent tourner sur autre chose.

ROS 1 ROS 2
Statut Dernière version Noetic, fin de vie en mai 2025 Développement actif, nouvelle version chaque mois de mai
Messagerie Protocole spécifique avec un maître central DDS, sans point de défaillance unique
Support à long terme Aucun désormais Versions LTS maintenues cinq ans, par exemple Jazzy Jalisco jusqu’en 2029
Sécurité Pas de sécurisation native des échanges SROS2 ajoute le chiffrement et le contrôle d’accès
Pour qui Maintenance de robots existants Nouveaux projets et produits

En pratique, quelques questions orientent le choix :

  • Pilotes. Le fabricant de votre capteur ou de votre bras fournit-il un pilote ROS 2 ? Un pilote manquant peut coûter plus de temps que tout le reste réuni.
  • Rythme des versions. Une nouvelle version de ROS 2 sort chaque mois de mai. Celles des années paires sont maintenues cinq ans, les autres environ un an et demi : les produits se fixent donc généralement sur une version LTS et planifient le passage à la suivante.
  • Petit matériel. micro-ROS apporte les concepts de ROS 2 aux microcontrôleurs, si bien qu’une carte capteur peut rejoindre directement les topics du robot.
  • Bras industriels. Beaucoup de bras industriels se programment via le contrôleur et le langage propres au fabricant. ROS se place souvent à côté de ce contrôleur plutôt que de le remplacer, une approche sur laquelle le consortium ROS-Industrial travaille depuis des années.

Pensez aussi au réseau dès le départ. DDS découvre les nœuds automatiquement, ce qui est pratique sur un banc d’essai mais génère beaucoup de trafic parasite sur un réseau d’entreprise partagé par de nombreux robots. Les équipes séparent généralement les robots avec des identifiants de domaine DDS, limitent la découverte à des hôtes connus et activent SROS2 avant qu’un robot ne quitte le laboratoire.

Certaines entreprises s’appuient sur ROS 2 en y ajoutant leurs propres couches, comme les paquets Isaac ROS de NVIDIA pour la perception accélérée par GPU. D’autres conservent une pile logicielle propriétaire et n’exposent qu’une interface vers l’extérieur. Les deux approches sont courantes, et la seconde prend toute son importance quand le robot doit fonctionner avec le reste du site.

Comment connecter ROS à des appareils IoT ?

ROS a été conçu pour l’intérieur d’un robot, ou pour une flotte sur un même réseau. Un bâtiment ou une usine compte un second ensemble d’appareils que le robot ne peut pas percevoir : un contact de porte à l’autre bout de l’entrepôt, un détecteur de fuite dans un local technique, l’état d’une porte coupe-feu, une mesure de qualité de l’air dans un service hospitalier. Ces appareils communiquent généralement en LoRaWAN, MQTT, Modbus ou BACnet, pas en topics ROS.

Il existe des passerelles bien connues. rosbridge expose les topics ROS en JSON via WebSockets, des paquets communautaires relaient des topics choisis vers et depuis des brokers MQTT, et Open-RMF, l’Open Robotics Middleware Framework, coordonne plusieurs flottes de robots avec des infrastructures partagées comme les portes et les ascenseurs. Ces outils règlent le transport. Décider quel événement de capteur doit envoyer quel robot à quel endroit, et tester cette logique avant qu’elle ne tourne sur un vrai site, c’est un autre travail.

Mieux vaut décider tôt de ce qui franchit cette frontière. Les topics bruts, comme les balayages laser et les images de caméra, sont bien trop bavards et détaillés pour les systèmes du site. Ce dont le reste du site a besoin, c’est d’un petit ensemble stable de faits et de requêtes : la position du robot sur le plan du site, son niveau de batterie, l’état de sa mission en cours et quelques tâches qu’il accepte, comme se rendre à un endroit nommé, rejoindre sa station de charge ou se mettre en pause. Avec une interface aussi réduite, l’équipe robotique peut tout modifier dans ROS sans casser la logique du site.

Cette couche de décision, c’est précisément ce qu’ajoute un système d’exploitation pour l’IA physique au-dessus de ROS, et c’est cette couche que nous construisons avec Kilo. Si l’intégration du robot expose quelques commandes via MQTT, par exemple « aller au point de passage » ou « retour à la station », vous pouvez les enregistrer dans Kilo et laisser une règle en envoyer une quand un capteur situé ailleurs sur le site signale un événement, pendant que ROS continue de gérer la navigation à bord. Chaque commande envoyée ainsi apparaît dans son historique avec le statut En attente, Livré, Confirmé, Avertissement léger ou Échoué.

Comme ces commandes font bouger une vraie machine, vous testez d’abord la règle à blanc : parcourez-la pas à pas dans le débogueur de Kilo en simulant la réponse du robot, pour voir chaque scénario se dérouler avant tout déploiement.

Questions fréquentes sur ROS

ROS est-il gratuit ?

Oui. ROS est open source, sous des licences permissives qui autorisent un usage commercial sans frais de licence. Restent à payer le temps d’ingénierie, le matériel et, le cas échéant, un contrat de support commercial qu’une entreprise choisit de souscrire auprès d’une des sociétés qui proposent du conseil ROS.

Quel langage de programmation utilise ROS ?

Les deux bibliothèques clientes officielles sont en C++ (rclcpp) et en Python (rclpy), et un même robot combine souvent les deux. Des bibliothèques communautaires existent pour Rust, Java et d’autres langages, et les types de messages sont définis dans de simples fichiers d’interface à partir desquels le code est généré pour chaque langage.

Peut-on utiliser ROS sous Windows ?

ROS 2 compte Windows parmi ses plateformes prises en charge, aux côtés d’Ubuntu Linux, et chaque version précise ses niveaux de support exacts dans un document appelé REP 2000. La plupart des tutoriels, des pilotes et des robots en production restent toutefois sous Ubuntu : Linux demeure donc la voie la plus simple.

ROS 2 est-il un système temps réel ?

Pas à lui seul. ROS 2 a été conçu pour pouvoir servir dans des systèmes temps réel, mais il faut aussi un noyau temps réel, comme Linux avec le patch PREEMPT_RT, une configuration soignée de la mémoire et des threads, et un matériel qui respecte ses contraintes de temps. Le framework ros2_control est la solution habituelle pour exécuter, dans ROS 2, les boucles de commande aux contraintes de temps strictes des bras et des roues.

Un robot ROS 2 déjà en service suffit pour un premier essai, à petite échelle, côté site. Utilisez l’une des passerelles communautaires pour publier trois de ses topics vers MQTT, par exemple le niveau de batterie, l’état de la mission et la position, enregistrez le robot comme un appareil dans Kilo et affichez ces trois valeurs dans un tableau de bord. Ajoutez ensuite une règle qui vous alerte quand la batterie passe sous 20 % alors qu’une mission est encore en cours. Cela fait un seul appareil et une seule règle, largement dans les limites de l’offre gratuite, et rien ne change sur le robot à part la passerelle.