🤖 AI

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

Deze paper introduceert een open-source, modulaire benchmark die een diffusie-gebaseerde bewegingsplanner integreert in de productie-AD-stack Autoware via ROS 2, waardoor runtime-configuratie en per-stap observatie mogelijk worden en prestaties in gesloten-lus simulaties aanzienlijk verbeteren ten opzichte van monolithische implementaties.

Oorspronkelijke auteurs: Yun Li, Simon Thompson, Yidu Zhang, Ehsan Javanmardi, Manabu Tsukada

Gepubliceerd 2026-03-03

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Yun Li, Simon Thompson, Yidu Zhang, Ehsan Javanmardi, Manabu Tsukada

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zelfrijdende auto bouwt. De "hersenen" van deze auto moeten constant beslissingen nemen: waar moet ik naartoe, hoe snel, en hoe vermijd ik andere auto's?

Recente technologie, genaamd Diffusie-planners, is hierin heel goed geworden. Het werkt als een kunstenaar die een schilderij maakt: hij begint met een wazig, rommelig beeld (ruis) en werkt stap voor stap naar een scherp, perfect plan toe. Maar tot nu toe was er een groot probleem: deze kunstenaars werden getest in een veilige, gecontroleerde studio (simulaties), maar niemand wist of ze ook goed werkten in de drukke, chaotische realiteit van een echte auto.

Deze paper introduceert een open-source, modulaire testomgeving die dit probleem oplost. Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Zwarte Doos" en de "Trage Kunstenaar"

In de oude manier van werken (de "monolithische" aanpak) was het hele denkproces van de auto in één grote, ondoorzichtige doos gegoten.

De Zwarte Doos: Je kon niet zien hoe de auto dacht. Als je het aantal stappen wilde veranderen om het sneller te maken, moest je de hele doos opnieuw bouwen en opnieuw programmeren. Het was alsof je een auto zou moeten smeden uit één blok staal; als je een wiel wilt veranderen, moet je de hele auto opnieuw gieten.
De Trage Kunstenaar: De auto moest bij elke stap van het denkproces het hele schilderij opnieuw bekijken. Het was alsof een schilder bij elke penseelstreek het hele canvas opnieuw zou moeten scannen om te zien wat er al getekend was. Dit kostte te veel tijd (meer dan 300 milliseconden), terwijl een echte auto binnen 100 milliseconden moet beslissen.

2. De Oplossing: De "Lego-blokken" aanpak

De auteurs hebben deze grote doos opengebroken en in drie losse, slimme Lego-blokken verdeeld:

