Nœuds, sujets, services et actions en ROS 2

Robot Operating System 2 (ROS 2) laisse des programmes tournant indépendamment échanger des données typées. Un pilote de caméra, un contrôleur moteur, un planificateur et une interface utilisateur peuvent être des nœuds séparés connectés via le graphe ROS. La décision de conception importante n’est pas seulement le type de message ; c’est si l’interaction est un flux, une courte requête, ou un but de longue haleine.

Ce guide reste neutre en distribution. Commandes et concepts centraux sont stables, mais les détails d’installation et versions de paquets doivent suivre la documentation de la version ROS 2 vraiment utilisée.

Modélisez une responsabilité par nœud

Un nœud est un participant au graphe ROS. Les bonnes frontières de nœuds suivent les responsabilités : un pilote lidar publie des balayages, un nœud d’odométrie estime le mouvement, et un navigateur accepte des buts. Évitez de faire de chaque fonction un nœud — le surcoût de processus et de communication se justifie quand la frontière améliore réutilisation, isolation, déploiement ou propriété.

Les noms rendent le graphe compréhensible. Utilisez des noms de nœuds et d’interfaces descriptifs comme /front_lidar, /wheel_odometry et /cmd_vel. Les espaces de noms laissent deux robots faire tourner des graphes équivalents sans collisions.

Inspectez un système en marche avant de le changer :

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info révèle publieurs, abonnés, serveurs et clients de services, et actions connectés à ce nœud. C’est souvent le chemin le plus rapide vers une interface manquante ou mal nommée.

Utilisez les sujets pour les flux continus

Un sujet est une communication asynchrone publier-s’abonner. Les publieurs envoient des messages typés sans attendre de réponse directe, et un nombre quelconque d’abonnés peut les recevoir. Les sujets conviennent aux données qui changent dans le temps :

• images de caméra et balayages lidar ;
• états articulaires et odométrie des roues ;
• état de la batterie ;
• vitesse commandée ;
• événements de diagnostic.

Vérifiez un flux depuis la ligne de commande :

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

Le type de message fait partie du contrat. Repères de coordonnées, unités, horodatages et covariance comptent autant que les noms de champs. Un abonné ne peut interpréter une position sûrement s’il ne sait pas si la valeur est en mètres dans map ou en millimètres dans un repère caméra.

Les réglages de qualité de service (QoS) affectent la livraison. Les flux de capteurs préfèrent souvent des données récentes à la retransmission d’échantillons périmés, tandis qu’un état de type configuration peut exiger un comportement fiable ou transient-local. Un publieur et un abonné aux politiques QoS incompatibles peuvent figurer dans le graphe sans échanger aucune donnée.

Utilisez les services pour les courtes requêtes-réponses

Un client de service envoie une requête et attend la réponse du serveur. Les services conviennent aux opérations rapides à réponse définie :

• lire ou actualiser une configuration ;
• réinitialiser l’odométrie ;
• effacer une carte ;
• demander si un composant est prêt.

Ils conviennent mal aux données de capteurs continues ou à une manœuvre pouvant durer des secondes. Un appel synchrone qui attend une lente action moteur peut bloquer un appelant et ne fournit ni retour de progression standard ni annulation.

Inspectez et appelez un service avec :

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

Le type exact dans la dernière commande doit correspondre au serveur. Concevez les réponses pour rapporter à la fois le succès de transport et le statut significatif de l’opération ; recevoir une réponse ne garantit pas que l’action matérielle demandée était possible.

Utilisez les actions pour les buts de longue haleine

Une action modélise un but qui prend du temps. Elle supporte l’acceptation du but, un retour périodique, un résultat final, et l’annulation ou la préemption. Naviguer vers une pose et déplacer un bras sur une trajectoire sont des actions naturelles.

L’interaction a trois parties sémantiques :

• But : ce que le client veut, comme une pose cible.
• Retour : la progression en cours, comme la distance restante.
• Résultat : l’issue terminale et les données renvoyées.

Les serveurs d’actions doivent répondre promptement à l’annulation et laisser le matériel dans un état documenté. Un client doit traiter rejet, annulation, abandon et succès plutôt que de traiter chaque résultat terminal comme un achèvement.

Depuis la ligne de commande :

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Remplacez les substituts par le type et les champs rapportés par le graphe en marche. Utilisez la commande pour inspecter le comportement, pas comme interface de production codée en dur.

Choisissez avec un tableau de décision

Un sujet n’est pas automatiquement « rapide », ni un service automatiquement « fiable ». Temporisation et livraison dépendent de QoS, intergiciel, exécuteurs, charge de travail et réseau. Choisissez d’abord par sémantique d’interaction.

Un comportement peut utiliser les trois. Un nœud de navigation s’abonne aux sujets de balayages et d’odométrie, accepte une action de navigation, et expose un court service pour effacer une carte de coûts. Les frontières restent claires parce que chaque interface répond à une sorte différente de question.

Concevez un petit graphe de robot mobile

Considérez un robot à entraînement différentiel :

1. /encoder_driver publie les impulsions des roues.
2. /odometry s’abonne aux impulsions, publie /odom, et diffuse odom → base_link.
3. /range_driver publie des mesures de distance.
4. /safety_controller s’abonne aux distances et limite /cmd_vel.
5. /navigator accepte une action de déplacement et publie la vitesse désirée.

Ne laissez pas deux nœuds sans rapport commander les moteurs sans arbitrage. Donnez à un composant la propriété de la commande finale d’actionneur ou rendez la règle de priorité explicite.

Utilisez les types de messages ROS standard quand leur sémantique convient. Les interfaces personnalisées conviennent quand le contrat de données est vraiment propre au projet, pas juste pour renommer des champs existants.

Déboguez le graphe couche par couche

Quand des données manquent :

1. Confirmez que les deux nœuds figurent dans ros2 node list.
2. Confirmez noms et types d’interfaces.
3. Inspectez les comptes de publieurs et abonnés.
4. Comparez les politiques QoS.
5. Affichez un message et vérifiez horodatages et identifiants de repères.
6. Vérifiez les logs et la charge des exécuteurs.

Quand une action ne finit jamais, distinguez « but non accepté », « serveur ayant cessé de produire du retour » et « client ayant ignoré le résultat ». Quand un service reste coincé, vérifiez si le rappel serveur est bloqué en attendant un travail qui aurait dû être une action.

Évitez les erreurs d’architecture courantes

• Tout utilise un sujet : les appelants ne peuvent savoir si une requête unique a réussi.
• Le mouvement utilise un service : le long travail manque de sémantique de progression et d’annulation.
• Les données de capteurs utilisent une file profonde fiable par défaut : les échantillons périmés s’accumulent quand le traitement traîne.
• Les conventions de repères et d’unités sont non documentées : les messages typés restent sémantiquement ambigus.
• Un nœud géant possède chaque sous-système : les tests et l’isolation des pannes disparaissent.
• Des dizaines de minuscules nœuds enveloppent des fonctions ordinaires : le graphe devient plus dur sans ajouter de frontière utile.

Le simulateur de bras robotique fournit une tâche concrète de type action : demandez une cible, observez le mouvement, et rapportez des issues inatteignables ou contraintes. Continuez avec les repères de coordonnées TF2 en ROS 2 pour garder la géométrie de chaque nœud cohérente.