Fondements de ROS 2 : nœuds, repères et vision robotique
Vous savez structurer un robot en nœuds ROS 2, choisir correctement entre topics, services et actions, et placer les observations d'une caméra dans l'arbre des repères du robot.
Tout le reste de ce site tourne sur microcontrôleur : un programme, une boucle, un contrôle total. ROS 2 est ce vers quoi on va quand un robot dépasse cela — quand il a une caméra, un planificateur et une pile de pilotes à faire tourner à la fois, écrits par des gens différents, redémarrables indépendamment.
Le prix est un nouvel ensemble d’idées, dont la première est qu’un robot ROS 2 n’est pas un programme mais un graphe de nœuds qui se parlent. L’essentiel de la confusion initiale vient de mal choisir entre les quatre façons de se parler, donc ce parcours commence là : topics pour les flux, services pour les requêtes rapides, actions pour les longs travaux éventuellement annulables.
Puis TF2, la partie qui bat les gens en silence. Un robot est un arbre de repères de coordonnées — la base, les roues, chaque capteur — et presque chaque vrai bogue est une transformation manquante, périmée, ou rattachée au mauvais parent. Une fois les repères compris, une caméra étalonnée devient juste un nœud de plus publiant une pose dans cet arbre, et c’est exactement ainsi que la vision rejoint le reste du robot.
Avant de commencer
Il faut être à l’aise en ligne de commande Linux et savoir lire Python ou C++. Un Raspberry Pi est la cible habituelle, mais tout jusqu’aux nœuds matériels tourne sur un portable. Prévoyez une soirée pour l’installation elle-même — ROS 2 est un système distribué, qui se comporte comme tel dès la première commande.
Ce que vous saurez faire
- Choisir correctement entre topic, service et action, plutôt que de tout faire en topic et d’en découvrir les limites plus tard.
- Construire un arbre de repères TF2 qui transforme un point du repère d’un capteur vers celui du robot, et le diagnostiquer quand une transformation manque.
- Étalonner une caméra, obtenir la pose d’un marqueur, et comprendre par rapport à quoi sont les nombres.
- Convertir une consigne
cmd_velen vitesses de roues gauche et droite, avec une saturation qui préserve l’arc commandé.
Où l’on se heurte
Les nœuds ne se voient pas. La découverte ROS 2 est automatique jusqu’à ce qu’elle ne le soit plus. Deux
machines sous des valeurs ROS_DOMAIN_ID différentes sont invisibles l’une à l’autre, et un Wi-Fi bloquant le
multicast casse entièrement la découverte pendant que chaque nœud se déclare en parfaite santé.
QoS désaccordé. Un publicateur en best-effort et un abonné exigeant du reliable ne se connecteront jamais, et — sans aider — aucun ne journalise d’erreur. Le topic ne transporte simplement rien. Les données capteurs sont le coupable habituel, car les pilotes de capteurs utilisent souvent best-effort par défaut.
Oublier de sourcer l’espace de travail. Un nouveau terminal ignore vos paquets jusqu’à
être sourcé, donc ros2 run annonce comme manquant un paquet pourtant bien présent.
Un repère à deux parents. TF2 est un arbre. Publier le même repère enfant depuis deux sources lui donne deux parents, et les résolutions échouent par intermittence selon la temporisation — l’un des bogues ROS les plus difficiles à voir, car ça fonctionne la plupart du temps.
Horodatages et identifiants de repères vides. Un message dont l’en-tête n’a pas de frame_id ne peut être
transformé, et un horodatage nul ne s’alignera avec rien. Les deux traversent le
système de types sans plainte et n’échouent que quand quelque chose tente de les utiliser ensemble.
Ce qu’il vous faut
| Quoi | Pourquoi ce parcours en a besoin | Notes |
|---|---|---|
| Une ligne de commande Linux maîtrisée | ROS 2 est un système d’abord Linux et l’outillage le suppose | Ubuntu correspond aux binaires officiels ; tout autre choix signifie compiler |
| Python ou C++ | Le code des nœuds s’écrit dans l’un des deux | Python est plus rapide pour apprendre ; C++ est ce qu’utilisent les nœuds critiques en performance |
| Une machine avec un vrai écran | Diagnostiquer un système distribué en SSH est inutilement pénible | Un portable est une meilleure cible d’apprentissage qu’un Pi sans écran |
| Un Raspberry Pi (nœuds matériels seulement) | Nécessaire seulement quand le robot embarque son propre ordinateur | Pi 4 ou mieux ; un Pi Zero décevra |
| Une caméra (nœud vision seulement) | Le dernier nœud du parcours | Un module Pi Camera ou toute webcam UVC |
| Une soirée pour l’installation | Sans blague — cela fait partie du parcours | L’installation est vraiment la première étape difficile |
Pourquoi le parcours suit cet ordre
Les motifs de communication viennent en premier car mal choisir coûte cher ensuite. Les quatre façons dont les nœuds ROS 2 se parlent ne sont pas interchangeables, et l’échec standard du débutant est de tout faire en topic — puis de découvrir, trois cents lignes plus loin, qu’il fallait l’annulation et le retour d’avancement et qu’on réimplémentait les actions à la main. Dix minutes à trancher entre topic, service et action économisent une réécriture.
TF2 vient deuxième car c’est la partie qui bat les gens en silence. Dès que plusieurs nœuds publient des données sur le monde physique, chacun veut dire « 3 mètres » par rapport à quelque chose de différent — la caméra, la base, la carte. TF2 est la façon dont ces repères se relient, et la majorité des vrais bogues ROS sont une transformation manquante, périmée, ou rattachée au mauvais parent. L’apprendre comme sujet, avant d’en avoir besoin, coûte bien moins cher que de le rencontrer comme une mystérieuse erreur de résolution.
L’étalonnage de caméra vient troisième car il dépend entièrement du deuxième. Une pose de marqueur ne veut rien dire sans savoir par rapport à quoi. Une fois les repères compris, une caméra étalonnée est juste un nœud de plus publiant une pose dans l’arbre, et la vision cesse d’être un cas particulier.
Le nœud de propulsion clôt le parcours car c’est là que ROS rencontre le matériel dont tout le reste de ce site traite. Une consigne cmd_vel est l’interface standard parlée par chaque composant de navigation ROS,
et la convertir en vitesses de roues gauche et droite — avec une saturation qui
préserve l’arc commandé plutôt que de le déformer — est le pont entre le monde ROS
et le monde des moteurs.
Étapes : comment savoir qu’une étape est acquise
| Étape | Le test | Ce à quoi ressemble la réussite |
|---|---|---|
| Installation | ros2 topic list dans un terminal frais |
Ça fonctionne après sourçage, et vous savez pourquoi ça échoue avant |
| Deux nœuds | Lancez parleur et auditeur sur deux machines | Les messages arrivent — et vous pouvez nommer l’identifiant de domaine partagé |
| Topic contre service | Écrivez l’un et l’autre pour les mêmes données | Vous pouvez dire en une phrase pourquoi chaque motif convient à son travail |
| Actions | Démarrez une longue action et annulez-la à mi-chemin | Elle s’arrête proprement, avec un retour d’avancement pendant l’exécution |
| QoS | Désaccordez délibérément la fiabilité sur un topic | Il ne transporte silencieusement rien — vous reconnaissez désormais le symptôme |
| Arbre TF2 | Lancez ros2 run tf2_tools view_frames |
Un arbre, une racine, aucun repère à deux parents |
| Résolution de transformation | Transformez un point d’un repère capteur vers le repère de base | Le nombre est bon, vérifiable au mètre ruban |
| Transformations périmées | Coupez un publicateur de transformation pendant une résolution | Vous obtenez une erreur d’extrapolation — l’échec a désormais un nom |
| Étalonnage de caméra | Étalonnez et vérifiez l’erreur de reprojection | Bien sous le pixel ; une grande valeur trahit une mauvaise série de captures |
| Pose de marqueur | Placez un marqueur à une distance mesurée et lisez sa pose | Conforme au mètre ruban, avec le repère énonçable |
cmd_vel |
Publiez une consigne avec termes linéaire et angulaire | Les deux roues tournent correctement, et saturer l’une met l’autre à l’échelle pour garder l’arc |
Où ce parcours s’arrête
Ce parcours construit les fondations sous un robot ROS 2 — comment les nœuds se parlent, comment les repères se relient, et comment un capteur et une transmission rejoignent le graphe. Il s’arrête délibérément avant les grands sous-systèmes qui supposent tout cela.
Il ne couvre pas la pile Nav2, réponse standard à la navigation autonome
en ROS 2 et système substantiel à part entière — cartes de coûts, arbres de comportement,
planificateurs et contrôleurs, tous configurés plutôt qu’écrits. Nav2 suppose un arbre TF
fonctionnel et une interface cmd_vel, exactement ce que donne ce parcours.
Il ne couvre pas URDF et la description robot, le format XML qui dit au reste de ROS quelle forme a votre robot. Tout ici publie les transformations à la main ; URDF est la façon d’arrêter de le faire.
Il ne couvre pas la simulation dans Gazebo, manière dont se fait vraiment l’essentiel du développement ROS sérieux, ni ros2_control, la couche standard d’abstraction matérielle pour vraies transmissions.
Et il ne couvre pas le comportement temps réel. ROS 2 est construit sur DDS et bien plus capable ici que ROS 1, mais une machine Linux faisant tourner un nœud Python n’est pas un système de commande temps réel. Les boucles serrées — équilibrage, commande de courant, tout au kilohertz — restent sur microcontrôleur, avec ROS 2 au-dessus. Cette division est l’architecture normale d’un robot sérieux, pas un compromis.
Parcours d'apprentissage
Le parcours
Suivez les nœuds dans l'ordre — chacun débloque le suivant une fois terminé. Votre progression est enregistrée sur cet appareil.
0 / 5 terminés
Questions courantes
Questions fréquentes
Quand un robot doit-il passer d'Arduino à ROS 2 ?
Quand une boucle cesse de suffire. Un microcontrôleur faisant tourner un programme unique est la bonne architecture pour un suiveur de ligne, un solveur de labyrinthe, ou tout ce dont tout le comportement tient dans une boucle de commande — et il est vraiment meilleur que ROS 2 pour cela, car déterministe et tenable en entier dans la tête. ROS 2 mérite sa complexité quand un robot a plusieurs choses à faire tourner à la fois à des rythmes différents — un pipeline caméra, un planificateur, une pile de pilotes — écrites à des moments différents, redémarrables indépendamment. Le prix est un système distribué, qui se comporte comme tel dès la première commande.
Topic, service ou action — comment choisir en ROS 2 ?
Accordez le motif de communication au travail. Un topic est un flux sans réponse : données capteurs, odométrie, commandes de vitesse — tout ce qui est publié en continu où la dernière valeur compte. Un service est une requête rapide avec réponse, pour ce qui s'accomplit en millisecondes, comme interroger un paramètre ou basculer un mode. Une action est pour les longs travaux dont on veut suivre l'avancement ou qu'il faut annuler — naviguer vers un objectif, ou fermer un préhenseur sur un objet. L'erreur la plus fréquente au début est de tout faire en topics puis de reconstruire à la main une sémantique requête-réponse par-dessus.
Pourquoi mes nœuds ROS 2 ne se voient-ils pas ?
Trois causes couvrent presque tout. Des valeurs ROS_DOMAIN_ID différentes rendent deux machines complètement invisibles l'une à l'autre alors que chacune se déclare en parfaite santé. Les réseaux Wi-Fi qui bloquent le multicast cassent entièrement le protocole de découverte, et c'est pourquoi les nœuds se trouvent souvent en Ethernet et pas via la borne Wi-Fi du bureau. Et un QoS désaccordé — un publicateur en best-effort face à un abonné exigeant du reliable — fait que les deux ne se connectent jamais, sans qu'aucun journalise d'erreur. Vérifiez d'abord l'identifiant de domaine ; c'est gratuit et c'est la réponse la plus fréquente.
Qu'est-ce que TF2 et pourquoi les transformations échouent-elles sans cesse ?
TF2 tient l'arbre des repères de coordonnées d'un robot — base, roues, et chaque capteur — pour demander où se trouve un point du repère caméra dans le repère robot. Les résolutions échouent pour trois raisons récurrentes. Un repère à deux parents casse l'arbre, et comme l'échec dépend du publicateur gagnant la course temporelle, ça fonctionne la plupart du temps. Un frame_id vide dans l'en-tête d'un message rend le message non transformable. Et un horodatage nul ou périmé signifie que la transformation existe mais pas à l'instant demandé. Les trois passent le système de types sans plainte.
Faut-il un Raspberry Pi pour apprendre ROS 2 ?
Non. Tout sauf les nœuds pilotes matériels tourne parfaitement sur un portable, meilleur endroit pour apprendre — compilations plus rapides, vrai écran, et aucun risque de corruption de carte SD coûtant une soirée. Un Pi devient nécessaire quand vous voulez que le robot embarque son propre ordinateur. Si vous en utilisez un, attendez-vous à ce que le Pi soit la contrainte : un pipeline caméra et un planificateur ensemble trouveront vite les limites d'un Pi 4.
Pourquoi ros2 run dit-il que mon paquet n'existe pas alors qu'il existe ?
Vous n'avez pas sourcé l'espace de travail dans ce terminal. Chaque nouveau terminal ignore vos paquets compilés jusqu'à sourcer le script d'installation, et ROS rend le résultat comme un paquet manquant plutôt qu'un environnement non sourcé. C'est le tracas ROS 2 le plus fréquent, il attrape tout le monde à répétition, et l'atténuation standard est de le sourcer depuis le profil du shell — avec la réserve que cela masque ensuite le problème quand vous avez vraiment deux espaces de travail.