Programmer un drone maison avec une carte Arduino, ça peut faire peur au début : capteurs, PID, mixage des moteurs… On a vite l’impression qu’il faut un diplôme d’ingé aéronautique. En réalité, si tu sais déjà faire clignoter une LED et lire un capteur avec Arduino, tu as déjà 70 % des bases. La différence, c’est qu’en drone tout doit être propre, rapide et fiable. Rien ne pardonne en l’air.
Dans cet article, on va voir comment aborder la programmation Arduino pour un drone DIY de façon méthodique, sans partir dans tous les sens. Objectif : que tu comprennes ce qu’il se passe dans la boucle principale, comment sont gérés les capteurs, la radio, les moteurs et les sécurités, et que tu puisses réellement modifier ton code en connaissance de cause.
Pourquoi utiliser Arduino pour un drone maison ?
On va être honnête : si tu veux juste voler le week-end sans te prendre la tête, une carte de vol Betaflight ou Ardupilot toute faite sera souvent plus efficace qu’un Arduino bricolé. Mais l’Arduino a trois gros avantages pour un drone DIY :
- Pédagogie maximale : tu contrôles tout, du capteur au moteur. Idéal pour comprendre comment vole un quadri.
- Souplesse : tu codes exactement ce dont tu as besoin (mode stabilisé, altitude hold, test de nouveaux capteurs…).
- Coût et accessibilité : une Arduino Nano ou Pro Mini + un MPU6050 coûtent quelques euros, parfait pour expérimenter.
Évidemment, il y a des limites :
- Puissance limitée : un ATmega328P à 16 MHz, ce n’est pas fait pour de la fusion de capteurs lourde ou de la navigation complexe.
- Pas optimisé pour le temps réel exigeant : il faut coder proprement si tu veux une boucle de contrôle stable à 200–400 Hz.
Donc l’idée, c’est : utiliser Arduino comme plateforme d’apprentissage et de prototypage, pas refaire Ardupilot en version low-cost.
Prérequis matériels et compétences minimales
Avant même d’ouvrir l’IDE Arduino, assurons-nous que tu pars sur de bonnes bases.
Côté matériel, pour un quadri basique :
- 1 carte Arduino Nano ou Pro Mini 5 V / 16 MHz (petit, léger, suffisant pour un drone simple)
- 1 capteur MPU6050 (accéléromètre + gyroscope en I2C, ultra répandu)
- 1 récepteur radio PPM, SBUS ou PWM (en fonction de ta radio)
- 4 ESC compatibles signal PWM
- 4 moteurs brushless + hélices adaptés à ton châssis
- Une alimentation propre pour l’Arduino (via BEC 5 V) isolée du bruit des ESC autant que possible
Côté compétences en Arduino :
- Savoir utiliser l’IDE Arduino, téléverser un sketch, lire la console série
- Savoir lire un capteur I2C (ou au moins installer et utiliser une librairie toute faite)
- Comprendre la différence entre
loop()etsetup(), et ce qu’est une interruption - Savoir utiliser
millis()au lieu dedelay()(fondamental pour un drone)
Si tout ça est flou, commence par quelques mini-projets à côté (gyro + affichage, gestion de servo, lecture de PPM) avant de mettre tout ensemble sur un châssis.
Architecture logique d’un firmware de drone sous Arduino
Avant d’écrire la moindre ligne, il faut visualiser comment ton code va « respirer ». Un firmware de drone typique tourne autour de quelques blocs :
- Initialisation : capteurs, radio, timers, sorties moteurs, paramètres (PID, offsets…)
- Boucle de contrôle temps réel (100–500 Hz) :
- Lecture gyro/accéléro
- Filtrage / fusion (calcul attitude)
- Lecture des commandes radio
- Calcul PID pour chaque axe (pitch, roll, yaw)
- Mixage moteur
- Envoi des signaux aux ESC
- Tâches lentes (10–50 Hz) :
- Télémétrie série
- Vérification batterie / failsafe
- Changement de mode de vol, LEDs, etc.
L’erreur classique du débutant : mettre delay() partout, et obtenir une boucle de contrôle à 20 Hz qui rend le drone ingérable. Ton but : une boucle de contrôle régulière (par exemple 250 Hz, soit toutes les 4 ms) avec le moins de jitter possible.
Étape 1 : Préparer l’environnement Arduino et les librairies
1. Configurer l’IDE Arduino
- Installe la dernière version de l’IDE Arduino (ou Arduino IDE 2.x)
- Choisis ta carte (Nano, Pro Mini…) et le bon port série
- Désactive l’auto-scroll de la console série quand tu débogues des données qui arrivent vite, sinon tu deviens fou.
2. Installer les librairies indispensables
Pour gagner du temps, appuie-toi sur des libs éprouvées :
- MPU6050 ou Jeff Rowberg I2Cdevlib pour lire le gyro/accéléro
- PID_v1 (Brett Beauregard) si tu ne veux pas recoder un PID de zéro
- Une librairie PPM/SBUS ou ton propre code d’interruptions, en fonction de ton récepteur
Tu peux bien sûr tout coder à la main, mais au début, le temps que tu te fasses la main, mieux vaut sécuriser les briques de base avec des libs connues.
Étape 2 : Lire proprement les capteurs (MPU6050 & co.)
Le cœur de la stabilisation, c’est ton IMU (gyro + accéléro). Si tes mesures sont bruitées, décalées ou lentes, tout le reste sera pourri.
Points clés pour le MPU6050 :
- Utilise le bus I2C avec des câbles courts et bien soudés
- Fixe physiquement le module sur le châssis, bien orienté, avec des silent-blocs si possible
- Configure les plages de mesures (par exemple ±2000°/s pour le gyro, ±4 g pour l’accéléro)
Dans ton setup(), tu vas initialiser le capteur, vérifier qu’il répond, et éventuellement lancer une calibration gyro à plat (drone immobile sur une surface plane).
Ensuite, dans ta boucle temps réel, la séquence typique sera :
- Lire les valeurs brutes gyro + accéléro
- Appliquer ton offset de calibration
- Filtrer (filtre complémentaire simple ou DMP du MPU6050 si tu l’utilises)
- Obtenir un angle de pitch, roll, yaw exploitable
Tu peux déjà afficher ces angles sur la console série et secouer ton drone à la main pour vérifier que les valeurs bougent dans le bon sens. Ne passe pas à la suite tant que ça n’est pas propre.
Étape 3 : Récupérer les commandes radio
Un drone, ce n’est pas juste un gyroscope qui lutte contre le vent. Il doit aussi obéir à ta radio. Là, tout dépend du type de sortie de ton récepteur :
- PWM classique : 1 pin par voie (gourmand en entrées)
- PPM : toutes les voies sur une seule pin (très pratique avec Arduino)
- SBUS : bus série (un peu plus complexe à gérer sur Arduino classique)
Sur Arduino, le plus simple pour débuter est souvent le PPM :
- Tu branches la sortie PPM du récepteur sur une pin d’interruption (2 ou 3 sur Uno/Nano)
- Tu mesures le temps entre les fronts montants/descendants pour reconstruire les canaux
- Tu obtiens des valeurs en microsecondes (1000–2000 µs) que tu normalises en « commandes » (par exemple -500 à +500)
Encore une fois, avant de piloter un seul moteur, affiche tes canaux (gaz, roll, pitch, yaw, arm/disarm) sur la console série. Bouge chaque manche et vérifie que :
- Les valeurs bougent dans le bon sens (un roll à droite doit augmenter la valeur prévue pour le roll droit)
- Les plages sont cohérentes (1000 min, 1500 neutre, 2000 max environ)
Un mapping radio mal géré, c’est la garantie d’un premier vol catastrophique.
Étape 4 : Commander les moteurs et gérer le mixage
Un quadri X à 4 moteurs, ce n’est pas « un moteur pour chaque axe ». Tu as un mixage entre les commandes d’attitude et la puissance de chaque moteur.
Exemple de numérotation des moteurs pour un quad X :
- M1 : avant gauche
- M2 : avant droit
- M3 : arrière droit
- M4 : arrière gauche
Les formules de mixage typiques (simplifiées) pour la puissance de chaque moteur :
- M1 = Gaz + Pitch + Roll – Yaw
- M2 = Gaz + Pitch – Roll + Yaw
- M3 = Gaz – Pitch – Roll – Yaw
- M4 = Gaz – Pitch + Roll + Yaw
Concrètement, dans ton code, tu vas :
- Gérer un signal PWM vers chaque ESC (via
Servo.hou, mieux, en manipulant directement les timers pour plus de précision) - Limiter les valeurs envoyées (par ex. 1000–2000 µs)
- Empêcher les moteurs de tourner si le signal radio est perdu ou si le drone n’est pas armé
Commence par un petit test sans hélices : envoie un signal fixe (1200–1300 µs), vérifie que tes moteurs démarrent et tournent tous dans le bon sens. Inverse deux fils de phase si nécessaire sur les moteurs qui tournent à l’envers.
Étape 5 : Intégrer un PID simple pour la stabilisation
Sans PID, ton drone est une savonnette volante. Le PID permet d’ajuster en permanence la vitesse des moteurs pour corriger l’angle du drone.
Schéma classique :
- Entrée : consigne d’angle (venant de ta radio) et angle mesuré (venant de l’IMU)
- Erreur = consigne – mesure
- Ton contrôleur PID calcule une commande de correction (par axe)
- Tu injectes cette commande dans le mixage moteurs
Au début, contente-toi d’un PID par axe (pitch, roll, yaw) en mode angle (stabilisé). Quelques conseils pratiques :
- Commence uniquement avec P, mets I et D à zéro
- Augmente P jusqu’à ce que le drone commence à osciller rapidement, puis redescends légèrement
- Ajoute un peu de D pour calmer les oscillations et améliorer la réactivité
- Ajoute enfin du I pour corriger les erreurs lentes (dérives)
Tout ça se fait progressivement, en testant d’abord à la main, drone attaché ou posé au sol avec de petites impulsions de gaz, puis en vol très bas, dans un environnement dégagé.
Étape 6 : Gérer le temps réel sans bloquer la boucle
C’est souvent là que ça déraille : tu peux avoir un super PID, une bonne IMU, une radio propre, et un drone injouable parce que ta boucle tourne à 60 Hz avec des à-coups.
Quelques règles d’or :
- Jamais de
delay()dans ton code principal. Utilisemillis()oumicros()pour programmer les tâches périodiques. - Fixe une fréquence de boucle (par ex. 250 Hz) : calcule le temps écoulé entre deux tours de boucle avec
micros()et n’exécute la partie contrôle que si le pas de temps est atteint. - Place les tâches lentes (télémétrie, logs série) dans des blocs conditionnels du type « toutes les 50 ms ».
- Évite les opérations lourdes (float, trigonométrie) dans la boucle temps réel si possible : pré-calcule, simplifie, ou utilise des approximations.
Une bonne pratique : afficher régulièrement sur la console la fréquence effective de ta boucle (par exemple, toutes les secondes, le nombre de boucles effectuées). Si tu annonces 250 Hz et que tu en as 120, il faut optimiser.
Étape 7 : Ajouter les sécurités minimales
Un drone DIY mal sécurisé, c’est un blender volant. Il te faut au minimum :
- Arm / Disarm via la radio (switch dédié ou combinaison de manches)
- Failsafe radio : si la radio se coupe, les moteurs doivent s’arrêter
- Timeout IMU : si tu ne reçois plus de données cohérentes du gyro, tu coupes tout
- Vérification batterie (si tu as un capteur de tension) : avertir ou poser avant que la lipo soit morte
Concrètement, cela veut dire dans ton code :
- Une variable d’état (ARMED / DISARMED) qui conditionne l’envoi de gaz aux moteurs
- Une vérification de la validité du signal radio avant chaque calcul de commande
- Des valeurs de sortie moteurs forcées au minimum en cas de doute
Ne fais jamais confiance à ton code au point de tester la première fois avec les hélices montées à 50 cm de ta tête.
Erreurs fréquentes et galères classiques
Quelques pièges que je vois passer régulièrement :
- Utilisation massive de
delay(): la boucle devient lente et irrégulière, le drone oscille ou réagit en retard. - Mauvaise orientation de l’IMU : les corrections partent dans le mauvais sens, le drone amplifie les erreurs au lieu de les corriger.
- Mapping radio inversé : manche à droite = correction à gauche… et crash instantané.
- Alimentation sale : bruit des ESC qui parasite l’IMU ou l’Arduino, reset en plein vol.
- Trop de log série dans la boucle : le temps d’envoi des données sur l’USB flingue ton temps réel.
Diagnostic rapide : si en regardant la sortie série tu vois que ton temps de boucle fait le yoyo ou que tes angles sautent, corrige ça avant de parler de PID ou de tuning fin.
Aller plus loin : GPS, baromètre, modes de vol avancés
Une fois que tu maîtrises un quad stabilisé basique sur Arduino, tu peux commencer à t’amuser :
- Ajouter un baromètre (BMP280, MS5611) pour un maintien d’altitude rudimentaire
- Intégrer un GPS pour du position hold (mais attention, ça devient vite costaud pour un simple ATmega328P)
- Implémenter un mode acro (pilotage direct sur la vitesse de rotation, pour les amateurs de FPV et figures)
- Porter ton code sur une carte plus musclée (STM32, ESP32) si tu veux des boucles plus rapides et des algos plus lourds
L’intérêt de cette démarche « full DIY Arduino », ce n’est pas de battre Betaflight sur le terrain, mais de savoir ce qu’il se passe derrière chaque paramètre, chaque oscillation, chaque comportement bizarre en vol.
Une fois que tu as passé quelques soirées à traquer un bug d’interruption ou un gyro mal calibré, tu ne regardes plus une carte de vol toute faite de la même manière. Et surtout, tu es capable de diagnostiquer et réparer bien plus vite ton matos, maison ou non.