🤖 AI

Driving on Registers

Das Papier stellt DrivoR vor, eine reine Transformer-Architektur für das End-to-End-autonome Fahren, die kamera-bewusste Register-Token nutzt, um Multi-Kamera-Merkmale in eine kompakte Repräsentation zu komprimieren, was eine effiziente Trajektorien-Generierung und -Bewertung mit interpretierbaren Teilbewertungen ermöglicht und dabei State-of-the-Art-Baselines über mehrere Benchmarks hinweg übertrifft oder mit ihnen gleichzieht.

Ursprüngliche Autoren: Ellington Kirby, Alexandre Boulch, Yihong Xu, Yuan Yin, Gilles Puy, Éloi Zablocki, Andrei Bursuc, Spyros Gidaris, Renaud Marlet, Florent Bartoccioni, Anh-Quan Cao, Nermin Samet, Tuan-Hung VU, Matthieu

Veröffentlicht 2026-02-04

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Ellington Kirby, Alexandre Boulch, Yihong Xu, Yuan Yin, Gilles Puy, Éloi Zablocki, Andrei Bursuc, Spyros Gidaris, Renaud Marlet, Florent Bartoccioni, Anh-Quan Cao, Nermin Samet, Tuan-Hung VU, Matthieu Cord

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 bringen einem Roboter das Autofahren bei. Traditionell würde man dem Roboter ein massives Handbuch mit tausenden Seiten geben, in dem genau steht, was er in jeder erdenklichen Situation zu tun hat. Dieses Paper stellt eine neue Art vor, den Roboter zu lehren, die DrivoR genannt wird und viel intelligenter, schneller und einfacher ist.

Hier ist die Aufschlüsselung der Funktionsweise, unter Verwendung von Alltagsanalogien:

1. Das Problem: Zu viele Informationen

Stellen Sie sich vor, Sie fahren und schauen durch sechs verschiedene Fenster (Kameras). Ein Standard-Computervisionssystem versucht, jedes einzelne Pixel in jedem Fenster zu erfassen, was einen Berg an Daten erzeugt. Es ist, als würde man versuchen, eine Bibliothek voller Bücher zu lesen, während man fährt; der Computer wird überfordert, weil er versucht, all diese Informationen zu verarbeiten, bevor er entscheiden kann, ob er abbiegt oder anhält. Dies macht das System langsam und teuer im Betrieb.

2. Die Lösung: Die „Register“-Notizenschreiber

Die Autoren von DrivoR haben erkannt, dass der Roboter nicht die ganze Bibliothek lesen muss. Er braucht nur ein paar wichtige Notizen.

Sie haben etwas namens „Register Tokens“ eingeführt. Betrachten Sie diese als ein kleines Team spezialisierter Notizenschreiber, die auf dem Beifersitz für jede Kamera sitzen.

Anstatt dass der Computer das gesamte Bild verarbeiten muss, scannen diese Notizenschreiber die Sicht und schreiben nur die wichtigsten Details auf (wie „Auto voraus“, „Rote Ampel“ oder „leere Straße“).
Sie komprimieren ein riesiges, chaotisches Bild in eine winzige, ordentliche Zusammenfassung.
Das Ergebnis: Der Computer muss nun nur noch ein paar Sätze lesen anstatt eines ganzen Buches. Dies macht das System unglaublich schnell und effizient, ohne die Fähigkeit zu verlieren, Gefahren zu erkennen.

3. Der zweistufige Entscheidungsprozess

Sob nachdem die Notizenschreiber die Szene zusammengefasst haben, muss der Roboter entscheiden, was zu tun ist. DrivoR teilt diese Aufgabe in zwei separate Teams auf, wie einen Coach und einen Schiedsrichter.

