Journalia

3 entries · drone

· # drone

Parcours d'apprentissage — Comprendre l'IA du Quadcopter

Un parcours en 6 étapes, pensé pour ce projet précis. Chaque étape = un objectif clair, une ressource, une action dans le code, une question pour valider.

Avance à ton rythme. Reviens-y autant que tu veux.


Étape 0 — Voir le truc tourner (30 min)

Objectif : avoir une image mentale avant toute théorie.

Action :

  • Installer le projet (cf. README)
  • Lancer python -m quadai et jouer manuellement aux flèches
  • Lancer en mode PID, puis en mode SAC, comparer

Validation : tu peux décrire en une phrase ce que fait le drone et ce qui change entre les modes.


Étape 1 — La physique (1 h)

Objectif : comprendre que le drone bouge à cause de Newton, pas de magie.

Concepts :

  • Force = masse x accélération (F = ma)
  • Accélération vers vitesse vers position (par intégration)
  • Couple : différence entre les deux hélices = rotation

Ressource :

  • Vidéo "Quadcopter dynamics explained" (n'importe laquelle de 10 min sur YouTube)

Action dans le code :

  • Lire src/quadai/SAC/env_SAC.py lignes 142 à 167
  • Repérer : xdd (accélération horizontale), ydd (verticale, contient la gravité), add (rotation)
  • Voir comment les deux poussées d'hélices génèrent une force et un couple

Validation : tu peux pointer la ligne où la gravité est appliquée et celle où la rotation est calculée.


Étape 2 — Le contrôle classique : PID (2 h)

Objectif : voir qu'on peut piloter le drone avec 30 lignes de code sans IA.

Concepts :

  • Erreur = position cible - position actuelle
  • P (proportionnel) : corrige proportionnellement à l'erreur
  • I (intégral) : corrige les erreurs qui s'accumulent (vent constant, etc.)
  • D (dérivé) : amortit, anticipe

Ressource :

  • Vidéo "PID controller explained" par Brian Douglas sur YouTube (excellent, 10 min)

Action dans le code :

  • Lire src/quadai/PID/controller_PID.py en entier (35 lignes)
  • Reconnaître les 3 termes P, I, D dans la méthode compute
  • Voir comment il est utilisé dans balloon.py

Validation : tu peux expliquer pourquoi un P seul oscille et pourquoi le D calme l'oscillation.


Étape 3 — Bases du Machine Learning (3 h)

Objectif : comprendre l'idée d'optimiser une fonction par gradient.

Concepts :

  • Modèle = fonction f(x) = y avec des paramètres ajustables
  • Loss : à quel point on se trompe
  • Gradient descent : on tourne les paramètres dans le sens qui réduit la loss
  • Réseau de neurones : juste une fonction f très flexible avec beaucoup de paramètres

Ressources :

  • 3Blue1Brown, série "Neural Networks" (4 vidéos, 1 h total), INDISPENSABLE
  • StatQuest "Gradient Descent" sur YouTube

Action : pas de code dans ce projet pour cette étape, c'est de la culture générale.

Validation : tu peux expliquer en français ce que fait l'opération "rétropropagation" sans réciter une formule.


Étape 4 — Le Reinforcement Learning (4 h)

Objectif : comprendre la boucle agent-environnement et ce que SAC apprend.

Vocabulaire à maîtriser :

  • Agent : ce qui décide (le SAC)
  • Environnement : le simulateur du drone
  • État / observation : ce que l'agent perçoit (les 7 nombres)
  • Action : ce que l'agent fait (les 2 nombres)
  • Reward : signal numérique de qualité
  • Épisode : une partie complète
  • Politique : la fonction état vers action

Ressources :

  • Hugging Face Deep RL Course, unités 1 et 2 (gratuit, 2-3 h), fait coder un agent simple
  • Optionnel : OpenAI Spinning Up, "Intro to RL" (lecture)

Action dans le code :

  • Lire src/quadai/SAC/env_SAC.py lignes 75 à 127 (reset et get_obs)
  • Lire la fonction step lignes 129 à 206
  • Identifier : où est calculé le reward ? Quand l'épisode se termine-t-il ?
  • Lire train_SAC.py (50 lignes) : reconnaître la boucle d'entraînement

Validation : tu peux expliquer ce que représentent chacun des 7 nombres en entrée du SAC, et pourquoi ce reward précis pousse le drone à atteindre la cible sans crasher.


Étape 5 — Sim-to-real : du simulateur au monde réel (2 h)

Objectif : comprendre pourquoi un agent qui marche en simu ne marche pas forcément en vrai, et comment on franchit le gap.

Concepts :

  • Reality gap : différences entre simu et réel (bruit capteurs, latence, masse réelle, vent)
  • Domain randomization : entraîner sur 1000 simulateurs différents pour devenir robuste
  • System identification : caler le simulateur sur des mesures du vrai drone
  • Architecture hiérarchique : RL haut niveau + PID bas niveau

Ressources :

  • Article ou vidéo sur le projet Swift de l'ETH Zurich (drone racing autonome qui bat les humains)
  • Mots-clés à googler : "sim-to-real reinforcement learning"

Action dans le code (expérience) :

  • Modifier env_SAC.py pour ajouter du bruit aux observations
  • Tester le SAC pré-entraîné : il s'effondre
  • Discuter ce que ça implique pour un déploiement réel

Validation : tu peux citer 3 raisons concrètes pour lesquelles ce SAC ne marcherait pas sur un vrai drone.


Récap visuel

Étape 0 : voir       -> image mentale
Étape 1 : physique   -> comprendre le monde simulé
Étape 2 : PID        -> contrôler sans IA
Étape 3 : ML / DL    -> comprendre les réseaux
Étape 4 : RL         -> comprendre l'apprentissage par récompense
Étape 5 : sim-to-real -> comprendre les limites

Temps total estimé : ~12 h, étalable sur plusieurs semaines.


Phase 2 — Du jeu au vrai drone autonome

Cette phase est pour toi si ton but final est :

  • faire voler un vrai drone qui exécute des missions (waypoints, suivi d'objet, exploration)
  • travailler dans la robotique / l'aérospatial

C'est un parcours sérieux : compte 1 à 2 ans de travail régulier pour aller de zéro à un drone qui exécute une vraie mission de façon fiable. Voici l'échelle.


Étape 6 — Simu 3D réaliste : gym-pybullet-drones (1 semaine)

Objectif : passer du 2D au 3D avec une vraie physique de quadricoptère.

C'est quoi : un projet open source qui fait voler des drones en 3D avec PyBullet (moteur physique), exposés en gym.Env exactement comme ici. Tu réutilises tout ton vocabulaire RL.

Action :

Validation : tu fais voler un drone 3D vers un waypoint avec un agent que tu as entraîné toi-même.


Étape 7 — Capteurs, perception, vision (1 mois)

Objectif : un vrai drone ne connaît pas sa position magiquement. Il la déduit de capteurs bruités.

Concepts :

  • IMU (accéléromètre + gyro) : mesure les accélérations, dérive vite
  • Baromètre : altitude, bruyant
  • GPS : position absolue, ~1m de précision, pas en intérieur
  • Caméra : pour vision par ordinateur (détection, suivi)
  • Filtre de Kalman / EKF : fusionner tout ça en une estimation propre

Ressources :

  • Cours Coursera "State Estimation and Localization for Self-Driving Cars" (les concepts sont identiques pour un drone)
  • OpenCV tutorials pour la vision (détection de couleur, ArUco markers, optical flow)

Action :

  • Ajouter une caméra simulée à gym-pybullet-drones
  • Faire détecter un marqueur ArUco au drone et le suivre

Validation : tu sais expliquer pourquoi un drone sans GPS dérive et comment l'EKF le corrige.


Étape 8 — PX4 SITL : le vrai firmware en simulation (1 mois)

Objectif : utiliser le vrai logiciel qui tourne sur les drones professionnels, mais en simulation.

C'est quoi :

  • PX4 ou ArduPilot : firmwares open source qui équipent 90% des drones autonomes (DJI custom, Skydio, projets pro)
  • SITL = Software In The Loop : le firmware tourne sur ton PC, connecté à un simulateur (Gazebo ou jMAVSim)
  • Tu pilotes via MAVLink (le protocole standard) avec MAVSDK ou DroneKit en Python

Ressources :

Action :

  • Installer PX4 SITL + Gazebo
  • Écrire un script Python qui décolle, va à un waypoint, atterrit
  • C'est EXACTEMENT le code que tu utiliseras sur un vrai drone, juste connecté à une simu pour l'instant

Validation : ton script Python fait décoller, naviguer et atterrir un drone simulé via MAVLink.


Étape 9 — Premier vrai drone : Crazyflie ou Tello (1-2 mois, ~50-300 €)

Objectif : ton code décolle pour de vrai.

Choix matériel :

  • Crazyflie 2.1 (~250 €) : 30g, sécurisé, ouvert, contrôlable en Python, idéal pour la recherche
  • DJI Tello EDU (~150 €) : SDK Python officiel, plus robuste, caméra incluse, idéal pour débuter
  • Attention : évite les drones jouet pas-SDK, tu ne pourras rien programmer dessus

Action :

  • Reprendre le script de l'étape 8, le pointer sur le vrai drone
  • Premier vol autonome : décollage, carré, atterrissage
  • Suivi d'un marqueur visuel avec la caméra
  • Sécurité : toujours dehors ou en cage filet, batterie chargée, kill switch

Validation : tu fais exécuter une mission simple à un vrai drone à partir de ton code Python.


Étape 10 — Drone custom avec companion computer (3-6 mois, ~500-1500 €)

Objectif : construire un drone capable de vraies missions (vol longue durée, charge utile, autonomie GPS-denied).

Stack typique :

  • Frame + moteurs + ESC + batterie LiPo
  • Flight controller : Pixhawk (PX4) ou Cube Orange
  • Companion computer : Raspberry Pi 4 ou Jetson Nano (pour la vision/IA en temps réel)
  • ROS 2 : middleware robotique standard pour orchestrer tout ça
  • Caméra + capteurs additionnels selon la mission

Compétences à acquérir en parallèle :

  • Linux embarqué (le RPi/Jetson tourne sous Linux)
  • C++ (les firmwares pro sont en C++ ; Python ne suffira plus)
  • ROS 2 (cours TheConstruct ou Articulated Robotics sur YouTube)
  • Électronique de base (PWM, I2C, SPI, soudure)
  • Réglementation drone selon ton pays (en France : DGAC, formations télépilote)

Action :

  • Assembler le drone avec un kit
  • Le configurer (calibration capteurs, accordage PID, modes de vol)
  • Faire tourner ton code Python/C++ sur le companion computer
  • Réaliser une mission simple : "décolle, va à GPS X, prends une photo, reviens"

Validation : ton drone exécute une mission complète sans intervention humaine.


Étape 11 — Spécialisation "missions" (continu)

À ce stade tu as un drone fonctionnel. Les vraies missions intéressantes demandent une compétence parmi :

  • Path planning : algos A*, RRT* pour planifier un trajet en évitant des obstacles
  • SLAM : cartographier un environnement inconnu en temps réel (intérieur sans GPS)
  • Vision avancée : détection d'objets en deep learning (YOLO), tracking, segmentation
  • RL avancé en sim-to-real : transférer une politique apprise en simu vers le vrai matériel (domain randomization)

C'est là que tu deviens spécialiste et que ton CV intéresse l'industrie.


Étape 12 — Vol en essaim (swarm) (continu)

Objectif : faire coopérer plusieurs drones (formation, exploration coordonnée, spectacles type Intel).

C'est une spécialisation à part entière. Tu peux y aller en parallèle des étapes 6 à 10, surtout côté simulation.

Concepts à maîtriser

  • Boids (Reynolds, 1986) : 3 règles simples, séparation, alignement, cohésion, qui produisent un essaim émergent. C'est l'archétype, à coder absolument.
  • Consensus & formation control : algos pour maintenir une formation (ligne, V, grille), théorie des graphes
  • Allocation de tâches : qui fait quoi dans le groupe (auctions, market-based)
  • Multi-Agent RL (MARL) : RL avec plusieurs agents qui apprennent ensemble (MADDPG, QMIX, MAPPO)
  • Communication : centralisée (un serveur orchestre) vs décentralisée (chaque drone décide)
  • Localisation relative : se positionner par rapport aux voisins, pas seulement absolument

Ressources

  • Vidéo Boids de Sebastian Lague (YouTube, 15 min) : implémentation visuelle, point de départ idéal
  • Cours Erdos Institute "Multi-Agent Systems" (gratuit en ligne)
  • Crazyswarm2 (https://imrclab.github.io/crazyswarm2/) : framework ROS 2 de référence pour la recherche swarm
  • Papiers Vijay Kumar (UPenn) & Raffaello D'Andrea (ETH) : les deux labos historiques du swarm

Action, simulation pure

  1. Niveau 0 : code les Boids en 2D toi-même en Python/pygame (1 weekend), tu vois émerger le comportement de groupe
  2. Niveau 1 : multi-drone dans gym-pybullet-drones (l'env supporte déjà N drones)
  3. Niveau 2 : Crazyswarm2 en simulation, tu écris du code qui marchera ensuite tel quel sur la vraie flotte

Action, vrai matériel

Le standard mondial de la recherche swarm est le Crazyflie 2.1 :

  • ~250 € l'unité, Bitcraze (Suède)
  • Léger (30 g), sécurisé en intérieur
  • Conçu pour le swarm dès l'origine
  • Système de positionnement intérieur Lighthouse (~250-500 €) ou Loco (UWB)
  • Tu peux faire voler 20 drones dans ton salon

Budget réaliste pour un mini-essaim chez toi :

  • 5 Crazyflies + radio Crazyradio + base Lighthouse : ~2000 €
  • C'est l'investissement standard pour un thésard ou un projet sérieux

Validation

Tu fais voler 3-5 Crazyflies en formation, qui suivent des trajectoires coordonnées et évitent les collisions inter-drones, d'abord en simu, puis en vrai.


Annexe, Simulation vs matériel : que peut-on simuler ?

Réponse courte

Quasi tout peut être simulé. La simulation suffit pour apprendre et prototyper 80 % du chemin. Le matériel devient nécessaire :

  1. Quand tu veux valider que ton code marche dans le réel
  2. Quand le projet exige des choses qu'aucune simu ne reproduit fidèlement (vent, salissures, défaillances)
  3. Pour un portfolio : "je l'ai fait voler en vrai" pèse 10 fois plus qu'une démo simu sur un CV

Ce qui se simule très bien (gratuit)

Domaine Outil(s) Niveau de réalisme
Physique de quadricoptère gym-pybullet-drones, PX4 SITL + Gazebo, AirSim Très bon
Capteurs (IMU, GPS, baromètre) PX4 SITL avec bruit configurable Bon
Caméra et vision Gazebo, AirSim, Isaac Sim (Nvidia) Très bon (photoréaliste)
Vol d'essaim Crazyswarm2 simu, gym-pybullet-drones multi Très bon
Vent, turbulences Gazebo (modèles existants) Moyen
RL training Tous les ci-dessus + sb3, RLlib Très bon

Ce qui se simule mal ou pas du tout

  • Vraies failures matérielles : moteur qui faiblit, ESC qui déraille, batterie qui chute brutalement
  • Effets aérodynamiques fins : effet de sol, interactions inter-drones rapprochés (downwash)
  • Bruit capteur réel : un IMU réel a des biais, dérives thermiques, etc. que les simus modélisent imparfaitement
  • Latence radio et perte de paquets réels
  • Problèmes mécaniques : vibrations qui pourrissent l'IMU, équilibrage hélices, soudures
  • Conditions extérieures : soleil qui aveugle la caméra, pluie, vent en rafale

Quand acheter du matériel ?

  • Phase 1 (étapes 0-5, ce projet) : rien. Que de la simu.
  • Étape 6 (gym-pybullet-drones) : rien.
  • Étape 7 (perception) : rien, sauf une webcam pour jouer avec OpenCV.
  • Étape 8 (PX4 SITL) : rien. C'est la grande force de PX4.
  • Étape 9 (premier vol) : OUI. Premier achat. Choix selon ton objectif (voir tableau ci-dessous).
  • Étape 10 (custom) : OUI, drone custom. 500-1500 €.
  • Étape 12 (swarm) : OUI si tu veux du vrai swarm. Plusieurs Crazyflie + Lighthouse.

Tableau d'achat, quel drone selon ton objectif

Si tu veux Achète Budget Pourquoi
Démarrer simple (étape 9 facile, vision, missions basiques en intérieur/extérieur) DJI Tello EDU ~150 € SDK Python officiel, robuste, caméra incluse, pas besoin d'assemblage
Faire de la recherche RL / sim-to-real / contrôle bas-niveau Crazyflie 2.1 + Crazyradio ~250-300 € Open source, ultra léger, contrôle total du firmware, communauté académique
Faire du swarm 3-10 Crazyflie + base Lighthouse v2 ~1500-3000 € Le standard mondial du swarm de recherche
Faire des vraies missions extérieures (GPS, payload, longue durée) Drone custom Pixhawk + RPi/Jetson 500-1500 € Tu maîtrises l'électronique, charge utile, autonomie
Vision et IA embarquée sérieuse Drone custom + Jetson Orin Nano 1000-2000 € GPU embarqué pour deep learning en vol

Mon conseil de séquencement

  1. Mois 0-6 : tout en simu. Aucun achat. Phase 1 + étapes 6-8.
  2. Mois 6-9 : achète un Tello EDU (~150 €). Tu touches du réel sans risquer 1000 €. Étape 9.
  3. Mois 9-12 : achète un Crazyflie 2.1 (~250 €). Tu commences le swarm en solo et tu as un drone "recherche-grade".
  4. Mois 12-18 : selon ton intérêt :
    • Branche swarm vers 3-5 Crazyflies de plus + Lighthouse
    • Branche missions outdoor vers drone custom Pixhawk
  5. Au-delà : tu as un vrai portfolio physique, tu vises des stages/jobs ciblés.

Total budget mini pour aller jusqu'à un mini-essaim et un drone outdoor custom : ~2000-3000 € étalés sur 18 mois. C'est l'équivalent d'un cours universitaire mais sans frais de scolarité.


Carte mentale de la progression complète

PHASE 1, Comprendre (3-6 mois, ce projet)
  Étapes 0-5 : physique, PID, ML, RL, sim-to-real
        |
        v
PHASE 2, Construire vers le réel (1-2 ans)
  Étape 6  : simu 3D (gym-pybullet-drones)
  Étape 7  : capteurs et perception
  Étape 8  : PX4 SITL + MAVLink
  Étape 9  : premier vrai drone (Crazyflie / Tello)
  Étape 10 : drone custom + companion computer + ROS 2
  Étape 11 : spécialisation mission (vision, SLAM, planning)

Pistes carrière (robotique / aéro)

  • Profils recherchés : ingénieurs PX4/ArduPilot, vision par ordinateur, RL appliqué, contrôle, embedded
  • Entreprises drones France/EU : Parrot, Delair, Diodon, Squadrone, Hexadrone
  • Aéro classique : Airbus, Dassault, Thales, Safran (souvent plus de C++ et de certif que de Python)
  • Recherche : ONERA, ETH Zurich, INRIA Sophia (équipe Chorale, AgileFlight)
  • Concours / portfolios : RoboMaster, AlphaPilot, IMAV, un bon projet drone visible sur GitHub vaut beaucoup à l'embauche

Annexe, Calcul, GPU et infrastructure d'entraînement

Pour entraîner des agents RL, tu auras besoin de puissance de calcul. Voici quoi utiliser et quand.

Évaluer ton matériel local

Commande utile :

free -h                                   # RAM disponible
lspci | grep -iE 'vga|3d'                 # GPU
nvidia-smi                                # si GPU Nvidia

Ordre de grandeur des besoins :

Tâche Besoin minimal
Ce projet (SAC 2D) CPU correct, 8 Go RAM
gym-pybullet-drones (3D, sans vision) CPU multi-coeurs, 16 Go RAM
RL avec vision (caméra simulée) GPU dédié (Nvidia recommandé)
Vision deep learning (YOLO, etc.) GPU >= 8 Go VRAM
Multi-agent RL / swarm RL GPU + beaucoup de coeurs CPU

Avant un entraînement local : ferme Chrome / apps gourmandes, vise au moins 8 Go RAM dispo (free -h doit montrer ~8G+ "available").

Pourquoi pas GitLab CI / GitHub Actions pour l'entraînement

Tu pourrais penser "je pousse mon code, le CI entraîne pour moi", c'est une fausse bonne idée :

  • Les runners gratuits n'ont pas de GPU
  • Les jobs ont un timeout (1h sur GitLab.com, 6h sur GitHub Actions free)
  • Pour avoir du GPU il faut un self-hosted runner sur ta propre machine GPU = tu paies déjà la GPU, le CI n'apporte rien

Le bon pattern : GitLab CI pour les tests (lint, unit tests), cloud GPU séparé pour l'entraînement.

GitLab CI / GitHub Actions  ->  tests CPU rapides (push automatique)
       | (déclenchement manuel)
       v
Cloud GPU (Modal / Vast.ai)  ->  entraînement long
       |
       v
Sauvegarde modèle (S3 / artifacts)

Options cloud GPU, du gratuit au pro

Service Coût Pour quoi Notes
Google Colab Free 0 € Prototypage rapide T4 GPU, sessions 12h max, idéal pour démarrer
Kaggle Notebooks 0 € Entraînements moyens 30h/semaine de P100, plus stable que Colab
Colab Pro ~10 €/mois Usage régulier A100/V100 parfois, sessions 24h
Modal.com ~0.30-1 €/h Lancer un script Python en cloud Pay-per-second, parfait pour python train.py
Vast.ai ~0.20-0.50 €/h Entraînements longs Marketplace de GPUs particuliers (RTX 3090/4090)
RunPod ~0.30-2 €/h Pods persistants Bon UI, machines réutilisables
Lambda Labs ~0.50-2 €/h Recherche pro A100, H100

Recommandation par phase

Phase 1 (étapes 0-5, ce projet) : 100 % local, ton CPU suffit. 0 €.

Phase 2 (étapes 6-7, simu 3D + perception) :

  • Prototypage sur Colab Free
  • Quand un run prend > 2h, bascule sur Modal (lance ton script Python comme une fonction cloud, paye uniquement le temps de calcul)
  • Budget réaliste : 5-15 € par expérience d'entraînement long

Phase 2 (étapes 8-12, PX4, hardware, swarm) :

  • Pour les modèles RL lourds : Modal ou Vast.ai
  • Pour les notebooks d'expérimentation : Colab Pro (10 €/mois) ou Kaggle
  • Budget réaliste : 20-50 € par mois pendant les phases d'entraînement intensif

Workflow type pour un entraînement

  1. Développer en local : tu écris et débugges train.py avec un mini-config (peu d'epochs)
  2. Tester sur Colab gratuit : tu uploades, tu lances un run court avec GPU pour vérifier que ça tourne
  3. Lancer le run final sur Modal/Vast.ai : tu commits le code, tu déclenches le job, tu reçois le modèle entraîné quelques heures plus tard
  4. Téléchargement du modèle, test local en inférence (qui ne demande pas de GPU)

Astuces économiques

  • Stable-baselines3 supporte le multiprocessing CPU : sur ton 18-coeurs, make_vec_env(..., n_envs=16) accélère l'entraînement RL plus qu'un GPU petit pour les politiques sans vision
  • Garde tes modèles intermédiaires (checkpoints) : un run interrompu peut être repris au lieu de redémarrer de zéro
  • Profile avant de payer : un run qui rame 5h sur Colab gratuit peut souvent être réduit à 30 min en optimisant (batch size, n_envs, type d'observation)

Aide-mémoire, où regarder dans le code

Sujet Fichier Lignes
Physique du drone src/quadai/SAC/env_SAC.py 142-167
Observations (7 nombres) src/quadai/SAC/env_SAC.py 89-127
Reward src/quadai/SAC/env_SAC.py 171-191
Action et step src/quadai/SAC/env_SAC.py 129-206
PID complet src/quadai/PID/controller_PID.py 1-35
Entraînement SAC src/quadai/SAC/train_SAC.py 1-50
· # drone

PID vs SAC : option ou complémentaire ?

Dans le jeu Quadcopter-AI 2D ce sont des alternatives (3 pilotes interchangeables : Human, PID, SAC), mais dans la vraie vie ils sont presque toujours COMPLEMENTAIRES via un pattern d'architecture appelé "contrôle hiérarchique" ou "RL sur PID".

Architecture standard d'un drone autonome moderne (DJI, Skydio, recherche académique) :

IA / RL — décisions stratégiques (10-100 Hz, complexe, "smart") ↓ envoie un setpoint type "va à (X, Y, Z)" PID — contrôle bas-niveau (1000-2000 Hz, simple, "fiable") ↓ commandes hélices Moteurs

Le RL choisit QUOI faire (mission, planification). Le PID choisit COMMENT le faire (stabiliser, suivre une consigne).

Avantages comparés :

  • PID : très rapide (microsecondes), stable mathématiquement, tourne sur un microcontrôleur 1$, mais bête et figé
  • RL : intelligent et adaptatif, mais lent, imprévisible aux limites, demande GPU embarqué

Trois patterns d'intégration concrets :

  1. Couches superposées (le standard industriel — Skydio, DJI)
  2. RL produit les setpoints d'un PID (recherche ETH Zurich, Swift drone racing)
  3. RL en sécurité, PID en opération normale (recherche MIT robustesse)

Implication pour mon parcours : sur un vrai drone, je n'écrirai jamais le PID moi-même — PX4 (firmware standard) contient déjà une cascade de ~10 PIDs au bas niveau. J'écrirai la couche stratégie en Python/C++ qui leur envoie des consignes via MAVLink. Le RL pourrait remplacer une partie de cette stratégie haut niveau (ex: un agent qui apprend à choisir le meilleur waypoint dans un labyrinthe), mais le PID en bas restera toujours.

Erreur classique du débutant : "je vais faire un drone 100% IA, c'est plus moderne" — presque toujours mauvaise idée. L'approche moderne 2025 = PID pour la fondation + IA aux endroits où elle apporte vraiment (perception, décision haut niveau, adaptation).

Resume : un drone autonome moderne, c'est toujours du PID + de l'IA, jamais l'un sans l'autre.

· # drone

Projet Quadcopter-AI — coordonnées

Chemin local : /home/pham/work/lab/Quadcopter-AI Repo Git (origin) : git@gitlab.com:spham/quadcopter-ai.git Repo upstream original : https://github.com/AlexandreSajus/Quadcopter-AI

Fichiers importants ajoutés pendant l'apprentissage :

  • parcours-apprentissage.md (à la racine) : parcours complet en 6+6 étapes du débutant au drone autonome avec missions, plus annexes (sim vs matériel, calcul/GPU)
  • apprentissage/boids.py : simulateur d'essaim Reynolds avec 3 sliders interactifs (séparation, alignement, cohésion) — premier pas vers le swarm

Setup local :

  • Venv Python à .venv/ (Python 3.12)
  • Dependances installées : pygame 2.6.1, numpy 2.4, stable-baselines3 2.8, gym 0.26.2 (compat), shimmy 2.0
  • Pour activer : source .venv/bin/activate
  • Pour lancer le jeu : .venv/bin/python -m quadai
  • Pour lancer Boids : .venv/bin/python apprentissage/boids.py

Corrections apportées :

  • requirements.txt original force pip==21 (à cause de gym 0.21 cassé), contourné par install moderne avec gym 0.26 + shimmy
  • balloon.py : 3 blits patchés pour wrapper les coords float en int (pygame 2.6 strict sur les types)