Introduction à ROS 2 — Distribution sécurisée du contrôle des robots entre les nœuds, les sujets et les DDS

ROS 2 n'est pas le robot lui-même. Il s'agit d'une plateforme permettant d'exécuter un pilote de caméra, la géolocalisation, la planification de trajectoire et le contrôle des moteurs sous forme de programmes (nœuds) distincts, puis de les combiner grâce à des messages et une communication standardisés. Vous pouvez démarrer avec un simple fichier Python au stade du prototype, puis évoluer vers du C++, l'exécution en temps réel, l'utilisation de plusieurs ordinateurs et la surveillance de la sécurité pour un produit final. L'important n'est pas de mémoriser l'API, mais de concevoir qui est responsable des données, du timing, de la fiabilité et de l'état de sécurité à l'arrêt.

ROS 2

Image : Robot Logo du système d'exploitation, Wikimedia Commons (CC BY-SA 4.0). Le logo identifie le middleware et ne garantit pas une distribution ou une configuration DDS particulière.

Résumé en 30 secondes

• Un nœud est un processus ayant une seule responsabilité, un sujet représente un flux continu, un service représente une requête/réponse courte et une action représente une tâche longue avec un retour d'information intermédiaire.

La communication de ROS 2 s'effectue via DDS, et la QoS (fiabilité, historique, profondeur, durabilité, délai) peut être configurée pour chaque point de terminaison. Les capteurs et le système de contrôle n'ont pas besoin d'utiliser les mêmes paramètres.

TF2 gère un arbre de repères temporels. Si les repères map, odom, base_link et les repères des capteurs sont confondus, le robot se dirigera au mauvais endroit, même si la perception est correcte.

Sur du matériel réel, il est indispensable d'ajouter la gestion du cycle de vie, des mécanismes de surveillance, la séparation des privilèges, la journalisation et des mécanismes de sécurité en cas de coupure réseau. La simulation ne garantit pas la sécurité.

Il est recommandé de développer dès le départ une version stable et à support long terme comme ROS 2 Jazzy, avec une combinaison DDS, système d'exploitation et pilotes compatible, et de créer un environnement de travail reproductible.

1. Vue d'ensemble de ROS 2

Figure 1 — Dans ROS 2, les nœuds se découvrent et communiquent entre eux via DDS. Non seulement les noms des sujets, mais aussi la QoS, le type, l'heure et le système de coordonnées sont considérés comme faisant partie du contrat.

Un graphe ROS 2 peut être configuré à l'exécution. Un nœud caméra publie des images, un nœud perception s'y abonne et un nœud de contrôle utilise les résultats, l'autolocalisation et publie des commandes de vitesse. Même si vous déplacez un nœud vers un autre ordinateur, le graphe reste inchangé tant que la découverte DDS et la sérialisation fonctionnent correctement.

2. Choisir la primitive de communication appropriée

Un message de sujet doit contenir non seulement la valeur, mais aussi header.stamp et frame_id. Si l'horodatage de l'image et celui de l'IMU sont désynchronisés, l'algorithme peut toujours calculer un résultat, mais l'estimation du mouvement sera erronée. Le renvoi des images de la caméra avec une fiabilité élevée peut saturer la bande passante ; il est donc important de choisir la QoS en fonction des caractéristiques de chaque capteur.

3. La QoS comme « contrat de communication »

Les paramètres QoS minimaux à vérifier dans ROS 2 sont : Fiabilité (Meilleur effort/Fiable), Durabilité (Volatile/Transitoire locale), Historique (Conserver la dernière/Tout conserver), Profondeur, Délai et Réactivité. Un LiDAR à haut débit est généralement bien adapté au mode « Meilleur effort », qui supprime les paquets obsolètes. En revanche, les commandes de vitesse, sensibles aux pertes de messages, doivent utiliser le mode « Fiable » avec un délai court.

Si la QoS de l'éditeur et de l'abonné est incompatible, la communication sera impossible, même avec le même nom de sujet. Vérifiez les paramètres réels avec ros2 topic info -v /scan plutôt que de vous fier aveuglément aux paramètres prédéfinis du pilote de capteur. Lors de la traversée d'un réseau, testez simultanément la MTU, la retransmission Wi-Fi, les restrictions de multidiffusion et la synchronisation temporelle.

4. TF2 et Temps

La pose d'un robot est exprimée comme une transformation entre deux repères. Un arbre typique ressemble à ceci :

