Architecture Temps Réel : Le Rôle de ROS 2
Si TensorRT et OpenVINO sont les moteurs, ROS 2 (Robot Operating System 2) est le châssis et le système nerveux qui intègre toutes les composantes d'un drone autonome. Son architecture modulaire et ses garanties temps réel via DDS en font le standard pour la robotique complexe, permettant une communication à faible latence et prévisible entre tous les processus. Cliquez pour ouvrir le dossier technique complet.
Dossier Technique : ROS 2, le Système Nerveux du Drone Autonome
ROS 2 structure une application robotique en un graphe de processus indépendants (nœuds) qui communiquent via des mécanismes standardisés. Cette modularité permet le développement parallèle, la réutilisation de code et une grande robustesse : la défaillance d'un nœud n'entraîne pas l'arrêt de l'ensemble du système.
[Image du graphe de calcul de ROS 2]Les Briques de Base de ROS 2
| Composant | Rôle | Exemple d'Usage Drone |
|---|---|---|
| Nœud (Node) | Une unité de calcul (un processus). | /camera_driver, /object_detector, /path_planner. |
| Sujet (Topic) | Canal de communication asynchrone (unidirectionnel). | Le nœud /camera_driver publie des images sur le topic /image_raw. |
| Service | Communication synchrone de type requête/réponse. | Un nœud demande au service /arm_drone d'armer les moteurs et attend la confirmation. |
| Action | Communication asynchrone pour des tâches longues avec feedback. | Un nœud envoie un objectif à l'action /follow_path et reçoit un feedback régulier sur la progression. |
Le changement le plus fondamental entre ROS 1 et ROS 2 est le remplacement du middleware maison (TCPROS) par le Data Distribution Service (DDS), un standard industriel éprouvé pour les systèmes critiques (aérospatiale, finance). Ce changement apporte des garanties de performance et de fiabilité.
La Puissance de la Qualité de Service (QoS)
Avec DDS, chaque communication peut être configurée avec un profil QoS précis, permettant des arbitrages fins entre performance et fiabilité.
| Profil QoS | Option "Fiable" (Reliable) | Option "Meilleur Effort" (Best Effort) | Cas d'Usage Drone |
|---|---|---|---|
| Fiabilité | Garantit la livraison de chaque message, avec retransmissions si nécessaire. | Envoie les messages sans garantie de livraison (type UDP). | Fiable pour les commandes de vol. Meilleur Effort pour un flux vidéo 60fps. |
| Durabilité | Un nouvel abonné reçoit les N derniers messages publiés. | Un nouvel abonné ne reçoit que les futurs messages. | Fiable (Transient Local) pour /map, pour qu'un nœud qui démarre ait la dernière carte. |
| Historique | Conserve les N derniers messages dans une file d'attente. | Ne conserve que le dernier message. | Historique (Keep Last, depth=1) pour les capteurs, pour avoir la valeur la plus fraîche. |
L'intégration entre le companion computer (exécutant ROS 2) et le contrôleur de vol (exécutant le firmware PX4) se fait via un pont logiciel haute-performance, typiquement XRCE-DDS. Cela permet une communication native et bidirectionnelle.
[Image de l'architecture d'intégration ROS 2 et PX4]Flux de Données et Contrôle
PX4 → ROS 2
Le firmware PX4 publie ses données internes (IMU, position, batterie...) sur le réseau DDS. Un nœud ROS 2 sur le companion computer s'y abonne nativement pour les utiliser dans des algorithmes d'IA.
ROS 2 → PX4
Inversement, un nœud d'IA peut publier des consignes de haut niveau (points de passage, vitesse...) sur des topics DDS. Le firmware PX4 s'abonne à ces topics et, en mode "Offboard", les utilise comme référence pour sa boucle de contrôle.
Exemple : Atterrissage de Précision Autonome sur Cible Visuelle
Ce cas d'usage illustre parfaitement la puissance de l'intégration ROS 2 / PX4.
[Image d'un drone atterrissant sur une cible visuelle]- Un nœud ROS 2
/marker_detectors'abonne à/camera/image_raw. Il détecte un marqueur visuel (ex: Aruco) et publie sa position relative sur/target_pose. - Un nœud
/landing_controllers'abonne à/target_pose. Il transforme la position de la cible en consignes de vitesse pour le drone. - Le
/landing_controllerpublie ces consignes à 20Hz sur les topics/offboard_control_modeet/trajectory_setpoint. - Le firmware PX4, en mode "Offboard", reçoit ces consignes via XRCE-DDS et exécute un atterrissage de précision que le GPS seul ne pourrait jamais atteindre.
Toute cette logique complexe est implémentée de manière modulaire grâce à ROS 2, et exécutée avec une faible latence grâce à l'intégration DDS.