🤖 AI

An Open-Source Modular Benchmark for Diffusion-Based Motion Planning in Closed-Loop Autonomous Driving

Cet article présente un benchmark open-source modulaire intégré à la pile Autoware qui décompose un planificateur de mouvement par diffusion monolithique en modules exécutables indépendamment en C++ natif, permettant ainsi une évaluation en boucle fermée avec des paramètres configurables à l'exécution et une réduction significative de la latence et de l'erreur de distance finale par rapport aux méthodes de déploiement existantes.

Auteurs originaux : Yun Li, Simon Thompson, Yidu Zhang, Ehsan Javanmardi, Manabu Tsukada

Publié 2026-03-03

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Yun Li, Simon Thompson, Yidu Zhang, Ehsan Javanmardi, Manabu Tsukada

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🚗 Le Problème : Le Chef Cuisinier qui ne fait qu'une seule chose

Imaginez un chef cuisinier (le planificateur de mouvement) dans une voiture autonome. Son travail est de décider où la voiture doit aller dans les prochaines secondes, en évitant les autres voitures et les piétons.

Récemment, les chercheurs ont créé un "super-chef" basé sur une technologie appelée Diffusion. C'est comme un artiste qui commence par un tableau plein de "bruit" (des taches aléatoires) et qui efface petit à petit ces taches pour révéler un dessin parfait de la trajectoire à suivre.

Mais il y a deux gros problèmes avec ce super-chef actuel :

Il est trop lent et rigide : Dans les tests actuels, on le fait travailler dans un laboratoire virtuel (un simulateur) où tout est parfait. Mais dans la vraie vie, la voiture doit communiquer avec ses capteurs, son GPS et ses freins en temps réel (via un système appelé ROS 2). Le "super-chef" actuel est si lourd qu'il met trop de temps à cuisiner son plat. De plus, une fois qu'il est installé dans la voiture, on ne peut pas changer ses paramètres (comme le nombre de fois où il doit "effacer le bruit") sans tout réinstaller et recompiler. C'est comme si vous deviez changer toute la cuisine de votre voiture juste pour ajouter un peu moins de sel.
C'est une "boîte noire" : Quand il travaille, on ne voit pas ce qui se passe à l'intérieur. On ne sait pas s'il est en train de réfléchir ou s'il est bloqué.

🛠️ La Solution : Une Cuisine Modulaire et Efficace

Les auteurs de ce papier ont eu une idée géniale : découper le monstre en trois petits robots spécialisés.

Au lieu d'avoir un seul gros bloc de code qui fait tout d'un coup, ils ont utilisé un outil magique (appelé GraphSurgeon) pour décomposer le planificateur en trois modules indépendants :

Le Chef de Cuisine (Context Encoder) : Il regarde la scène (la route, les autres voitures, les feux rouges) et prépare les ingrédients. Il ne le fait qu'une seule fois par cycle.
L'Artiste (DiT Core) : C'est lui qui fait le travail d'effacer le bruit pour trouver la trajectoire. Il peut être appelé plusieurs fois de suite.
Le Signalisateur (Turn Indicator) : Il dit simplement si la voiture doit tourner à gauche ou à droite.

La grande astuce ?
Dans l'ancien système, le "Chef de Cuisine" préparait les ingrédients à chaque fois que l'Artiste faisait un petit pas. C'était du gaspillage !
Dans le nouveau système, le Chef prépare les ingrédients une seule fois, les pose sur un plateau (mise en cache), et l'Artiste vient les prendre autant de fois qu'il veut sans attendre.

🏎️ Les Résultats : Plus rapide, plus intelligent, et adaptable

Grâce à cette nouvelle organisation, les chercheurs ont pu faire des choses incroyables :

