🤖 AI

Driving on Registers

Le document présente DrivoR, une architecture purement transformer pour la conduite autonome de bout en bout qui utilise des jetons de registre sensibles à la caméra pour compresser les caractéristiques multi-caméras en une représentation compacte, permettant une génération et une évaluation de trajectoire efficaces avec des sous-scores interprétables tout en surpassant ou égalant les modèles de référence de l'état de l'art sur plusieurs bancs d'essai.

Auteurs originaux : 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

Publié 2026-02-04

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : 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

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

Imaginez que vous enseigniez à un robot à conduire une voiture. Traditionnellement, vous pourriez donner au robot un manuel d'instructions massif de milliers de pages, lui dictant exactement quoi faire dans chaque situation possible. Ce document présente une nouvelle façon d'enseigner au robot, appelée DrivoR, qui est beaucoup plus intelligente, rapide et simple.

Voici le fonctionnement détaillé, en utilisant des analogies de la vie quotidienne :

1. Le problème : Trop d'informations

Imaginez que vous conduisez et que vous regardez à travers six fenêtres différentes (caméras). Un système de vision par ordinateur standard essaie de regarder chaque pixel dans chaque fenêtre, créant ainsi une montagne de données. C'est comme essayer de lire une bibliothèque de livres tout en conduisant ; l'ordinateur est submergé par l'effort de traiter toute cette information avant de pouvoir décider s'il doit tourner ou s'arrêter. Cela rend le système lent et coûteux à exploier.

2. La solution : Les preneurs de notes « Registre »

Les auteurs de DrivoR ont réalisé que le robot n'a pas besoin de lire toute la bibliothèque. Il a juste besoin de quelques notes clés.

Ils ont introduit ce qu'ils appellent les « Jetons de Registre » (Register Tokens). Considérez cela comme une petite équipe de preneurs de notes spécialisés, assis sur le siège passager pour chaque caméra.

Au lieu que l'ordinateur essaie de traiter l'image entière, ces preneurs de notes scannent la vue et notent uniquement les détails les plus importants (comme « voiture devant », « feu rouge » ou « route vide »).
Ils compressent une image immense et désordonnée en un résumé minuscule et ordonné.
Le résultat : L'ordinateur n'a plus qu'à lire quelques phrases au lieu d'un livre entier. Cela rend le système incroyablement rapide et efficace sans perdre sa capacité à voir le danger.

3. Le processus de décision en deux étapes

Une fois que les preneurs de notes ont résumé la scène, le robot doit décider quoi faire. DrivoR divise ce travail en deux équipes distinctes, comme un Entraîneur et un Arbitre.

L'Entraîneur (Générateur de trajectoire) : Cette équipe regarde le résumé et dit : « Voici 100 façons différentes dont nous pourrions conduire au cours des prochaines secondes. » Ils génèrent de nombreux chemins possibles (trajectoires) rapidement.
L'Arbitre (Système de notation) : Cette équipe examine ces 100 chemins et les évalue. Mais voici la partie intéressante : l'Arbitre ne donne pas seulement un seul score (comme « Bon » ou « Mauvais »). Il remet un bulletin de notes avec des notes spécifiques :
- Sécurité : « Quelle est la probabilité que nous nous crashons ? »
- Confort : « Les passagers auront-ils la nausée ? »
- Efficacité : « À quelle vitesse arrivons-nous à destination ? »

4. Conduire avec une « Personnalité »

Parce que l'Arbitre donne des notes séparées pour la sécurité, le confort et la vitesse, vous pouvez changer la personnalité du robot sans avoir à le réentraîner.

Le mode « Sécurité » : Vous dites à l'ordinateur : « Je me soucie à 100 % de la sécurité et du confort. » Le robot choisit le chemin ayant le score de sécurité le plus élevé, même s'il est un peu plus lent.
Le mode « Sportif » : Vous dites à l'ordinateur : « Je veux arriver vite. » Le robot choisit le chemin qui maximise la progression, même s'il est un peu cahoteux.

C'est comme avoir une voiture qui peut instantanément passer d'un « conducteur de grand-mère » à un « pilote de course » simplement en tournant un bouton.

5. Les résultats

Le papier a testé ce système sur des simulations de conduite très difficiles (comme un jeu vidéo plus difficile que la réalité).

