Parcours gratuit · étape 1 sur 3 · sans prérequis · 6 chapitres
Middlewares et robotique : ce qui relie le logiciel au robot
Un robot mobile, un drone ou une voiture autonome sont faits de dizaines de programmes qui doivent se parler en temps réel. Le middleware est la couche qui rend cela possible. Voici comment on en est arrivé à ROS 2, Cyber RT et les autres, et pourquoi chaque famille de robots a ses habitudes.
Chapitre 1
Pourquoi un middleware ?
Un robot n'est pas un programme : c'est un ensemble de programmes. Un pilote lit le lidar, un autre la caméra, un troisième estime la position, un quatrième planifie la trajectoire et un dernier envoie les consignes aux moteurs. Le middleware leur donne une façon commune de s'échanger des messages, de se découvrir sur le réseau et de tenir des délais, sans que chacun connaisse les autres.
- Missionlivrer un colis, inspecter un champ, suivre une voie
- Fonctionsperception · localisation · planification · contrôle
- Middlewaremessages (topics), requêtes (services), découverte, qualité de service, enregistrement et rejeu
- Piloteslidar, caméra, IMU, GPS, variateurs
- Matérielcapteurs, moteurs, calculateur embarqué
Sans middleware, chaque programme devrait savoir où trouver chacun des autres, dans quel format lui écrire et quoi faire s'il ne répond pas. Avec cinq programmes, cela fait déjà dix liaisons à maintenir à la main. Le middleware remplace ces liaisons par un point de rendez-vous commun :
Chaque programme publie ce qu'il sait et lit ce dont il a besoin.
Un pilote ou un planificateur écrit une fois sert sur plusieurs robots.
On enregistre les messages, on les rejoue, on simule avant de rouler.
Chapitre 2
Trois façons de se parler
Presque tous les middlewares de la robotique proposent les mêmes trois façons d'échanger. Les reconnaître, c'est déjà savoir lire l'architecture d'un robot.
Pour ce qui coule en continu : mesures des capteurs, position, commandes de vitesse. L'émetteur ne sait pas qui écoute.
Pour une demande ponctuelle et rapide : lire un niveau de batterie, changer un mode. Le client attend la réponse.
Pour une tâche qui prend du temps : aller à un quai, saisir un objet. On suit l'avancement, et on peut annuler.
À retenir : devant un besoin de communication, demandez-vous si l'information coule en continu (topic), si l'on attend une réponse immédiate (service), ou si c'est une tâche longue à suivre (action).
Chapitre 3
Se trouver et tenir les délais
Deux questions se posent dès que les programmes tournent sur plusieurs ordinateurs : comment se trouvent-ils, et que faire quand le réseau perd un message ? ROS 1 répondait à la première avec un serveur central. ROS 2 s'appuie sur DDS, un standard de l'industrie, où chaque programme s'annonce lui-même sur le réseau.
Pour la seconde question, ROS 2 laisse régler la qualité de service de chaque topic. Les deux réglages qu'on rencontre le plus :
En mode fiable (reliable), un message perdu est renvoyé : c'est le choix pour une commande. Au mieux (best effort), on ne renvoie rien : un scan laser perdu sera remplacé par le suivant, un dixième de seconde plus tard.
Une carte ou la description du robot se publient une fois. En les gardant pour les retardataires (transient local), un nœud démarré après coup les reçoit quand même.
À retenir : pas de serveur central en ROS 2, et chaque topic choisit son compromis entre fiabilité et fraîcheur. Le module bonus « La qualité de service (QoS) » du parcours ROS 2 le met en pratique.
Chapitre 4
Une courte histoire
- Début des années 2000 · Player/Stage
Un serveur qui expose les capteurs et les moteurs d'un robot sur le réseau, et un simulateur 2D. Les laboratoires commencent à partager du code d'un robot à l'autre.
- 2007 · ROS
Né à Stanford puis développé chez Willow Garage. Nœuds, topics, services et un écosystème de packages ouvert : ROS devient la référence de la recherche.
- 2017 · ROS 2
Après des versions alpha dès 2015, la première distribution, Ardent Apalone, sort en décembre 2017. ROS 2 repose sur DDS, un standard industriel de communication : plus de serveur central, qualité de service réglable, plusieurs robots sur un même réseau. Pensé pour les produits, pas seulement les labos.
- Apollo 3.5 · Cyber RT
Avec la version 3.5 de sa plateforme de conduite autonome Apollo, Baidu introduit Cyber RT, un nouveau cadre d'exécution « conçu spécifiquement pour la conduite autonome ».
- Aujourd'hui
Les distributions ROS 2 maintenues incluent Jazzy Jalisco (2024) et Lyrical Luth (2026). ROS 2 s'étend jusqu'aux microcontrôleurs avec micro-ROS et, depuis PX4 v1.14, dialogue avec l'autopilote de drone via uXRCE-DDS. Les middlewares spécialisés restent là où ils excellent.
Chapitre 5
Le paysage aujourd'hui
Le standard ouvert le plus répandu. Communication DDS, outils (RViz, rosbag), et de grandes briques comme Nav2 pour la navigation et MoveIt 2 pour les bras.
Le cadre d'exécution open source d'Apollo, pensé pour la conduite autonome : calcul centralisé, forte concurrence, faible latence et débit de données élevé.
ROS 2 sur microcontrôleur (FreeRTOS, Zephyr) : un agent micro-ROS relie la carte moteur ou capteur au reste du graphe.
uORB est l'API asynchrone publier / s'abonner interne à l'autopilote. Depuis la v1.14, uXRCE-DDS publie ses messages comme des topics ROS 2 sur l'ordinateur de bord.
« Yet Another Robot Platform » : bibliothèque de communication et d'interfaces matérielles, issue de l'IIT et du consortium RobotCub (iCub), utilisée des humanoïdes aux systèmes embarqués.
Orocos Real-Time Toolkit : des composants temps réel pour la commande de machines et de bras.
À retenir : les concepts se ressemblent partout (publier, s'abonner, appeler un service, régler la qualité de service). Celui qui les maîtrise dans ROS 2 s'adapte vite aux autres.
Chapitre 6
Un middleware par type de robot
Le choix dépend des contraintes : temps réel, puissance de calcul embarquée, certification, taille de l'écosystème. Voici les associations les plus courantes.
| Robot | Middleware courant | Ce qui compte |
|---|---|---|
| Robot mobile | ROS 2 et Nav2 | cartographie, localisation, évitement d'obstacles |
| Drone | PX4 (uORB), relié à ROS 2 | boucle de vol temps réel séparée de la mission |
| Véhicule autonome | Cyber RT (Apollo), Autoware sur ROS 2 | latence, volumes de données, sûreté |
| Bras robotique | ROS 2 et MoveIt 2, OROCOS pour la commande | cinématique, planification de trajectoire, boucles rapides |
| Humanoïde | YARP (iCub), ROS 2 et ros2_control | beaucoup d'articulations, équilibre, synchronisation |
Sources officielles
Testez-vous
Quatre questions pour vérifier ce que vous avez retenu. Réfléchissez, puis ouvrez la réponse.
Le lidar envoie ses mesures dix fois par seconde à trois programmes. Topic, service ou action ?
Un topic. L'information coule en continu, sans réponse attendue, vers autant d'abonnés que nécessaire.
Le robot doit traverser l'entrepôt jusqu'au quai 4, en donnant des nouvelles. Topic, service ou action ?
Une action. C'est une tâche longue : un but, des nouvelles en route, un résultat, et la possibilité d'annuler.
Pourquoi ROS 2 n'a-t-il plus besoin de roscore ?
Parce qu'il repose sur DDS : chaque nœud s'annonce lui-même sur le réseau, et les nœuds se découvrent entre eux. Il n'y a plus de serveur central dont l'arrêt paralyserait le robot.
Un scan laser se perd sur le Wi-Fi. Faut-il absolument le renvoyer ?
Non. Un nouveau scan arrive un dixième de seconde plus tard : le mode « au mieux » (best effort) suffit. Une commande ou une carte, en revanche, se publient en mode fiable.
Voir ROS 2 de près, gratuitement
L'étape suivante du parcours gratuit ouvre ROS 2 : le robot vu comme un graphe, les messages, un premier nœud en Python, et le chemin du code jusqu'au robot.