Vitesse fulgurante : En évitant de refaire le travail inutilement, ils ont divisé le temps de calcul par 3,2. La voiture peut maintenant prendre ses décisions assez vite pour respecter les règles de sécurité (moins de 100 millisecondes).
Intelligence ajustable : Maintenant, on peut dire à la voiture : "Aujourd'hui, tu as peu de temps, fais juste 3 pas de nettoyage" ou "Aujourd'hui, tu as du temps, fais-en 20 pour être ultra-précis". Tout cela sans réinstaller le logiciel !
Meilleure précision : Ils ont testé deux méthodes de "nettoyage". L'une est rapide mais un peu brouillonne (1er ordre), l'autre est plus intelligente (2ème ordre). Ils ont découvert que la méthode intelligente, même avec très peu d'étapes, donne des résultats 41 % plus précis que l'ancienne méthode rapide.

🌍 Conclusion : Du laboratoire à la route réelle

Le plus important, c'est que ce système a été testé non pas dans un jeu vidéo isolé, mais dans un simulateur réaliste (AWSIM) qui imite parfaitement la façon dont les vraies voitures (comme celles d'Autoware) communiquent entre elles.

En résumé :
Cette recherche a transformé un planificateur de mouvement lent et rigide en un système modulaire, rapide et flexible. C'est comme passer d'une voiture de course qui ne peut rouler que sur une piste de test à une voiture de rallye capable de s'adapter à la boue, à la pluie et aux virages serrés, tout en restant rapide et sûre.

Et le meilleur ? Le code est open-source. Cela signifie que n'importe quel chercheur ou ingénieur peut maintenant utiliser ces outils pour tester de nouvelles idées directement sur des voitures réelles, sans avoir à tout reconstruire de zéro.

1. Problématique

Les planificateurs de mouvement basés sur les modèles de diffusion (Diffusion Models) ont atteint des performances de pointe sur des benchmarks comme nuPlan. Cependant, leur évaluation et leur déploiement dans des systèmes de conduite autonome (AD) réels en boucle fermée restent largement inexplorés. L'article identifie deux lacunes majeures dans les approches actuelles :

Évaluations non réalistes : La plupart des évaluations actuelles se font dans des simulateurs autonomes (comme CARLA) ou via des rejeux de scénarios en Python. Ces environnements ignorent les contraintes de latence critiques des piles de production, telles que la communication ROS 2, le prétraitement des capteurs et l'ordonnancement temps réel.
Déploiement monolithique rigide : Les pipelines de déploiement actuels exportent l'ensemble du processus de débruitage itératif (incluant la logique du solveur et le calendrier de bruit) dans un seul graphe ONNX monolithique. Cela fige tous les paramètres du solveur (nombre d'étapes, ordre, schedule de bruit) au moment de l'export. Il est impossible de modifier ces paramètres sans réexporter et recompiler le modèle, empêchant l'étude de questions fondamentales comme le nombre optimal d'étapes en temps réel ou l'efficacité des solveurs d'ordre supérieur.

2. Méthodologie

Les auteurs proposent une architecture modulaire open-source qui décompose le planificateur de diffusion monolithique pour l'intégrer dans la pile de production Autoware (basée sur ROS 2) et la valider via le simulateur AWSIM.

