Un simulateur de vol pour la compétition AI Grand Prix
La startup Elodin, spécialisée dans les logiciels aérospatiaux, a rendu public aujourd'hui un simulateur de vol open source destiné à la préparation de la compétition AI Grand Prix organisée par Anduril. Ce concours, doté d'une récompense de 500 000 dollars, oppose des drones autonomes dans une course d'obstacles. Le simulateur, baptisé Elodin AI Grand Prix race sim harness, permet aux concurrents et au public intéressé de commencer à écrire du code de pilote automatique dès maintenant, avant la sortie du premier simulateur officiel de qualification virtuelle.
Le projet est hébergé sur GitHub sous le dépôt elodin-sys/ai-grand-prix et fonctionne sur macOS et Linux (le sous-système Windows pour Linux est également fonctionnel). L'installation se résume à une commande uv sync et une compilation de Betaflight d'environ cinq minutes.
Un stack technique complet et ouvert
Le simulateur met en œuvre une physique rigide 6-DOF (degrés de liberté), la dynamique des moteurs, la traînée, une contrainte au sol, des capteurs multi-taux (IMU, baromètre, magnétomètre), ainsi qu'une caméra avant rendue par GPU en 640×360 pixels, inclinée à +20 degrés conformément au cahier des charges technique VADR-TS-002 publié par les organisateurs.
Au cœur du système, Betaflight — le firmware de vol open source largement utilisé dans le monde des drones de course — s'exécute dans sa version SITL (Software In The Loop) réelle, avec la synchronisation PID activée. Un pont logiciel d'environ 80 lignes sérialise les paquets de données (FDM, RC, PWM) sur UDP et synchronise les deux côtés à 1 kHz, assurant qu'un réglage effectué sur ce simulateur sera identique sur un drone réel.
Les participants n'ont à modifier qu'un seul fichier, solver/, qui contient une fonction unique autopilot(update: SensorUpdate) -> RCCommand. Cette fonction reçoit à chaque tick les mesures de l'IMU, la position et l'orientation du drone, les données barométriques et magnétiques, ainsi qu'une image caméra facultative. Aucun GPS, ni profondeur, ni régime moteur n'est transmis, conformément au contrat de télémétrie du simulateur officiel.
Un exemple basique de pilote (un contrôleur PID de position et d'altitude, couplé à une liste de portes codée en dur) est fourni pour permettre un premier décollage et passage de portes dès le premier jour.
Une architecture née de l'expérience industrielle
Le noyau physique d'Elodin, nommé nox, est écrit en Rust avec un modèle ECS (Entity Component System) et un moteur de physique compilé à la volée (JIT). Il dispose de liaisons Python, d'un éditeur 3D connecté à une base de données de télémétrie temporelle (elodin-db) via TCP, et d'un petit lanceur de processus (s10) qui permet au même point d'entrée Python de lancer tous les composants nécessaires : contrôleur de vol, serveur de rendu, estimateur externe.
Selon l'équipe d'Elodin, la particularité de cette approche réside dans le fait que la physique est écrite en code de style JAX (bibliothèque de calcul numérique avec accélération GPU), avec des fonctions @el.map opérant sur des composants typés, ce qui facilite les simulations Monte Carlo, l'accélération GPU et les rejouabilités déterministes bit à bit. L'ensemble du moteur et de l'éditeur est disponible sous licence Apache-2.0.
Limitations et divergences avec le simulateur officiel
Le simulateur présente plusieurs limitations explicites. Il utilise les paquets UDP de Betaflight plutôt que le protocole MAVLink, ce qui nécessitera une couche d'adaptation pour se connecter au simulateur de qualification officiel. L'état du monde est exposé dans le repère ENU (Est-Nord-Haut) alors que le cahier des charges stipule NED (Nord-Est-Bas). Les effets atmosphériques se résument à un coefficient de traînée unique : ni turbulence, ni effet de sol, ni chute de tension de batterie ne sont modélisés.
Une incohérence interne du cahier des charges officiel concernant le champ de vision de la caméra est également signalée : la spécification annonce un champ vertical de 90 degrés, mais les paramètres intrinsèques qu'elle fournit impliquent un champ vertical d'environ 58,72 degrés et un champ horizontal de 90 degrés. Elodin a choisi de suivre les paramètres intrinsèques, en partant du principe que le simulateur officiel fera de même.
Un appel à la contribution
Elodin sollicite les retours de la communauté, en particulier des personnes ayant développé des simulateurs pour du contrôle temps réel dur, des participants à l'AI Grand Prix, et toute personne intéressée par l'ergonomie de l'API de pilotage ou l'intégration de contrôleurs de vol en boucle fermée. Le dépôt contient une section « Opportunités d'amélioration » détaillée dans le fichier ARCHITECTURE.md, et les contributions (pull requests) sont les bienvenues.
