Cette couche est le centre de l'autonomie. S'exécutant sur un Companion Computer (ex: NVIDIA Jetson, Qualcomm RB5), elle traite les tâches qui demandent une forte puissance de calcul et une "compréhension" de l'environnement, bien au-delà de la simple stabilisation.

1. Estimation d'État (State Estimation)

Avant toute décision, le drone doit savoir avec une précision extrême où il est, à quelle vitesse il se déplace et quelle est son orientation (sa "pose"). C'est le rôle de l'estimation d'état, souvent réalisée par un Filtre de Kalman Étendu (EKF). Ce filtre fusionne des données de sources multiples et de fréquences variées pour produire une estimation unique et robuste :

• Haute fréquence : Données de l'IMU (instables à long terme mais précises à court terme).
• Basse fréquence : Données du GPS (précises à long terme mais sujettes aux pannes), du baromètre (altitude) et du magnétomètre (cap).
• Données Visuelles (VIO) : L'Odometrie Visuelle-Inertielle (VIO) analyse le mouvement des points de repère dans le flux vidéo pour estimer le déplacement du drone, fournissant une source de localisation cruciale en l'absence de GPS.

2. Perception et Compréhension de Scène

C'est ici que les données brutes des capteurs sont transformées en une représentation sémantique du monde. Computer Vision LiDAR Processing Sensor Fusion

• Vision par Ordinateur : Des modèles de Deep Learning exécutés sur le GPU embarqué analysent les images pour :
  • Détection d'objets : Identifier et localiser des objets (véhicules, personnes) avec des boîtes englobantes (ex: YOLOv8).
  • Segmentation Sémantique : Classifier chaque pixel de l'image (route, bâtiment, ciel, végétation), créant une carte de "navigabilité".
• Traitement LiDAR : Les nuages de points 3D sont traités pour détecter les obstacles avec une grande précision géométrique, indépendamment des conditions de lumière.

3. Planification de Trajectoire (Path Planning)

Avec une carte de l'environnement et une estimation de sa propre position, le drone peut planifier son chemin. Ce processus est scindé en deux :

• Planificateur Global : Calcule une trajectoire optimale sur une carte connue ou construite en temps réel (via SLAM), en utilisant des algorithmes comme A* ou RRT*.
• Planificateur Local : Ajuste la trajectoire en temps réel pour réagir aux obstacles dynamiques (non prévus sur la carte globale), en utilisant des approches comme le DWA (Dynamic Window Approach).

4. Exécution et Contrôle de Haut Niveau

La couche IA ne commande pas directement les moteurs. Elle envoie des consignes de haut niveau (points de passage, trajectoires, consignes de vitesse) au Middleware, qui les traduit pour le contrôleur de vol. Cela crée une séparation claire des responsabilités : l'IA décide "où aller", et le contrôleur de vol (Couche 1) se charge de "comment y aller" de manière stable.

Le middleware est la glue logicielle qui permet à des dizaines de processus hétérogènes de collaborer. Sans lui, l'architecture serait un "plat de spaghettis" de liens directs, impossible à maintenir et à faire évoluer. L'écosystème ROS (Robot Operating System) est le standard de facto.

ROS 2 & DDS : Le Passage à la Production

Alors que ROS 1 était excellent pour le prototypage, ROS 2 a été reconstruit pour les applications critiques. Il repose sur le standard industriel DDS (Data Distribution Service). Ce changement apporte des avantages cruciaux pour un drone :

• Qualité de Service (QoS) : On peut configurer la manière dont les messages sont transmis. Un flux vidéo peut être configuré en mode "best effort" (perdre quelques images n'est pas grave), tandis qu'un ordre d'arrêt d'urgence sera configuré en mode "reliable" (garantie de livraison).
• Découverte Automatique : Les nœuds se découvrent automatiquement sur le réseau, ce qui est idéal pour des systèmes complexes ou des essaims de drones.
• Sécurité : DDS intègre des mécanismes d'authentification et de chiffrement, essentiels pour protéger le drone contre le piratage.

Le Pont MAVROS : L'Interprète Indispensable

Le Companion Computer (Linux/ROS) et le Contrôleur de Vol (RTOS/PX4) ne parlent pas le même langage. Le nœud MAVROS sert de pont de traduction bidirectionnel :

• ROS → FCU : Il traduit les messages ROS (ex: une consigne de vitesse sur le topic `/setpoint_velocity/cmd_vel`) en messages MAVLink que le contrôleur de vol comprend.
• FCU → ROS : Il reçoit les données de télémétrie MAVLink du contrôleur (données IMU, état GPS, voltage batterie) et les publie sur des topics ROS pour que les autres nœuds (IA, logging) puissent les utiliser.

L'Écosystème de Simulation

Le développement sur le matériel réel est lent et risqué. Le middleware permet de s'interfacer de manière transparente avec des simulateurs photoréalistes comme Gazebo ou AirSim (basé sur Unreal Engine). Les algorithmes d'IA peuvent ainsi être testés et validés dans des milliers de scénarios virtuels avant même de faire tourner une hélice.

ROS 2 / DDS MAVLink MAVROS Gazebo AirSim

Cette couche est la fondation de la pyramide de sécurité. S'exécutant sur un microcontrôleur (ex: STM32) au sein du Contrôleur de Vol (FCU), sa seule mission est de garantir la stabilité et l'exécution des commandes de base. Elle doit fonctionner de manière parfaite, même si toutes les couches supérieures tombent en panne.

Le Déterminisme Temporel d'un RTOS

Imaginez une rafale de vent qui frappe le drone. Le FCU doit réagir en quelques millisecondes. Un OS généraliste (GPOS) comme Linux pourrait être en train d'effectuer une opération disque et retarder cette réaction, provoquant un crash. Un RTOS (ex: NuttX, FreeRTOS) garantit que la tâche de stabilisation (haute priorité) interrompra n'importe quelle autre tâche (basse priorité) pour s'exécuter dans sa fenêtre temporelle garantie (son "deadline"). C'est le déterminisme, une exigence non négociable pour le contrôle de vol.

Le Cœur du Contrôle : La Boucle PID

Au cœur du firmware (ex: PX4, ArduPilot) se trouve la boucle de contrôle d'attitude, qui s'exécute des centaines de fois par seconde. Pour chaque axe (roulis, tangage, lacet), un contrôleur PID (Proportionnel, Intégral, Dérivé) calcule en permanence l'erreur entre l'état désiré (envoyé par la couche IA ou le pilote) et l'état réel (mesuré par l'IMU).

• Terme Proportionnel (P) : Réagit à l'erreur actuelle. Plus l'erreur est grande, plus la correction est forte.
• Terme Intégral (I) : Corrige les erreurs statiques résiduelles (ex: un léger déséquilibre du drone).
• Terme Dérivé (D) : Anticipe les erreurs futures en regardant la vitesse de variation de l'erreur, agissant comme un amortisseur pour éviter les oscillations.

La Couche d'Abstraction Matérielle (HAL)

Les firmwares comme PX4 sont conçus pour tourner sur des dizaines de contrôleurs de vol différents. Ceci est possible grâce à une HAL (Hardware Abstraction Layer). C'est une couche logicielle qui fournit une interface standardisée pour le code de haut niveau, tout en masquant les détails d'implémentation spécifiques à chaque matériel (quel capteur IMU est utilisé, sur quel port I2C/SPI il est connecté, etc.).

RTOS: NuttX, FreeRTOS Firmwares: PX4, ArduPilot Contrôleurs PID HAL Protocoles Moteurs: DShot, PWM