map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
                                                        ├── base_laser
                                                        ├── imu_link
                                                        └── camera_link

map est le repère monde à long terme, odom est l'odométrie lissée à court terme et base_link est le repère du véhicule. SLAM corrige map → odom, tandis que l'estimation roue/IMU met à jour odom → base_link à haute fréquence. TF2 stocke les transformations horodatées et les interpole à l'instant d'acquisition de chaque capteur.

Normalisez les repères de coordonnées comme étant directs et indiquez clairement la différence entre le repère optique (z vers l'avant, x vers la droite, y vers le bas) et le repère du véhicule (x vers l'avant, y vers la gauche, z vers le haut). Corrigez les transformations statiques avec static_transform_publisher et ne publiez pas de transformation dynamique comme statique. Un cycle ou plusieurs parents dans l'arbre TF constituent une erreur de conception.

5. Packages et flux d'implémentation

Un nœud Python ROS 2 minimal ressemble à ceci.

import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32

class Speed(Node):
    def __init__(self):
        super().__init__('speed_node')
        self.pub = self.create_publisher(Float32, '/speed', 10)
        self.timer = self.create_timer(0.02, self.tick)  # 50 Hz
    def tick(self):
        msg = Float32(); msg.data = 0.2
        self.pub.publish(msg)

rclpy.init(); node = Speed(); rclpy.spin(node)

Sur du matériel réel, n'envoyez pas de commandes de vitesse directement au moteur ; intercalez un nœud en amont, une limitation de vitesse, un arrêt d'urgence et une surveillance matérielle. Même en utilisant rclcpp en C++, vérifiez les groupes de rappel, l'exécuteur, l'allocation de mémoire et le comportement en temps réel.

Séparez l'espace de travail en src, build, install et log, et résolvez les dépendances avec rosdep. Installez le système d'exploitation, DDS et le compilateur avec Docker ou un conteneur de développement, et intégrez ros2 doctor, ros2 node list, ros2 topic hz et tf2_tools aux diagnostics d'intégration continue et de terrain.

6. Cycle de vie et sécurité

Les capteurs et actionneurs ne doivent pas nécessairement accepter les commandes dès leur mise sous tension. Les transitions d'état du nœud de cycle de vie (Non configuré → Inactif → Actif → Finalisé) séparent l'initialisation du pilote, l'étalonnage, les vérifications de communication et l'autorisation de sortie. Lorsqu'un chien de garde perd son signal, la commande de vitesse est annulée et le frein ou le relais est également ouvert côté matériel.

Du point de vue de la sécurité, la communication par messages de ROS 2 ne satisfait pas aux normes de sécurité fonctionnelle. Vérifiez le champ d'application des normes IEC 61508/ISO 26262/ISO 13849 et des normes similaires, et séparez les fonctions de sécurité en un système de surveillance, un microcontrôleur certifié et un dispositif d'arrêt d'urgence physique. Lors de la connexion à un réseau, utilisez les clés et certificats SROS 2, la sécurité DDS, le contrôle d'accès et l'audit des journaux.

7. Écosystème actuel et recherche

Nav2 intègre l'autolocalisation, la cartographie, la planification de trajectoires et le contrôle via des actions et la gestion du cycle de vie. ros2_control standardise l'interface entre le matériel et les contrôleurs. MoveIt 2 gère la cinématique du manipulateur, la détection des collisions et la planification de trajectoires. La simulation dans Gazebo ou Webots et la relecture des journaux de capteurs avec rosbag2 permettent des tests de régression sans interrompre le fonctionnement du robot réel.

La recherche progresse sur la communication sans copie, les pipelines d'images typées utilisant des GPU/NPU, les exécuteurs déterministes, l'apprentissage distribué et la robotique cloud, au-delà du DDS. Lors de l'adoption d'une nouvelle fonctionnalité, il est essentiel de tester non seulement les performances, mais aussi les déconnexions réseau, les décalages temporels, les redémarrages de processus, les déconnexions de capteurs et les messages malformés.

Résumé

ROS 2 transforme un robot, d'un assemblage de pièces, en un système distribué réutilisable. Définissez dès le départ les responsabilités des nœuds, la qualité de service (QoS) des sujets, les coordonnées et la synchronisation de TF2, le cycle de vie et les états de sécurité. Ainsi, le système restera robuste même en cas de changement d'algorithme.