Performance : DrivoR a obtenu des performances égales ou supérieures aux systèmes les plus complexes actuellement disponibles.
Vitesse : Parce qu'il utilise ces « preneurs de notes » pour compresser les données, il fonctionne 3 fois plus vite que des systèmes similaires.
Simplicité : Il n'a pas besoin d'un dictionnaire massif de mouvements de conduite préécrits ou de cartes 3D complexes. Il apprend directement des images de la caméra et des « preneurs de notes ».

Résumé

DrivoR est une nouvelle façon de construire des voitures autonomes qui revient à embaucher une équipe de preneurs de notes intelligents pour résumer la route, un Entraîneur pour suggérer de nombreuses options de conduite, et un Arbitre pour noter ces options en fonction de ce que vous valorisez (sécurité vs vitesse). Il prouve que vous n'avez pas besoin d'un super-ordinateur pour bien conduire ; vous avez juste besoin d'une manière intelligente et efficace de traiter l'information.

Résumé Technique : DrivoR – Driving on Registers

Énoncé du Problème

La conduite autonome de bout en bout (E2E) vise à mapper directement les données brutes des capteurs vers les décisions de conduite, réduisant ainsi les coûts d'étiquetage et évitant les annotations modulaires intermédiaires. Bien que les méthodes de proposition de trajectoires aient montré de solides performances en générant plusieurs chemins candidats et en sélectionnant le meilleur, elles font face à un goulot d'étranglement computationnel important. Les approches de pointe actuelles reposent souvent sur des backbones lourds (par exemple, de grands Vision Transformers ou des CNN) qui produisent des milliers de tokens par image. Le traitement de ces tokens pour des centaines de candidats de trajectoire crée une charge de calcul qui évolue mal avec la résolution et le nombre de capteurs. De plus, les solutions existantes reposent souvent sur un pooling uniforme, qui traite toutes les entrées de caméra comme étant également informatives et impose des exigences de résolution rigides, pouvant potentiellement écarter un contexte de planification critique.

Méthodologie : Architecture DrivoR