Décomposition du graphe ONNX : En utilisant l'outil ONNX GraphSurgeon, le graphe monolithique (composé de 18 398 nœuds pour le planificateur Diffusion Planner original) est décomposé en trois modules indépendants :
1. Context Encoder : Encode le contexte de la scène (véhicule, voisins, carte, feux, etc.). Il est exécuté une seule fois par cycle et son résultat est mis en cache.
2. DiT Core (Diffusion Transformer) : Le cœur du modèle de débruitage, exécuté $N$ fois (où $N$ est configurable à l'exécution).
3. Turn Indicator Classifier : Un classifieur linéaire minimal pour prédire les signaux de direction.
Implémentation du Solveur en C++ : La boucle de débruitage (DPM-Solver++) est réimplémentée nativement en C++. Cela permet de :
- Contrôler dynamiquement le nombre d'étapes ( $N$ ), l'ordre du solveur (1er ou 2nd ordre) et les paramètres du schedule de bruit VP (Variance Preserving) sans recompilation du modèle.
- Éviter la surcharge de l'interpréteur Python et le verrouillage global (GIL), garantissant une gestion déterministe de la mémoire pour le temps réel.
Intégration ROS 2 : Le système est intégré comme un nœud ROS 2 "plug-and-play" dans Autoware, permettant une observation étape par étape du processus de débruitage et une reconfiguration à chaud des paramètres.

3. Contributions Clés

Benchmark Modulaire Open-Source : Première plateforme permettant d'évaluer des solveurs de diffusion dans une pile AD de production (Autoware) en conditions de boucle fermée réelles, plutôt que dans des simulateurs isolés.
Solveur C++ Configurable : Une implémentation native permettant de varier les paramètres d'inférence (nombre d'étapes, ordre) sans toucher aux poids du réseau neuronal, comblant le fossé entre la recherche algorithmique et le déploiement.
Analyse Systématique : Une comparaison rigoureuse entre les solveurs DPM-Solver++ (1er et 2nd ordre) et DDIM sur différentes configurations de pas ( $N \in \{3, 5, 7, 10, 15, 20\}$ ).
Validation Numérique et Réelle : Démonstration de l'équivalence numérique avec le modèle monolithique (erreur maximale $< 10^{-5}$ ) et validation réussie de la conduite urbaine dans AWSIM.

4. Résultats Principaux

Les expériences menées sur un CPU (Intel i9) et validées dans AWSIM montrent des améliorations significatives :

Réduction de Latence par Mise en Cache : Dans l'architecture monolithique, l'encodeur de contexte est recalculé à chaque étape de débruitage, ce qui représente un gaspillage de 90,9 % du temps de calcul. L'architecture modulaire exécute l'encodeur une seule fois et met en cache le résultat.
- Gain : Réduction de la latence d'un facteur 3,2x (passant de 119 ms à 37 ms pour $N=3$ ) à précision égale.
Efficacité du Solveur d'Ordre Supérieur : L'utilisation d'un solveur DPM-Solver++ d'ordre 2 améliore considérablement la précision par rapport à l'ordre 1.
- Gain : Réduction de l'erreur de déplacement finale (FDE) de 41 % à $N=3$ (passant de 0,61 m à 0,36 m) par rapport au solveur d'ordre 1.
Planification "Anytime" : Le système permet d'ajuster dynamiquement le nombre d'étapes en fonction du temps restant dans le cycle ROS 2 (100 ms). Même avec un nombre d'étapes réduit ( $N=3$ ), le système reste dans les limites de temps requises tout en maintenant une qualité de trajectoire acceptable.
Observabilité : La décomposition permet d'analyser la convergence du processus de débruitage, révélant que la majeure partie de l'amélioration de la prédiction se produit entre les étapes 3 et 6 (phase de raffinement).

5. Signification et Impact

Cet article marque une étape importante pour le domaine de la conduite autonome basée sur l'IA générative :

Passage du "Benchmark" au "Déploiement" : Il démontre que les modèles de diffusion peuvent être déployés dans des contraintes temps réel strictes (100 ms) si l'architecture logicielle est adaptée (découplage du solveur et du modèle).
Flexibilité de Recherche : Il offre aux chercheurs un environnement où tester de nouvelles stratégies de scheduling, de solveurs ou de politiques adaptatives sans avoir à réentraîner ou réexporter des modèles lourds.
Reproductibilité : En rendant le code source complet disponible, l'équipe établit un standard pour l'évaluation reproductible des planificateurs de diffusion en boucle fermée, reliant directement les résultats de simulation aux véhicules réels.

En résumé, cette travail transforme les planificateurs de diffusion d'outils de recherche académique en composants logiciels modulaires, optimisables et prêts pour le déploiement industriel dans les véhicules autonomes.