Der Coach (Trajektorien-Generator): Dieses Team betrachtet die Zusammenfassung und sagt: „Hier sind 100 verschiedene Wege, wie wir in den nächsten Sekunden fahren könnten.“ Sie generieren viele mögliche Pfade (Trajektorien) sehr schnell.
Der Schiedsrichter (Bewertungssystem): Dieses Team betrachtet diese 100 Pfade und bewertet sie. Aber das ist der Clou: Der Schiedsrichter gibt nicht nur eine einzige Note (wie „Gut“ oder „Schlecht“), sondern erstellt ein Zeugnis mit spezifischen Bewertungen:
- Sicherheit: „Wie wahrscheinlich ist es, dass wir einen Unfall bauen?“
- Komfort: „Werden die Passagiere Reiseübelkeit verspüren?“
- Effizienz: „Wie schnell kommen wir ans Ziel?“

4. Fahren mit einer „Persönlichkeit“

Da der Schiedsrichter separate Noten für Sicherheit, Komfort und Geschwindigkeit vergibt, können Sie die Persönlichkeit des Roboters ändern, ohne ihn neu trainieren zu müssen.

Der „Sicherheits“-Modus: Sie sagen dem Computer: „Mir ist Sicherheit und Komfort zu 100 % wichtig.“ Der Roboter wählt den Pfad mit der höchsten Sicherheitsbewertung, auch wenn er dadurch etwas langsamer ist.
Der „Sportliche“ Modus: Sie sagen dem Computer: „Ich will schnell ans Ziel kommen.“ Der Roboter wählt den Pfad, der den Fortschritt maximiert, selbst wenn es etwas holprig ist.

Es ist, als hätte man ein Auto, das durch das Drehen eines Reglers sofort von einem „Oma-Fahrstil“ zu einem „Rennfahrer-Stil“ wechseln kann.

5. Die Ergebnisse

Das Paper hat dieses System in einigen sehr anspruchsvollen Fahrsimulationen getestet (wie ein Videospiel, das schwerer ist als das echte Leben).

Leistung: DrivoR war genauso gut oder sogar besser als die komplexesten Systeme, die derzeit verfügbar sind.
Geschwindigkeit: Da das System diese „Notizenschreiber“ nutzt, um die Daten zu komprimieren, läuft es 3-mal schneller als ähnliche Systeme.
Einfachheit: Es benötigt kein massives Wörterbuch mit vorgeschriebenen Fahrbewegungen oder komplexe 3D-Karten. Es lernt direkt aus den Kamerabildern und den „Notizenschreibern“.

Zusammenfassung

DrivoR ist eine neue Art, selbstfahrende Autos zu bauen, die wie das Einstellen eines Teams aus intelligenten Notizenschreibern funktioniert, die die Straße zusammenfassen, einem Coach, der viele Fahroptionen vorschlägt, und einem Schiedsrichter, der diese Optionen basierend darauf bewertet, was Ihnen wichtig ist (Sicherheit vs. Geschwindigkeit). Es beweist, dass man keinen Supercomputer braucht, um gut zu fahren; man braucht nur eine intelligente, effiziente Art, Informationen zu verarbeiten.

Technisches Resümee: DrivoR – Driving on Registers

Problemstellung

End-to-End (E2E) autonomes Fahren zielt darauf ab, rohe Sensordaten direkt auf Fahrentscheidungen abzubilden, um die Labeling-Kosten zu senken und zwischengeschaltete modulare Annotationen zu vermeiden. Trajektorien-Proposal-Methoden haben eine starke Leistung gezeigt, indem sie mehrere Kandidatypfade generieren und den besten auswählen, stehen jedoch vor einem erheblichen Rechenengpass. Aktuelle State-of-the-Art-Ansätze verlassen sich oft auf schwere Backbones (z. B. große Vision Transformer oder CNNs), die pro Frame Tausende von Tokens ausgeben. Die Verarbeitung dieser Tokens für hunderte von Trajektorien-Kandidaten erzeugt eine Rechenlast, die mit der Auflösung und der Anzahl der Sensoren schlecht skaliert. Darüber hinaus verlassen sich bestehende Lösungen oft auf ein uniformes Feature-Pooling, das alle Kamera-Inputs als gleichermaßen informativ behandelt und starre Auflösungsanforderungen erzwingt, was potenziell kritischen Planungskontext verwirft.