Les auteurs proposent DrivoR, une architecture purement transformer, simple et efficace, conçue pour la planification E2E. Le système évite les représentations intermédiaires complexes (comme les projections Bird's Eye View) et les dictionnaires de trajectoires pré-calculés volumineux. Au lieu de cela, il utilise un pipeline transformer à trois étapes :

1. Encodeur de Perception avec Registres Sensibles à la Caméra (Camera-Aware)

L'innovation centrale réside dans l'encodeur de perception, qui remplace le pooling uniforme par des tokens de registres sensibles à la caméra.

Mécanisme : Pour chacune des $N$ caméras d'entrée, le modèle introduit un ensemble fixe de $R$ tokens de registres apprenables. Ceux-ci sont concaténés avec les tokens de patch standards et injectés dans un backbone Vision Transformer (ViT) pré-entraîné (spécifiquement DINOv2 ViT-S).
Compression : Le ViT compresse les caractéristiques visuelles de haute dimension en ces $R$ registres par caméra. La sortie est un ensemble compact de $N \times R$ « tokens de scène ».
Avantage : Cette approche réduit considérablement la longueur de la séquence pour le traitement en aval (passant de milliers de tokens à quelques dizaines) tout en préservant le contexte pertinent pour la planification. Les registres sont spécifiques à chaque caméra, permettant au modèle de différencier les vues avant, latérales et arrière.
Entraînement : Le backbone est affiné (fine-tuned) à l'aide de l'adaptation de bas rang (LoRA) pour apprendre la compression vision-vers-registre de manière efficace, maintenant un nombre de paramètres faible.

2. Décodeur de Trajectoire

Le décodeur de trajectoire génère des chemins candidats à l'aide d'une architecture de décodeur transformer standard.

Entrée : Il prend un ensemble de requêtes de trajectoire apprenables, augmentées par des informations sur l'état de l'ego-agent (pose, vitesse, accélération, commandes).
Attention : Les requêtes portent une attention aux « tokens de scène » compressés via une attention croisée (cross-attention).
Sortie : Le décodeur produit un ensemble de trajectoires candidates, chacune représentée comme une séquence de poses $(x, y, \theta)$ dans le référentiel local de l'agent.
Perte : L'entraînement utilise une perte de type Winner-Takes-All (WTA) ou minimum-sur- $N$ (MoN), supervisant uniquement la trajectoire prédite la plus proche de la vérité terrain, ce qui encourage la diversité dans l'ensemble de propositions.

3. Décodeur de Scoring (Désentrelacé)

Un module de scoring distinct évalue la qualité des trajectoires générées.

Désentrelacement : Crucialement, les trajectoires décodées sont ré-encodées dans un nouvel espace de caractéristiques et détachées du graphe de gradient avant d'entrer dans le décodeur de scoring. Cela empêche le processus de génération de trajectoire d'être influencé par la qualité immédiate du scoreur pendant l'entraînement, imposant une séparation entre la génération et l'évaluation.
Sous-scores : Au lieu d'un score scalaire unique, le modèle prédit six sous-scores interprétables correspondant aux composantes du Predictive Driver Model Score (PDMS) (ex: sécurité, confort, efficacité, progression).
Conditionnement de Comportement : Lors de l'inférence, ces sous-scores peuvent être pondérés différemment (via un ensemble de poids $\lambda$ ) pour moduler le comportement de conduite (ex: prioriser la sécurité sur la progression) sans réentraîner le modèle.

Principales Contributions

Architecture Transformer Simple : Un planificateur E2E pur-transformer qui élimine le besoin de représentations BEV intermédiaires ou de vastes vocabulaires de trajectoires.
Compression de Tokens par Registres : Le premier travail réutilisant les tokens de registre de ViT spécifiquement pour compresser les caractéristiques visuelles dans la planification E2E. Cela permet d'obtenir une représentation de scène compacte qui conserve un contexte critique tout en réduisant la charge de calcul de plusieurs ordres de grandeur par rapport aux cartes de caractéristiques complètes.
Scoring Désentrelacé : Une conception modulaire qui sépare la génération de trajectoire du scoring, permettant l'apprentissage de sous-scores interprétables et autorisant des politiques de conduite conditionnées par le comportement lors de l'inférence.

Résultats Expérimentaux

DrivoR a été évalué sur trois benchmarks majeurs : NAVSIM-v1, NAVSIM-v2 et le benchmark en boucle fermée photoréaliste HUGSIM.

NAVSIM-v1 : DrivoR surpasse toutes les méthodes basées uniquement sur la caméra, atteignant un PDMS de 93,7 (en utilisant les données trainval) et 94,0 avec des données synthétiques supplémentaires, se rapprochant des performances humaines (94,8). Il surpasse significativement des baselines solides comme RAP et UniAD.
NAVSim-v2 : Sur le split difficile navhard-two-stage, DrivoR atteint un nouvel état de l'art EPDMS de 54,6, surpassant des modèles comme GTRS et ZTRS. Notamment, il y parvient avec un backbone beaucoup plus petit (ViT-S) et moins de paramètres (~40M) par rapport à ses concurrents.
HUGSIM : Dans une évaluation zero-shot sur le benchmark en boucle fermée HUGSIM, DrivoR (entraîné uniquement sur NAVSIM-v1) a obtenu le taux de complétion de route (Road Completion) le plus élevé (49,8 %) et le meilleur HD-Score (35,7) parmi les baselines rapportées, démontrant une forte généralisation à des environnements 3D photoréalistes.
Efficacité : La compression par registres permet une amélioration de 3x du débit (110ms contre 400ms par passage direct sur un GPU A100) et une réduction de 3x des GFLOPS et de la mémoire de pointe par rapport à une baseline ViT-L, rendant le déploiement en temps réel plus réalisable.

Signification et Revendications

L'article soutient qu'une architecture purement transformer, combinée à une compression de tokens ciblée via des registres, est suffisante pour une conduite de bout en bout précise, efficace et adaptative. Les auteurs soulignent que :

Le pooling uniforme est sous-optimal ; les registres sensibles à la caméra permettent au modèle d'apprendre quelles vues sont les plus informatives (ex: les caméras avant pour la planification, les caméras arrière pour des vérifications de sécurité spécifiques).
Le désentrelacement du scoring et de la génération améliore les performances et permet des comportements de conduite contrôlables.
Une haute performance ne nécessite pas de dictionnaires de trajectoires massifs ou de représentations 3D intermédiaires complexes ; un pipeline transformer simple et bien structuré peut égaler ou dépasser les performances de systèmes plus complexes tout en étant nettement plus efficace.

Ce travail suggère un changement vers des stratégies de compression légères basées sur les registres pour les systèmes de conduite autonome en temps réel, démontant que « moins, c'est plus » lorsque la compression est apprise et sensible au contexte.