🤖 AI

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

Die Autoren stellen einen Open-Source-Benchmark vor, der Diffusionsbasierte Bewegungsplaner durch eine modulare, in ROS 2 und Autoware integrierte C++-Implementierung für den Closed-Loop-Einsatz in der realen autonomen Fahrzeugentwicklung zugänglich macht und dabei Latenzreduktion sowie verbesserte Endpunktfehler durch optimierte Solver-Strategien nachweist.

Ursprüngliche Autoren: Yun Li, Simon Thompson, Yidu Zhang, Ehsan Javanmardi, Manabu Tsukada

Veröffentlicht 2026-03-03

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yun Li, Simon Thompson, Yidu Zhang, Ehsan Javanmardi, Manabu Tsukada

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie planen eine Autofahrt durch eine belebte Stadt. Ein moderner KI-Planer (ein „Diffusions-Planer") ist wie ein hochintelligenter Navigator, der nicht nur die Straße kennt, sondern auch vorhersagt, wie sich andere Verkehrsteilnehmer in den nächsten Sekunden bewegen werden. Er macht das, indem er schrittweise aus einem chaotischen „Rauschen" (wie einem statischen Bild) eine klare, sichere Fahrtroute herausfiltert.

Das Problem ist jedoch: Bisher wurde dieser Navigator nur in einer perfekten, simulierten Welt getestet. Wenn man ihn in ein echtes Auto einbaute, würde er oft zu langsam sein oder stecken bleiben, weil die echte Welt viele kleine Verzögerungen hat (wie das Warten auf Daten von Sensoren oder das Übertragen von Nachrichten im Auto-Netzwerk).

Hier ist die Lösung, die die Autoren in diesem Papier präsentieren:

1. Das Problem: Der „Monolith" (Der unflexible Riese)

Stellen Sie sich den bisherigen Planer wie einen riesigen, in Stein gemeißelten Block vor. Um eine Fahrtroute zu berechnen, muss dieser Block den gesamten Prozess von Anfang bis Ende in einem einzigen, unflexiblen Durchgang abarbeiten.

Das Problem: Wenn das Auto neue Daten bekommt (z. B. ein Kind läuft auf die Straße), muss der gesamte riesige Steinblock neu berechnet werden.
Die Folge: Es dauert zu lange (über 300 Millisekunden). Ein modernes Auto braucht aber Entscheidungen in unter 100 Millisekunden. Der Navigator ist also zu langsam für den echten Straßenverkehr.
Zweitens: Man kann die Einstellungen nicht ändern, ohne den ganzen Steinblock neu zu schleifen. Wenn man wissen will, ob weniger Rechenschritte reichen, muss man den ganzen Prozess neu bauen.

2. Die Lösung: Das modulare Baukastensystem

Die Autoren haben diesen riesigen Steinblock zerlegt und in drei separate, gut organisierte Module verwandelt. Stellen Sie sich das wie einen gut organisierten Küchenbetrieb vor, anstatt eines einzelnen Kochs, der alles selbst macht:

Modul 1: Der Szenen-Beobachter (Context Encoder).
- Was er tut: Er schaut sich die Umgebung an (andere Autos, Ampeln, Karte) und erstellt eine Art „Gedächtnis" oder „Kontext".
- Der Trick: Er macht das nur einmal pro Fahrzyklus. Das Ergebnis wird zwischengespeichert (wie ein Notizblock auf dem Tresen), damit es nicht immer wieder neu geschrieben werden muss.
Modul 2: Der Kreative Zeichner (DiT Core).
- Was er tut: Er nimmt das „Gedächtnis" und zeichnet schrittweise die Fahrtroute. Er wiederholt diesen Schritt mehrmals, um die Route immer genauer zu machen.
- Der Vorteil: Da der „Beobachter" (Modul 1) seine Arbeit schon erledigt hat, muss der Zeichner nur noch die eigentliche Zeichnung machen. Das ist viel schneller.
Modul 3: Der Dirigent (C++ Solver).
- Was er tut: Er ist der Chef im Hintergrund. Er sagt dem Zeichner: „Mach noch einen Schritt", „Stoppe jetzt" oder „Mach es genauer".
- Der Vorteil: Man kann ihm sofort sagen: „Wir haben nur wenig Zeit, mach nur 3 Schritte!" oder „Wir haben Zeit, mach 20 Schritte!", ohne den ganzen Computer neu starten zu müssen.

3. Die Ergebnisse: Warum ist das so toll?

Geschwindigkeit (Der Turbo-Effekt):
Durch das Zwischenspeichern des „Beobachters" (Modul 1) wurde die Rechenzeit um das 3,2-Fache reduziert. Der Planer ist jetzt schnell genug, um in echten Autos mitzuhalten (unter 100 ms).
Qualität (Der kluge Dirigent):
Die Autoren haben getestet, ob es besser ist, viele kleine Schritte oder wenige, aber sehr kluge Schritte zu machen. Sie stellten fest: Wenn man den „Dirigenten" anweist, einen intelligenteren Algorithmus (zweiter Ordnung) zu nutzen, ist die Route bei nur 3 Schritten 41 % genauer als bei der alten Methode mit 3 Schritten.
Transparenz (Kein Black Box mehr):
Früher war der Prozess eine „Black Box" – man wusste nicht, was im Inneren passiert. Jetzt kann man jeden einzelnen Schritt des Zeichnens beobachten. Man sieht genau, wie die Route von unscharf zu scharf wird.

Zusammenfassung in einer Metapher

Stellen Sie sich vor, Sie müssen ein komplexes Bild malen.

Die alte Methode: Ein einzelner Künstler muss jedes Mal, wenn er einen Pinselstrich setzt, die ganze Leinwand neu vorbereiten, die Farben mischen und dann einen Strich setzen. Das dauert ewig.
Die neue Methode: Ein Assistent bereitet die Leinwand und die Farben einmal vor und stellt sie bereit. Ein Maler nimmt sich diese Vorbereitung und malt schnell die Striche. Ein Chef gibt an, wie viele Striche noch nötig sind. Das Ergebnis ist schneller, genauer und man kann den Prozess jederzeit anpassen.

Fazit: Die Autoren haben einen Weg gefunden, komplexe KI-Planer so zu bauen, dass sie nicht nur auf dem Papier funktionieren, sondern auch in der realen Welt in echten Autos schnell und sicher arbeiten. Der gesamte Code wird als Open-Source veröffentlicht, damit andere Forscher und Entwickler dasselbe tun können.

1. Problemstellung

Diffusionsbasierte Bewegungsplaner (Motion Planners) haben auf Benchmarks wie nuPlan hervorragende Ergebnisse erzielt. Dennoch bleibt ihre Evaluierung in geschlossenen Regelkreisen (Closed-Loop) innerhalb von Produktions-Systemen für autonomes Fahren weitgehend unerforscht. Die aktuellen Forschungsansätze leiden unter zwei Hauptproblemen:

Fehlende Realitätsnähe in der Evaluierung: Die meisten bestehenden Bewertungen laufen in pseudo-geschlossenen Umgebungen (z. B. Python-Simulatoren oder Replay-Szenarien), die Latenzprobleme der Produktions-Software-Stacks (wie ROS 2 Kommunikations-Overhead, Echtzeit-Scheduling und Sensor-Verarbeitung) ignorieren. In der Realität benötigen monolithische Diffusionsplaner oft über 300 ms pro Zyklus, was weit über dem typischen Budget von 100 ms für Planungsknoten in Frameworks wie Autoware liegt.
Starre Monolithische Bereitstellung (Deployment): Der gesamte Denoising-Prozess (inklusive Rausch-Schedule, Solver-Logik und iterative DiT-Blöcke) wird als ein einziger, riesiger ONNX-Graph exportiert (z. B. 18.398 Knoten). Dies führt dazu, dass alle Solver-Parameter (Schrittanzahl $N$ , Solver-Ordnung, Rausch-Schedule) zum Zeitpunkt des Exports „eingefroren" sind. Eine Anpassung erfordert ein komplettes Neukompilieren des Modells, was eine flexible Forschung und Echtzeit-Anpassung unmöglich macht. Zudem wird der Kontext-Encoder bei jedem Denoising-Schritt redundant neu berechnet, was ineffizient ist.

2. Methodik

Die Autoren schlagen einen open-source modularen Benchmark vor, der diese Lücken schließt, indem sie die Architektur des Diffusionsplaners zerlegen und in das ROS 2-basierte Autoware-Framework integrieren.

Graph-Zerlegung (Decomposition):
Mithilfe von ONNX GraphSurgeon wird der monolithische ONNX-Graph in drei unabhängig ausführbare Module zerlegt:
1. Context Encoder: Verarbeitet die Szenenkontexte (Ego-Pose, Objekte, Karten, etc.) einmal pro Planungszyklus.
2. DiT Core (Diffusion Transformer): Das eigentliche Denoising-Netzwerk, das $N$ -mal aufgerufen wird.
3. Turn Indicator Classifier: Ein kleiner linearer Klassifikator für Blinker-Vorhersagen.
Externer C++ Solver:
Anstatt den Denoising-Loop im ONNX-Graphen zu verankern, wird er in nativer C++ neu implementiert (basierend auf DPM-Solver++). Dieser C++-Solver orchestriert die Module.
- Laufzeit-Konfigurierbarkeit: Parameter wie die Anzahl der Schritte ( $N \in [1, 50]$ ), die Solver-Ordnung (1. oder 2. Ordnung) und das Rausch-Schedule können zur Laufzeit geändert werden, ohne das Modell neu zu kompilieren.
- Encoder Caching: Da der Kontext-Encoder nur von der Szene und nicht vom Denoising-Zustand abhängt, wird sein Output einmal berechnet und für alle $N$ Schritte zwischengespeichert (cached).
Integration:
Das System wird als ROS 2-Knoten in Autoware integriert und in AWSIM (einem Open-Source-Simulator für geschlossene Regelkreise) validiert. Dies ermöglicht eine echte Closed-Loop-Evaluierung unter realistischen Bedingungen.

3. Wichtige Beiträge

Modularer Benchmark: Erstmals wird ein monolithischer Diffusionsplaner in ausführbare Module zerlegt, um Plug-and-Play-Solver-Evaluierungen in einer Produktions-AD-Stack (Autoware + AWSIM) unter echten Closed-Loop-Bedingungen zu ermöglichen.
Native C++ Implementierung: Eine Implementierung des DPM-Solver++ in C++ mit lauffähigen Parametern, die eine Untersuchung des Solver-Verhaltens ohne Modell-Neukompilierung erlaubt – eine Fähigkeit, die bei bisherigen Bereitstellungen fehlte.
Systematische Vergleichsstudie: Umfassender Vergleich verschiedener Solver (DPM-Solver++ 1. und 2. Ordnung, DDIM) über verschiedene Schrittanzahlen ( $N \in \{3, 5, 7, 10, 15, 20\}$ ) in einer realistischen Umgebung.
Validierung: Nachweis der numerischen Äquivalenz zum monolithischen Modell (max. Fehler $< 10^{-5}$ ), Demonstration der Latenzreduktion durch Caching und erfolgreicher Test in urbanen Szenarien. Der vollständige Code wird als Open-Source veröffentlicht.

4. Ergebnisse

Die Experimente zeigen signifikante Verbesserungen sowohl in der Effizienz als auch in der Genauigkeit:

Latenzreduktion durch Caching:
Durch das einmalige Ausführen und Cachen des Encoders (statt $N+1$ $N + 1$ -mal) wird die Rechenzeit drastisch gesenkt.
- Der Encoder macht 90,9 % der redundanten Berechnungen im monolithischen Ansatz aus.
- Bei $N=3$ reduziert das Caching die Latenz von 119 ms (monolithisch) auf 37 ms (modular), was einer 3,2-fachen Beschleunigung bei gleicher Genauigkeit entspricht.
- Alle modularen Konfigurationen liegen unter dem kritischen 100 ms-Zeitbudget für Planungsknoten, während monolithische Ansätze dies verfehlen.
Genauigkeitsgewinn durch 2. Ordnung:
Der Vergleich der Solver zeigt, dass die Verwendung eines 2. Ordnungs-Solvers (DPM-Solver++ 2nd Order) die Genauigkeit massiv verbessert.
- Bei nur 3 Schritten ( $N=3$ ) reduziert der 2. Ordnungs-Solver den Final Displacement Error (FDE) um 41 % im Vergleich zum 1. Ordnungs-Solver (von 0,61 m auf 0,36 m).
- Ein 2. Ordnungs-Solver mit $N=3$ erreicht die gleiche Genauigkeit wie ein 1. Ordnungs-Solver mit $N=5$ .
Timestep-Scheduling:
Die richtige Anpassung des Zeitschritt-Schedules für weniger Schritte ist entscheidend. Ein dediziertes $N=3$ -Schedule liefert einen FDE von 0,36 m, während das einfache Abschneiden eines 10-Schritt-Schedules zu einem FDE von 2,53 m führt (7-fache Verbesserung).
Closed-Loop Validierung:
Das System wurde in über 600 Planungszyklen in einer urbanen Umgebung (Nishishinjuku-Karte in AWSIM) erfolgreich getestet, ohne Kollisionen, bei einer konstanten Ausgaberate von ca. 10 Hz.

5. Bedeutung und Fazit

Dieses Paper adressiert die Kluft zwischen akademischen Benchmarks und der tatsächlichen Einsatzfähigkeit von Diffusionsplanern in autonomen Fahrzeugen.

Paradigmenwechsel: Es beweist, dass Diffusionsmodelle nicht als starre Black-Box-ONNX-Graphen bereitgestellt werden müssen, sondern als flexible, modulare Systeme, die Echtzeit-Anforderungen erfüllen können.
Forschungsplattform: Der bereitgestellte Open-Source-Benchmark ermöglicht es der Forschungsgemeinschaft, neue Solver, Scheduling-Strategien und adaptive Schrittanzahlen (Anytime Planning) direkt unter realistischen Closed-Loop-Bedingungen zu testen, ohne auf proprietäre oder nicht reproduzierbare Simulatoren angewiesen zu sein.
Praktische Relevanz: Die Kombination aus Encoder-Caching und effizienteren Solvern macht Diffusionsplaner erstmals konkurrenzfähig mit traditionellen Methoden in Bezug auf Latenz, während sie gleichzeitig die Vorteile der probabilistischen Modellierung beibehalten.

Zusammenfassend bietet die Arbeit einen direkten Weg von Simulation zu echter Fahrzeugbereitstellung und legt den Grundstein für die nächste Generation adaptiver, diffusionbasierter Bewegungsplaner.