📍 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.

Cas pratiques en zone UEMOA

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.

Sur un angle proche

🔝 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.

Étape 1 : cadrer la mission UAV avant tout choix de contrôleur

Avant de comparer des cartes, on fige la mission : payload, autonomie, environnement (urbain Dakar, brousse Tambacounda, littoral Saint-Louis), contraintes réglementaires ANACIM. Cette étape évite de surdimensionner un contrôleur pour un drone agricole de 2 kg.

Listez sur papier : poids total estimé, type de mission (mapping, livraison, inspection), température max au sol (jusqu’à 42 °C en saison chaude), portée radio cible. Ces paramètres dictent la classe de MCU (Cortex-M4 vs M7 vs H7).

Étape 2 : choisir la famille de contrôleur (Pixhawk, Cube, Holybro, Matek)

Les contrôleurs open-hardware basés sur la spec Pixhawk dominent le marché 2026. Pour un budget Dakar serré, un Holybro Pixhawk 6C revient à environ 230 EUR (~150 900 FCFA) commandé via un réexpéditeur. Le Cube Orange+ vise les missions critiques (inspection pipeline) à ~590 EUR.

Vérifiez la présence d’un IMU redondant et d’un baromètre isolé thermiquement avant de valider. Sortie attendue : une carte au format SPC ou STD avec connecteurs JST-GH normalisés.

Étape 3 : sélectionner le RTOS (NuttX vs Zephyr vs ChibiOS)

PX4 tourne sur NuttX, Ardupilot historiquement sur ChibiOS, et Zephyr gagne du terrain grâce à son support LTS. Pour une équipe qui débute, NuttX + PX4 reste la voie la plus documentée en français.

git clone --recursive https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot
make px4_fmu-v6c_default

Si la compilation se termine sans erreur et produit un fichier .px4 dans build/px4_fmu-v6c_default/, le toolchain est prêt. Comptez 8 à 15 minutes sur un laptop i5 récent.

Étape 4 : flasher le firmware via QGroundControl

QGroundControl détecte automatiquement la carte branchée en USB. Évitez de flasher en plein orage de saison des pluies : une coupure secteur en cours d’écriture brique le bootloader.

Connectez la carte, ouvrez Vehicle Setup → Firmware, sélectionnez la version stable PX4 v1.15. Le flash dure 60 à 90 secondes. Test concluant : la LED principale clignote en bleu lent.

Étape 5 : calibrer les capteurs (gyro, accéléromètre, magnétomètre)

La calibration magnétomètre est sensible à l’environnement : éloignez-vous de toute structure métallique (toit en tôle, ferraillage de dalle). Sur le terrain Almadies, faites les rotations à au moins 5 m de tout véhicule.

QGroundControl guide chaque axe avec une icône d’orientation. Une calibration réussie affiche un score < 0.30. Au-dessus, recommencez ou changez d'emplacement.

Étape 6 : configurer la failsafe radio et batterie

Une UAV mal configurée en failsafe est un projectile. Réglez RTL (Return To Launch) à 30 % de batterie restante pour les missions de plus de 5 km, 25 % en zone urbaine.

Testez en coupant volontairement la radio à 50 m d’altitude au-dessus d’un terrain dégagé. Le drone doit amorcer un retour en moins de 3 secondes. Documentez la procédure pour chaque pilote de l’équipe.

Étape 7 : tester la latence du link de télémétrie

En zone Sahel, les modules SiK 433 MHz portent jusqu’à 4 km en LOS. Pour Dakar urbain, 1,5 km est plus réaliste à cause des immeubles. Mesurez la latence aller-retour avec MAVLink Inspector.

mavproxy.py --master=/dev/ttyUSB0 --baudrate=57600
ping

Une latence sous 80 ms est confortable. Au-delà de 200 ms, le contrôle manuel devient hasardeux ; passez en mode automatique uniquement.

Étape 8 : valider en vol stationnaire avant mission réelle

Premier vol : 2 m d’altitude, 30 secondes de hover, atterrissage. Inspectez les logs .ulg avec Flight Review pour détecter toute oscillation parasite ou drift d’altitude.

Si le drone tient son point à ±0,5 m sans correction manuelle, l’architecture contrôleur+RTOS est validée. Vous pouvez passer aux missions waypoints. Dans la continuité sur le tooling embarqué, consultez notre série DevOps et nos tutoriels programmation.

Étape 9 : journaliser et analyser les vols sur la durée

Chaque mission produit un log .ulg qui pèse 5 à 40 Mo selon la durée. Centralisez ces logs sur un NAS local ou un bucket S3 compatible (Scaleway, Wasabi). Comptez environ 12 EUR (~7 870 FCFA) par mois pour 1 To chez Wasabi, suffisant pour une flotte de 5 drones sur un an.

Importez ensuite les logs dans Flight Review (open source) ou PX4 Log Analysis. Cherchez les pics de vibration au-dessus de 30 m/s² sur l’axe Z : ils trahissent une hélice mal équilibrée ou un bras desserré.

Étape 10 : prévoir la maintenance préventive trimestrielle

Un contrôleur de vol exposé à la poussière harmattan vieillit vite. Toutes les 50 heures de vol ou tous les 3 mois, démontez la coque, dépoussiérez à l’air sec (pas d’aérosol humide), revérifiez les soudures du connecteur d’alimentation.

Reflashez le firmware vers la dernière version stable une fois par trimestre. Tenez un journal de bord papier signé par le pilote responsable : utile en cas d’incident pour reconstituer l’historique. Ce rituel évite 80 % des pannes en vol selon les retours terrain des opérateurs agricoles de la vallée du fleuve Sénégal.

Étape 11 : industrialiser le déploiement multi-drones

Quand la flotte dépasse 3 appareils, scriptez la configuration. Un fichier params.txt par modèle, versionné dans Git, garantit que chaque drone reçoit exactement les mêmes gains PID, le même failsafe et la même limite d’altitude. Reproductibilité indispensable en mission cartographique payée par un client.

Utilisez QGroundControl en mode CLI ou MAVProxy pour pousser les paramètres en lot. Comptez 4 à 6 minutes par drone après rodage du script. Ce gain de temps vaut largement l’investissement initial d’une après-midi d’écriture, surtout sur une saison chargée d’inspections de pylônes télécoms.

Architectures de contrôleurs de vol et RTOS pour UAV (2026)