Architecture du Système

Le système Drone Control est conçu autour d'une architecture monorepo robuste permettant de coordonner une flotte de mini-drones. Il résout de nombreux défis de concurrence matérielle et d'interface utilisateur en isolant efficacement chaque composant.

Vue d'ensemble des Composants

L'application est divisée en plusieurs grands modules communicants :

1. Backend (backend/) Le cœur du système, développé en Python 3.11+. Il orchestre les drones, la détection vidéo et les communications avec l'interface. Grâce à la librairie drone_multiproc, les différents services (API web, traitement vidéo, logique de flotte) tournent dans des processus indépendants. Cela permet de contourner le Global Interpreter Lock (GIL) de Python et d'assurer une stabilité maximale, même sous forte charge vidéo.
2. Frontend (frontend/) Une application Single Page Application (SPA) moderne construite avec React 19, TypeScript, Vite et TailwindCSS 4. Elle communique avec le backend via WebSockets pour offrir un suivi en temps réel et un contrôle réactif.
3. Adaptateurs et Pilotes de Drones (drone-adapter/ et drones/ryze-tello/) Une couche d'abstraction permettant d'instrumenter différents types de drones. Actuellement, l'implémentation est optimisée pour la gestion des DJI / Ryze Tello.
4. Détection Vidéo (drone-detection/) Un processeur de vision par ordinateur accéléré par GPU. Il exploite les modèles YOLO (Nano et Small) via TensorRT et CUDA pour offrir une détection et un suivi de la trajectoire à haut framerate des éléments filmés par les drones.

Chargement Dynamique (Auto-Discovery)

L'une des forces du backend logé au cœur de cette architecture est son mécanisme de discovering dynamique. Au démarrage, l'application parcoure le PYTHONPATH et les dossiers annexes pour charger automatiquement à la volée les modules d'Intelligences Artificielles (comme drone_detection) ainsi que les adaptateurs de drones. S'ils sont trouvés, l'application greffe directement leurs fonctionnalités au serveur WebSocket sans la moindre recompilation nécessaire.

Le Défi de la Concurrence Wi-Fi (Namespaces Réseau)

L'un des défis matériels majeurs du pilotage de drones Tello réside dans le fait que chaque drone crée son propre point d'accès Wi-Fi (AP), attribuant typiquement la même plage d'adresses IP. Un système d'exploitation standard ne permet généralement pas de gérer plusieurs routeurs et adresses identiques sur une même pile réseau de manière efficace.

La Solution déployée : L'application utilise les Namespaces Réseau Linux (netns). Lors du démarrage, l'application assigne dynamiquement les dongles Wi-Fi physiques de l'ordinateur à des environnements réseau virtuellement isolés (ex: ns-drone-1, ns-drone-2). Le trafic de chaque drone est ainsi parfaitement encadré, sans conflit IP avec les autres drones de la flotte ou l'accès internet de l'hôte.

Exigence de Privilèges

L'orchestration des périphériques matériels via des namespaces Linux exige d'isoler physiquement les cartes réseaux. C'est l'exclusive raison pour laquelle l'application backend s'exécute fatalement avec des droits administrateurs (root / sudo). Sans cela, la modification des NetNS par le kernel serait rejetée.

Base de données et État

Les événements, logs et l'état centralisé de la flotte s'appuient sur une base de données embarquée intégrée par le backend. Lors de l'initialisation du programme principal, un fichier db.sqlite est automatiquement créé (s'il n'existe pas déjà) dans le répertoire courant courant (working directory) depuis lequel le script est exécuté. Cette stratégie par SQLite permet un accès rapide, simple et transportable à l'historique sans devoir gérer l'installation et l'instance d'un SGBD additionnel.