Methodik: DrivoR-Architektur

Die Autoren schlagen DrivoR vor, eine einfache, effiziente, reine Transformer-Architektur, die für das E2E-Planning entwickelt wurde. Das System vermeidet komplexe Zwischenrepräsentationen (wie Bird's Eye View-Projektionen) und große, vorab berechnete Trajektorien-Dictionaries. Stattdessen nutzt es eine dreistufige Transformer-Pipeline:

1. Wahrnehmungs-Encoder mit kamera-bewussten Registern

Die Kerninnovation liegt im Wahrnehmungs-Encoder, der anstelle von uniformem Pooling kamera-bewusste Register-Tokens verwendet.

Mechanismus: Für jede der $N$ Eingangskameras führt das Modell einen festen Satz von $R$ lernbaren Register-Tokens ein. Diese werden mit Standard-Patch-Tokens konkateniert und in einen vortrainierten Vision Transformer (speziell DINOv2 ViT-S) Backbone eingespeist.
Kompression: Der ViT komprimiert die hochdimensionalen visuellen Features in diese $R$ Register pro Kamera. Das Ergebnis ist ein kompakter Satz von $N \times R$ „Szene-Tokens“.
Vorteil: Dieser Ansatz reduziert die Sequenzlänge für die nachgelagerte Verarbeitung drastisch (von Tausenden von Tokens auf einige Dutzend), während der planungsrelevante Kontext erhalten bleibt. Die Register sind kameraspezifisch, was es dem Modell ermöglicht, zwischen Front-, Seiten- und Rückansichten zu differenzieren.
Training: Der Backbone wird mittels Low-Rank Adaptation (LoRA) feinjustiert, um die Vision-zu-Register-Kompression effizient zu lernen und die Anzahl der Parameter niedrig zu halten.

2. Trajektorien-Decoder

Der Trajektorien-Decoder generiert Kandidatenpfade unter Verwendung einer Standard-Transformer-Decoder-Architektur.

Input: Er nimmt einen Satz lernbarer Trajektorien-Queries entgegen, die mit Ego-Zustandsinformationen (Pose, Geschwindigkeit, Beschleunigung, Kommandos) angereichert sind.
Attention: Die Queries wenden Cross-Attention auf die komprimierten „Szene-Tokens“ an.
Output: Der Decoder produziert einen Satz von Kandidaten-Trajektorien, die jeweils als eine Sequenz von $(x, y, \theta)$ -Posen im lokalen Koordinatensystem des Ego-Agenten dargestellt sind.
Loss: Das Training nutzt einen Winner-Takes-All (WTA) oder Minimum-over- $N$ (MoN) Loss, der nur die zur Ground Truth am nächsten liegende vorhergesagte Trajektorie überwacht, um die Diversität im Proposal-Set zu fördern.

3. Scoring-Decoder (Entkoppelt)

Ein separater Scoring-Modul bewertet die Qualität der generierten Trajektorien.

Entkopplung: Entscheidend ist, dass die dekodierten Trajektorien in einen neuen Feature-Raum re-embedded und vom Gradienten-Graphen getrennt werden, bevor sie in den Scoring-Decoder gelangen. Dies verhindert, dass der Trajektorien-Generierungsprozess während des Trainings durch die unmittelbare Qualität des Scorers beeinflusst wird, wodurch eine Trennung zwischen Generierung und Evaluierung erzwungen wird.
Sub-Scores: Anstatt eines einzelnen Skalars sagt das Modell sechs interpretierbare Sub-Scores voraus, die den Komponenten des Predictive Driver Model Score (PDMS) entsprechen (z. B. Sicherheit, Komfort, Effizienz, Fortschritt).
Verhaltenssteuerung: Bei der Inferenz können diese Sub-Scores unterschiedlich gewichtet werden (über einen Satz von $\lambda$ -Gewichten), um das Fahrverhalten zu modulieren (z. B. Priorisierung von Sicherheit gegenüber Fortschritt), ohne das Modell neu trainieren zu müssen.

Wichtigste Beiträge

Einfache Transformer-Architektur: Ein reiner Transformer-E2E-Planner, der den Bedarf an intermediären BEV-Repräsentationen oder großen Trajektorien-Vokabularen eliminiert.
Register-basierte Token-Kompression: Die erste Arbeit, die ViT-Register-Tokens gezielt zur Kompression visueller Features in der E2E-Planung wiederverwendet. Dies erreicht eine kompakte Szenenrepräsentation, die kritischen Kontext bewahrt und gleichzeitig die Rechenlast im Vergleich zu vollen Feature-Maps um Größenordnungen reduziert.
Entkoppeltes Scoring: Ein modulares Design, das die Trajektorien-Generierung vom Scoring trennt, was das Lernen interpretierbarer Sub-Scores ermöglicht und verhaltensbedingte Fahr-Policies zur Inferenzzeit erlaubt.

Experimentelle Ergebnisse

DrivoR wurde auf drei großen Benchmarks evaluiert: NAVSIM-v1, NAVSIM-v2 und der fotorealistischen Closed-Loop-Benchmark HUGSIM.

NAVSIM-v1: DrivoR übertrifft alle existierenden Kamera-only-Methoden und erreicht einen PDMS von 93,7 (mit Trainval-Daten) sowie 94,0 mit zusätzlichen synthetischen Daten, womit es das menschliche Niveau (94,8) fast erreicht. Es übertrifft starke Baselines wie RAP und UniAD signifikant.
NAVSIM-v2: Im anspruchsvollen navhard-two-stage Split erreicht DrivoR einen neuen State-of-the-Art EPDMS von 54,6 und übertrifft damit Modelle wie GTRS und ZTRS. Bemerkenswert ist, dass dies mit einem viel kleineren Backbone (ViT-S) und weniger Parametern (~40M) im Vergleich zu den Wettbewerbern geschieht.
HUGSIM: In einer Zero-Shot-Evaluierung auf der Closed-Loop-Benchmark HUGSIM erreichte DrivoR (trainiert nur auf NAVSIM-v1) die höchste Road Completion (49,8 %) und den höchsten HD-Score (35,7) unter den berichteten Baselines, was eine starke Generalisierung auf fotorealistische 3D-Umgebungen demonstriert.
Effizienz: Die Register-basierte Kompression liefert eine 3-fache Verbesserung des Durchsatzes (110 ms vs. 400 ms pro Forward-Pass auf einer A100 GPU) und eine 3-fache Reduktion der GFLOPS sowie des Peak-Speicherbedarfs im Vergleich zu einem ViT-L Baseline, was eine Echtzeit-Bereitstellung praktikabler macht.

Bedeutung und Behauptungen

Das Paper postuliert, dass eine reine Transformer-Architektur, kombiniert mit gezielter Token-Kompression via Register, ausreichend ist für präzises, effizientes und adaptives End-to-End-Fahren. Die Autoren heben hervor, dass:

Uniformes Pooling suboptimal ist; kamera-bewusste Register ermöglichen es dem Modell, zu lernen, welche Ansichten am informativsten sind (z. B. Frontkameras für die Planung, Rückkameras für spezifische Sicherheitsprüfungen).
Die Entkopplung von Scoring und Generierung die Leistung verbessert und steuerbare Fahrverhaltensweisen ermöglicht.
Hohe Leistung keine massiven Trajektorien-Dictionaries oder komplexe intermediäre 3D-Repräsentationen erfordert; eine einfache, gut strukturierte Transformer-Pipeline kann komplexere Systeme erreichen oder übertreffen und dabei signifikant effizienter sein.

Die Arbeit deutet auf einen Wandel hin zu leichtgewichtigen, register-basierten Kompressionsstrategien für Echtzeit-autonome Fahrsysteme hin und zeigt, dass „weniger mehr ist“, wenn die Kompression gelernt und kontextbewusst erfolgt.