📍 Article principal de la série : Drones et UAV : panorama technologique pour ingénieurs
Cadre éditorial. Cet article présente l’architecture logicielle des contrôleurs de vol UAV au niveau enseigné en spécialité informatique embarquée. Aucun guide de flashage ou de configuration de hardware opérationnel — uniquement les concepts d’OS temps réel, l’organisation logicielle des firmwares libres ArduPilot et PX4, et leur usage en simulation logicielle pure.
Le contrôleur de vol (Flight Controller, FC) est le « cerveau » du drone. Il exécute en temps réel toutes les boucles de contrôle, lit les capteurs, communique avec la station sol, prend les décisions de mode (arming, RTL, failsafe). Comprendre son architecture demande de maîtriser trois domaines : microcontrôleurs ARM Cortex, OS temps réel, et organisation modulaire de gros projets logiciels.
Prérequis
- Programmation C/C++ niveau intermédiaire.
- Notions sur les systèmes d’exploitation : processus, ordonnancement, IPC.
- Notions de microcontrôleurs et d’I/O bas niveau (UART, SPI, I2C).
- Niveau : intermédiaire à avancé.
- Temps estimé : 90 minutes.
Étape 1 — Le hardware typique d’un FC
Les contrôleurs de vol modernes utilisent un microcontrôleur 32 bits ARM Cortex-M4 ou M7, cadencé entre 168 MHz et 480 MHz, avec FPU intégrée. Les références dominantes : STM32F405/F722/H743, NXP iMX RT1060, RP2040 (émergent pour les FC pédagogiques).
La RAM embarquée varie de 128 KB à 1 MB. La mémoire flash de 1 à 2 MB. Périphériques typiques : USB OTG, UART x4-8, SPI x2-3, I2C x2, PWM/DShot x4-8, ADC x4-8, SDIO ou SPI pour carte SD.
Étape 2 — Pourquoi un RTOS plutôt qu’un superloop
Les firmwares basiques utilisent un superloop : une boucle principale qui appelle séquentiellement chaque sous-tâche. Simple, prédictible, mais limité. Quand on veut héberger une dizaine de tâches concurrentes, le superloop devient inmaintenable.
La solution professionnelle est un OS temps réel (RTOS). Les deux RTOS dominants en aérospatial libre : NuttX (utilisé par PX4, POSIX-compliant) et FreeRTOS (plus léger). ArduPilot utilise une couche d’abstraction HAL qui s’adapte à plusieurs RTOS sous-jacents : ChibiOS sur les FC modernes, Linux sur les FC type Raspberry Pi.
Étape 3 — Notions clés du temps réel
Plusieurs concepts RTOS à maîtriser. Ordonnancement préemptif : une tâche de haute priorité interrompt une tâche de basse priorité. Latence : temps maximum garanti entre un événement et le début d’exécution. Jitter : variation de cette latence.
Pour un FC drone, latence acceptable typique : 100 µs sur la boucle d’attitude angulaire, 1 ms sur la boucle d’angle, 10 ms sur la boucle de position. Risque classique : l’inversion de priorité. Le RTOS gère ça via le mécanisme de priority inheritance.
Étape 4 — Architecture modulaire de PX4
PX4 organise son code en modules indépendants qui communiquent par un bus de messages publish/subscribe appelé uORB (micro Object Request Broker). Chaque module est une tâche RTOS distincte.
Modules typiques PX4 :
sensors : lit IMU, GPS, barometer, publie sensor_combined
ekf2 : lit sensor_combined, publie vehicle_attitude
mc_att_control : lit vehicle_attitude, publie actuator_controls
navigator : gère missions et failsafe
mavlink : pont vers la station sol
commander : machine d'état globaleÉtape 5 — Architecture d’ArduPilot
ArduPilot a une approche différente. Le code est organisé en bibliothèques C++ liées à un binaire principal par véhicule (ArduCopter, ArduPlane, ArduRover, ArduSub). Le principal scheduler est dans la librairie AP_Scheduler.
Avantages : moins d’overhead mémoire que PX4, large support de matériels. Pour la pédagogie, ArduPilot a souvent une longueur d’avance avec sa documentation.
Étape 6 — Les drivers de capteurs
Les drivers de capteurs sont les modules les plus critiques. Architecture typique du driver IMU : initialisation, lecture périodique (interruption matérielle à 1-8 kHz), validation, publication via uORB. Le tout doit s’exécuter en moins de 50 µs par cycle.
Étape 7 — Le système de paramètres
Les drones ont des centaines de paramètres configurables : gains PID, limites d’angle, calibrations capteurs. Stockés en mémoire flash. Le firmware expose ces paramètres via MAVLink (PARAM_REQUEST_LIST, PARAM_VALUE) qui permet à QGroundControl de les lire et les modifier.
Étape 8 — Le datalogging et l’analyse post-vol
En vol, le firmware enregistre toutes les variables internes. Le format uLog de PX4 et le format Bin d’ArduPilot sont les standards. L’analyse post-vol utilise FlightPlot ou PlotJuggler pour PX4, MAVExplorer ou Mission Planner pour ArduPilot.
Étape 9 — Compilation et flashage : approche SITL
Pour la pédagogie, on évite le flashage hardware réel. La solution : compiler le firmware pour la cible SITL qui exécute le binaire directement sur Linux.
make px4_sitl gz_x500
sim_vehicle.py -v ArduCopter --console --mapÉtape 10 — Vérifier votre compréhension
Cinq questions. Premier : pourquoi un RTOS plutôt qu’un superloop ? Deuxième : différence d’architecture entre PX4 et ArduPilot ? Troisième : à quoi sert uORB ? Quatrième : qu’est-ce que la priority inheritance ? Cinquième : décrivez le pipeline de débogage par analyse de logs uLog.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Tâche EKF qui prend trop de temps | Implémentation non optimisée | Profiler avec FreeRTOS+Trace. |
| Inversion de priorité non gérée | Mutex sans priority inheritance | Activer priority inheritance dans le RTOS. |
| Driver capteur qui rate des échantillons | Latence trop élevée d’interruption | Vérifier la priorité d’IRQ. |
| Paramètres non sauvegardés en flash | EEPROM émulée pas commit | Forcer save_params() après modification. |
| Logs trop verbeux qui saturent la SD | Niveau de logging mal calibré | Configurer SDLOG_PROFILE. |
| SITL diverge du hardware réel | Différences de précision floating-point | Documenter les écarts. |
Adaptation au contexte ouest-africain
Pour les écoles d’ingénieur ouest-africaines en spécialité informatique embarquée, l’architecture des firmwares libres pour drones est un cas d’étude exceptionnel. Le code est entièrement disponible sur GitHub, maintenu activement, accompagné d’une documentation pédagogique de qualité.
Plusieurs sujets de mémoire : étude comparative de l’ordonnancement temps réel NuttX vs ChibiOS, implémentation d’un module PX4 custom, optimisation de la pile MAVLink pour les liaisons à très faible débit (LoRa).
Côté infrastructure, une station Linux puissante (16 Go RAM) permet de compiler le firmware en quelques minutes. Pour les étudiants à matériel modeste, plusieurs écoles ont mis en place des serveurs de compilation distants accessibles en SSH.
Pour les TPE de spécialité, plusieurs sujets concrets : implémenter un mode de vol custom dans ArduPilot, ajouter un capteur tiers via le système de drivers, étudier la machine d’état du module Commander.
Pour les enseignants qui veulent introduire les firmwares libres dans un cours d’embarqué, l’approche la plus rentable est de partir d’un projet existant comme Hello World ArduPilot, de cloner le dépôt, de compiler en SITL, de lancer un vol simulé Gazebo.
Articles connexes
Pour aller plus loin
- 🔝 Retour au panorama : Drones et UAV : panorama technologique
- Documentation PX4 : docs.px4.io
- Documentation ArduPilot : ardupilot.org/dev
FAQ
Faut-il connaître l’assembleur ARM ? Pas pour le développement applicatif sur PX4 ou ArduPilot — tout se fait en C++ haut niveau.
PX4 ou ArduPilot pour démarrer en école ? ArduPilot a une courbe d’apprentissage plus douce. Pour un master ou un projet de recherche, PX4.
Le RTOS gère-t-il la mémoire dynamique ? Oui dans la plupart des cas, mais c’est déconseillé en code FC pour des raisons de prédictibilité.
Comment teste-t-on un firmware en simulation ? Compilation SITL + Gazebo. Le binaire firmware tourne sur Linux, les capteurs sont simulés par Gazebo.
Les firmwares supportent-ils le multicore ? Historiquement single-core sur Cortex-M. Les firmwares évoluent doucement vers le multicore.
Mots-clés secondaires : RTOS drone, NuttX, FreeRTOS, ChibiOS, ArduPilot architecture, PX4 modules, uORB, ordonnancement temps réel.