De Context-Scanner: Kijkt naar de omgeving (andere auto's, verkeerslichten, de route).
De Denker (DiT Core): Doet het zware werk van het "ontruisen" van het plan.
De Signaalgever: Besluit of je links of rechts moet slaan.

De Grootste Innovatie: Het "Bewaren van Notities"
In de oude versie moest de "Context-Scanner" bij elke stap van het denkproces opnieuw aan het werk. Dat was zonde van de tijd.
In deze nieuwe modulaire versie doet de scanner zijn werk één keer per beslissing, schrijft het resultaat op een post-it (cache), en geeft die door aan de denker. De denker gebruikt die post-it voor al zijn stappen.

Vergelijking: Het is het verschil tussen een chef-kok die bij elke hap die hij neemt, opnieuw de hele supermarkt moet bezoeken om de ingrediënten te halen, versus een kok die alle ingrediënten al op het aanrecht heeft liggen. Het resultaat is 3,2 keer sneller.

3. De Test: De "Echte Straat" vs. de "Videospelletjes"

Veel andere tests doen alsof ze in een videospelletje zitten (zoals CARLA), waar de communicatie tussen de onderdelen van de auto perfect en direct verloopt.
De auteurs hebben hun systeem echter geïntegreerd in Autoware, de software die door echte bedrijven over de hele wereld wordt gebruikt. Ze hebben het getest in een gesimuleerde stad (AWSIM) die precies doet alsof het een echte auto is, inclusief de vertragingen en communicatieproblemen die in de echte wereld voorkomen.

4. De Resultaten: Sneller en Slimmer

Door deze nieuwe manier van werken konden ze twee dingen doen die voorheen onmogelijk waren:

Aanpasbaarheid: Ze konden tijdens het rijden beslissen: "We hebben haast, laten we minder denkstappen doen" of "We hebben tijd, laten we extra nauwkeurig zijn". Ze hoefden de software niet opnieuw te installeren.
Betere Kwaliteit: Ze ontdekten dat een specifieke rekenmethode (de "tweede-orde" methode) veel slimmer was. Met slechts 3 stappen kon deze methode net zo goed presteren als de oude methode met 5 stappen. Dit betekent dat de auto sneller kan reageren zonder onnauwkeurig te worden.

Conclusie

Kortom, deze paper pakt de "geheime recepten" van de zelfrijdende auto's en maakt ze openbaar, moduler en snel. Ze hebben de "zwarte doos" opengebroken, de "trage kunstenaar" een notitieblok gegeven, en bewezen dat deze systemen niet alleen in een videospelletje werken, maar ook klaar zijn voor de drukke, echte straten.

Het is alsof ze van een statisch, onbeweeglijk standbeeld een flexibele, snelle robot hebben gemaakt die echt kan meedenken in het verkeer. En het beste van alles? De code is openbaar, zodat iedereen mee kan bouwen aan de toekomst van veilig rijden.

Probleemstelling

Diffusiemodellen hebben state-of-the-art resultaten behaald op benchmarks zoals nuPlan voor bewegingsplanning in autonoom rijden. Echter, er zijn twee kritieke hiaten tussen deze benchmarks en de daadwerkelijke implementatie in productiesystemen:

Gebrek aan gesloten-lus evaluatie in productie-omgevingen: Bestaande evaluaties vinden vaak plaats in pseudo-gesloten-lus omgevingen (zoals Python-simulaties of nuPlan's reactieve agenten). Deze negeren realistische beperkingen zoals ROS 2 communicatielatentie, sensorverwerkingstijd en real-time scheduling op gedeelde voertuigcomputers. Hierdoor blijft de kloof tussen "benchmarkprestaties" en "voertuig-deployeerbare prestaties" ongemeten. Monolithische diffusieplanners kunnen bijvoorbeeld meer dan 300 ms per cyclus nodig hebben, wat de gebruikelijke budget van 100 ms voor planningknooppunten (zoals in Autoware) overschrijdt.
Starre implementatie (Monolithische ONNX): Huidige deployment-pijplijnen exporteren het volledige iteratieve denoising-proces (inclusief noise-schedule, solver-logica en DiT-blokken) naar één monolithische ONNX-grafiek. Dit "bevriest" alle solver-parameters (zoals het aantal stappen $N$ , de solver-orde en het noise-schema) op het moment van export. Onderzoekers kunnen deze parameters niet dynamisch aanpassen zonder het model opnieuw te compileren, wat onderzoek naar fundamentele vragen (bijv. "Hoeveel stappen zijn echt nodig onder realtime constraints?") onmogelijk maakt.

Methodologie

De auteurs presenteren een open-source, modulaire benchmark die deze problemen oplost door de iteratieve denoising-lus uit de computationele grafiek te halen en te vervangen door een extern, runtime-configureerbaar C++-systeem.

Modulaire Decompositie: Met behulp van ONNX GraphSurgeon wordt de monolithische grafiek (oorspronkelijk 18.398 knopen) opgesplitst in drie onafhankelijk uitvoerbare modules:
1. Context Encoder: Verwerkt de scène-context (ego-positie, omringende voertuigen, kaart, route, etc.) en wordt slechts één keer per planningcyclus uitgevoerd. De output (context embedding) wordt in het geheugen bewaard (cached).
2. DiT Core (Diffusion Transformer): De kern van het model die $N$ keer wordt aangeroepen. Omdat de encoder is gecached, hoeft deze niet bij elke stap opnieuw te worden uitgevoerd.
3. Turn Indicator Classifier: Een klein moduletje voor het voorspellen van richtingsaanwijzers.
Native C++ Solver: De DPM-Solver++ denoising-lus is herschreven in native C++. Dit maakt het mogelijk om het aantal stappen ( $N$ ), de solver-orde (eerste of tweede orde) en het noise-schema dynamisch aan te passen via ROS 2 parameters zonder het model opnieuw te compileren.
Integratie: Het systeem is geïntegreerd als een ROS 2-knooppunt binnen de Autoware-stack (de open-source standaard voor autonoom rijden) en gevalideerd in AWSIM, een gesloten-lus simulator.

Belangrijkste Bijdragen

Open-source Modulaire Benchmark: Een framework dat een monolithische diffusieplanner decomposeert in uitvoerbare modules, waardoor "plug-and-play" evaluatie van solvers mogelijk is binnen een echte productie-AD-stack (Autoware + AWSIM).
Runtime-configureerbare Inference: Een native C++ implementatie van DPM-Solver++ die het mogelijk maakt om solver-gedrag (stap-aantal, orde, noise-schema) te bestuderen en aan te passen zonder model-recompilatie.
Systematische Vergelijking: Een uitgebreide vergelijking van DPM-Solver++ (1e en 2e orde) en DDIM over verschillende stap-aantallen ( $N \in \{3, 5, 7, 10, 15, 20\}$ ) in een gesloten-lus omgeving.
Validatie en Openbaarheid: Numerieke equivalentie met het monolithische model is bewezen (maximale fout $< 10^{-5}$ ) en het volledige codebase wordt open-source beschikbaar gesteld.

Resultaten

De experimenten tonen significante verbeteringen in zowel snelheid als nauwkeurigheid:

Latentie-reductie door Caching: Door de context encoder slechts één keer per cyclus uit te voeren in plaats van bij elke denoising-stap (zoals in de monolithische versie), wordt de rekenkosten drastisch verlaagd. Dit resulteert in een 3,2x lagere latentie (bijvoorbeeld van 119 ms naar 37 ms bij $N=3$ ) terwijl de voorspellingsnauwkeurigheid gelijk blijft.
Verbeterde Nauwkeurigheid met 2e Orde Solvers: Het gebruik van een tweede-orde DPM-Solver++ in plaats van een eerste-orde (of DDIM) reduceert de Final Displacement Error (FDE) met 41% bij een laag stap-aantal ( $N=3$ ).
Efficiëntie: De modulaire architectie past binnen het strikte 100 ms planning-budget van Autoware, zelfs bij lagere stap-aantallen. De monolithische architectie overschrijdt dit budget altijd.
Observatie: Het systeem biedt inzicht in het denoising-proces per stap, wat laat zien dat de meeste verbetering plaatsvindt in de "verfijningsfase" (stappen 3-6), wat de haalbaarheid van "anytime planning" (dynamisch aanpassen van stappen op basis van beschikbare rekentijd) ondersteunt.

Betekenis en Impact

Dit werk is van groot belang voor de overgang van academische diffusiemodellen naar praktische, veilige autonome voertuigen.

Brug naar Realiteit: Het vult de kloof tussen simulatie-benchmarks en real-world deployment door evaluatie binnen een productiestack met echte timing- en communicatiebeperkingen.
Flexibiliteit: Het doorbreekt de "black box" van monolithische ONNX-deployments, waardoor onderzoekers en ingenieurs solvers en hyperparameters kunnen optimaliseren voor specifieke hardware en scenario's zonder de zware last van modelhertraining.
Reproduceerbaarheid: Door het open-source karakter en de integratie met Autoware en AWSIM, biedt het een reproduceerbaar pad voor de gemeenschap om diffusiegebaseerde planning te testen en te verbeteren onder realistische gesloten-lus omstandigheden.

Kortom, de paper demonstreert dat het loskoppelen van de iteratieve solver van het neurale netwerk niet alleen de prestaties (snelheid) verbetert, maar ook de wetenschappelijke controle en flexibiliteit van het systeem aanzienlijk vergroot.