Driving on Registers

Ellington Kirby, Alexandre Boulch, Yihong Xu, Yuan Yin, Gilles Puy, Éloi Zablocki, Andrei Bursuc, Spyros Gidaris, Renaud Marlet, Florent Bartoccioni, et al.

► To cite this version:

Ellington Kirby, Alexandre Boulch, Yihong Xu, Yuan Yin, Gilles Puy, et al. Driving on Registers. 2026. hal-05453518

HAL Id: hal-05453518

https://hal.science/hal-05453518v1

Preprint submitted on 12 Jan 2026

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Driving on Registers

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¹,³

¹valeo.ai, Paris, France

²LIGM, ENPC, IP Paris, UGE, CNRS, France

³Sorbonne Université, CNRS, ISIR, F-75005 Paris, France

`{firstname.lastname}@valeo.com`

## Abstract

We present DrivoR, a simple and efficient transformer-based architecture for end-to-end autonomous driving. Our approach builds on pretrained Vision Transformers (ViTs) and introduces camera-aware register tokens that compress multi-camera features into a compact scene representation, significantly reducing downstream computation without sacrificing accuracy. These tokens drive two lightweight transformer decoders that generate and then score candidate trajectories. The scoring decoder learns to mimic an oracle and predicts interpretable sub-scores representing aspects such as safety, comfort, and efficiency, enabling behavior-conditioned driving at inference. Despite its minimal design, DrivoR outperforms or matches strong contemporary baselines across NAVSIM-v1, NAVSIM-v2, and the photorealistic closed-loop HUGSIM benchmark. Our results show that a pure-transformer architecture, combined with targeted token compression, is sufficient for accurate, efficient, and adaptive end-to-end driving. Code and checkpoints will be made available via the project page.

## 1. Introduction

End-to-end (E2E) planning has emerged as a promising direction for autonomous driving (AD), offering a single pipeline that maps raw sensor data and ego state to driving decisions [19, 48]. Besides, by avoiding intermediate annotations such as 3D boxes, these methods reduce labeling cost. Among E2E approaches, trajectory-proposal methods, whether using a large pre-computed vocabulary [6, 29, 33, 35], or generating proposals on the fly [15, 16, 36, 51], have shown particularly strong performance.

Methods predicting multiple possible trajectories and selecting between them naturally capture the uncertainty within navigation. As in model-based RL [38], the ability to score becomes central: the scorer must reliably choose the best candidate using context encoded in the sensor features.

The sensor processing backbone producing the features that capture this context are thus key in E2E planning methods. These backbones typically dominate the parameter and FLOP count of E2E methods, often leveraging convolutional architectures like VoV-Net [27] or large pre-trained networks such as Vision Transformers [13] like EVA [14], or DINO [39]. Such backbones output thousands of tokens per frame, which must be processed for hundreds of trajectories. This creates a major computational bottleneck that only worsens as resolution or sensor count increases.

The most common solution to reducing the bottleneck is to pool these features along the spatial dimensions. However, feature pooling enforces specific resolution requirements on sensor inputs, and treats all inputs as equally informative, performing the same averaging operation across all cameras. Inspired by works like [53], we ask just how many tokens are needed to represent a driving scene?

We introduce DrivoR, a ViT-based E2E planning architecture that replaces uniform pooling with a fixed set of per-camera register tokens that serve as compact scene descriptors. These tokens preserve planning-relevant context while drastically reducing the visual representation length. Using this compressed representation, DrivoR generates and scores trajectory proposals using two disentangled modules. The final trajectory is selected using predicted sub-scores, allowing behavior modulation at inference.

Our method relies only on scoring annotations (rather than explicit 3D supervision) and achieves state-of-the-art results on NAVSIM-v1 [12], NAVSIM-v2 [5], and the closed-loop HUGSIM benchmark [59]. Overall, our contributions are as follows:

<footnote>*Equal contribution</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 1. DrivoR architecture. The proposed architecture is composed of three transformer blocks: one encoder (perception) and two decoders (trajectory and scoring). The perception encoder compresses perceptual information in camera-aware registers for lightweight subsequent processing in the trajectory and scoring decoders. The decoded trajectories are re-embedded and detached from the gradient computation graph to disentangle scoring and generation. The final trajectory is chosen from the proposal set via the max predicted score.</figcaption></figure>

* An intentionally simple transformer architecture, without any intermediate BEV representations, or any large trajectory dictionary.
* The first work to explore specific, structural, advantages of ViT-based image backbones for E2E planning in the usage of register-based token compression.
* A disentangled scoring module enabling stronger performance and controllable behavior.

## 2. Related Work

**Token compression.** Token reduction is central to efficient ViTs, whose attention cost grows quadratically with sequence length. Simple solutions such as patch-group pooling are parameter-free but treat all tokens uniformly. Other training-free strategies include matching-based compression [2]. Learned approaches range from Perceiver-IO's latent queries [22] to ViT register tokens, originally introduced to fix attention sinks [10] and later used in compact generative models like TiTok [53]. Recent driving-focused works [20, 47] highlight the growing need for token reduction in real-time systems. To our knowledge, we are the first to repurpose ViT register tokens specifically for reducing visual tokens in E2E planning, enabling compact scene representations while retaining planning-critical context.

**End-to-end driving.** End-to-end learning has become popular in autonomous driving since the proof of concept of pioneering works [19, 24] like UniAD [19]. However, they still heavily rely on modular designs with different sub modules, such as detection, tracking and mapping, making it hard to deploy. With the introduction of more efficient (pseudo) closed-loop evaluation metrics [5, 12] or simulation [59], more recent methods [6, 8, 16, 32, 36] predict the planned trajectory or actions directly from sensor inputs, a step forward toward the fully end-to-end paradigm.

These E2E methods [16, 32, 36] mostly rely on off-the-shelf CNN-based (e.g., ResNet-34, ResNet-50, V2-99) im-

age encoders without putting further attention on the design of the perception stack. Downstream in the planning stack, transformers are more robustly explored. Transfuser [8] uses transformers for LiDAR-image fusion; DriveTransformer [23] unifies multiple tasks under one transformer; and iPad [16] exploits transformer residuals for iterative trajectory refinement. Innovation has concentrated on how to use mid-level sensor features rather than on stronger pretrained backbones. When ViTs [13] are used, methods [15, 34, 35, 52] typically rely on large or huge variants without considering the computation costs. These models lean on attention to fuse heterogeneous inputs (ego state, images, LiDAR, commands), but often supplement it with costly 3D reasoning-BEV projections, deformable cross-attention, or LiDAR supervision, raising annotation and compute demands. In this context, we design a simple query-based transformer architecture, built on the much smaller ViT variants, avoiding the high cost of complex intermediate representation, while keeping superior E2E driving performance.

**Trajectory scoring.** Trajectory-proposal based planning has become a compelling direction for E2E driving, introduced in Hydra-MDP [29]. Producing many possible futures and selecting one forces the model to address multimodality head-on. This shifts importance toward the scoring module, which must reliably choose the best candidate [36]. A recent state-of-the-art work on NAVSIM-v2, GTRS [35] showed that learning a sufficiently strong scorer using a ViT backbone, paired with a large trajectory vocabulary, can solve complex scenarios. We introduce the importance of separate scoring and trajectory generation pathways in our E2E model.
<figure><img src="image_3.png" /><figcaption>Figure 2. Encoder and decoder architectures follow standard transformer architectures, with introduction of sensor registers in the encoder, and using these registers as scene tokens in downstream decoders.</figcaption></figure>

# 3. Method

## 3.1. A Simple Design

We design a simple and efficient transformer based architecture for planning in autonomous driving. The overall pipeline is presented in Fig. 1. It is composed of three modules: an encoder for perception and two decoders for trajectory estimation and scoring. The model follows a classical transformer encoder-decoder architecture [45] without any complex intermediate representation.

The encoder for perception (see Sec. 3.2) is a vision transformer [13] applied per camera. In order to compress the feature map to small set of tokens, we introduce additional per-camera registers, finetuned with the backbone to encode the perceptual information. We group together all per-camera register tokens at the output of the ViT to form the scene tokens.

The trajectories are then estimated from learned queries using a transformer decoder attending to the scene tokens via cross-attention (see Sec. 3.3).

Finally, the trajectories are scored in the scoring decoder. Each trajectory becomes a query input of the decoder, which also attends to the scene tokens to produce scores (see Sec. 3.4).

During training, the trajectories are learned using a winner-takes-all regression loss (Sec. 3.3) and the scores are learned against an oracle scorer, e.g., provided along with the dataset (Sec. 3.4). At inference, we re-interpret our learned scoring function as a reward function, enabling driving according to several behavior conditioned policies with a single trained model.

## 3.2. Perception Encoder

At perception level, we seek to fulfill three objectives: 1) leveraging recent ViT architectures; 2) benefiting from pre-trained weights; and 3) limiting the output size to contain the computational complexity in the decoders. To this end, we efficiently compress the perceptual signals into a limited set of tokens using additional registers, and finetune the backbone with LoRA. as illustrated in Fig. 2a.

For each camera, we concatenate $R$ camera registers of size $D_{\text{ViT}}$, along with pre-existing registers, classification token, and patch tokens. $D_{\text{ViT}}$ denotes the dimension of the ViT features. All registers and tokens are fed to the ViT. We then retrieve the $R$ camera tokens at the final layer of the ViT. The final camera tokens for each of the $N$ cameras are finally grouped together to obtain $N \times R$ scene tokens of size $D_{\text{ViT}}$. Note that we use per-camera registers, that is we initialize $N \times R$ registers, where $N$ is the number of input cameras. This allows us to have camera-aware scene tokens: the model can differentiate if a given scene token is extracted from, e.g., the front, left or right camera.

This compression into a small set of camera tokens is close in spirit to Perceiver approaches [21, 22], with the noticeable difference that these approaches use cross-attentions for compression. Setting up such a mechanism in the encoder would require changes in the ViT architecture.

In our case, we can directly use a pretrained ViT as initialization, and perform LoRA finetuning of the ViT backbone to learn the vision-to-register compression, reducing parameter count and speeding training.

## 3.3. Trajectories

**Trajectory decoder.** All decoders use the architecture depicted in Fig. 2b, which consists of a vanilla transformer decoder [45]: a stack of $k$ transformer blocks, each made of a self-attention layer, followed by a cross-attention to the scene tokens, and a feed-forward network (FFN), all with residual connections.

The input of the trajectory decoder consists of a set of learnable trajectory queries $Q_{\text{traj}}$, each of dimension $D_{\text{traj}}$, which is also the inner dimension of the trajectory decoder. After the process, the queries are decoded into $|Q_{\text{traj}}|$ candidate trajectories. These queries are randomly initialized and learned during training. The ego status inputs, consisting of poses, velocities, accelerations, and driving command, are encoded and added to the trajectory queries before entering the decoder. The final trajectory tokens at the end of the transformer are decoded into trajectories with an MLP.

Each decoded candidate trajectory $\tau_i$ is a sequence of $n_p$ poses predicted from the current timestep $t$ (excluded) up to a future horizon at $t+T$, $T$ being the total prediction duration. Each pose is represented as $(x, y, \theta) \in \mathbb{R}^3$, and the full trajectory lies in $\mathbb{R}^{n_p \times 3}$. The variables $x$ and $y$ denote the longitudinal and lateral displacements, respectively, and $\theta$ is
the heading. All quantities are expressed in the ego agent's local reference frame at timestep t. The time interval between successive predicted poses is assumed to be uniform.

**Trajectory loss.** The trajectories $\tau_i$ are learned using a Winner-Takes-All (WTA) approach [17] or, equivalently, the minimum-over-n (MoN) loss [16]. Given a reference human trajectory $\hat{\tau}$ of duration $T$ and consisting of $n_p$ poses, only the closest predicted trajectory is supervised, which allows the model to produce diverse candidate trajectories:

$$ \mathcal{L}_{\text{traj}} = \min_{i} \|\tau_{i} - \hat{\tau}\|_{1} \quad (1) $$

This formulation encourages the model to consider multiple plausible pathways for a given scene.

An additional regression target $\hat{\tau}'$ can be introduced to encourage the predicted trajectories to reach farther waypoints. To construct this target, a reference trajectory with duration $T' > T$ is resampled to $T$ using cubic spline interpolation, producing an accelerated version that matches the number of predicted poses $n_p$. The resulting multi-target trajectory loss is written as

$$ \mathcal{L}_{\text{traj}} = \min_{i} (\|\tau_{i} - \hat{\tau}\|_{1} + \|\tau_{i} - \hat{\tau}'\|_{1}). \quad (2) $$

## 3.4. Scores

**Scoring decoder.** The scoring decoder, which evaluates the quality of each candidate trajectory, uses an architecture mirroring that of trajectory generation.

The scoring decoder takes as input the decoded trajectories as well as perceptual information through the scene tokens. Each decoded trajectory is turned into a $D_{\text{score}}$-dimensional query using an MLP. All the trajectory queries are fed to the scoring decoder.

Embedding the decoded trajectories into a new feature space rather than reusing the trajectory decoder's output tokens is key in our architecture. This enforces a separation between the information used to generate trajectories and the information used to score them: the scorer sees only the decoded trajectory, not the additional latent details still present in the trajectory tokens.

Our scoring decoder then uses cross-attentions between scene tokens and score queries, allowing gradients to flow back to the perception encoder to learn scene tokens useful for both trajectory and scoring predictions. However, we prevent the gradient from the scoring decoder from flowing back to the trajectory decoder. This prevents the trajectory decoder from being influenced by the current quality of the scoring decoder during training.

Finally we predict the six score components [12] using a dedicated MLP for each score.

**Scoring for adjustable driving behavior.** A key feature of our model is its ability to adapt trajectory selection to different driving preferences. For instance, one user may prioritize safety and comfort, while another may favor faster progress at the cost of smoothness. To enable such flexibility, our scoring head predicts separate sub-scores corresponding to different aspects of driving quality (e.g., safety, comfort, efficiency). These sub-scores can then be combined post-hoc into a single meta-score at inference time, allowing the relative importance of each term to be adjusted without retraining the model. We adopt the sub-scores directly from the Predictive Driver Model Score (PDMS) scorer used in NAVSIM-v1.

**Scoring loss.** We train our scoring network via binary cross entropy (BCE) to predict the individual sub-score components $c$ of the PDMS, each given a weight $\lambda_c$:

$$ \mathcal{L}_{\text{score}} = \sum_{c} \lambda_{c} \sum_{i} \text{BCE}(G_{\theta_{c}}(\tau_{i}), G_{c}(\tau_{i})) \quad (3) $$

where $G_c$ is an oracle scorer for the sub-score $c$, and $G_{\theta_c}(\tau_i)$ is our learned scoring head for sub-score $c$.

**Inference.** At inference, we interpret our scoring network as a reward function and our full pipeline as a driving policy which is conditioned on a specific behavior profile encapsulated in the set of weights applied to the scoring outputs. Borrowing from Offline-RL literature such as CtRL-Sim [40], we can thus condition our final scoring output on a driving behavior by modifying the values of our $\lambda_c$, and selecting trajectories which maximize the score computed with this new set of weights. For example, this can encourage trajectories which make maximal estimated progress.

## 3.5. Final Training Loss.

The training loss is the combination of the trajectory loss and the scoring loss:

$$ \mathcal{L} = \mathcal{L}_{\text{traj}} + \lambda_s \mathcal{L}_{\text{score}}. \quad (4) $$

In practice during training, the weights of the losses are all set to 1 for ease of implementation, s.t., $\lambda_c = 1$ for each sub-score $c$ and $\lambda_s = 1$.

## 4. Experiments

**Experimental setup.** As input, we use 4 cameras (front, front left, front right and back). The perception module is a DINOv2 ViT-S [39] encoder, LoRA finetuned [18] (rank 32) following [1]. By default, we add 16 registers per camera. The decoders are 4-layer transformers with an inner dimension of 256. The feed-forward network has a dilation
factor of 4. The camera registers as well as the initial trajectory tokens are randomly initialized with normal distribution $N(0, 10^{-6})$. The model is trained on the navtrain split for 10 epochs, with learning rate $2 \times 10^{-4}$ and cosine annealing scheduling. For the ablation studies, if not described otherwise, we train our model with this common base architecture. All ablation model scores are computed on the navval split. All models were trained on 4 NVIDIA A100 GPUs. The DrivoR model is roughly 40M parameters, significantly below comparable works.

## 4.1. Benchmarks

**NAVSIM-v1.** NAVSIM-v1 [12] is a dataset built out of nuPlan [4] as a subset of OpenScene [9]. As opposed to previous benchmark such as nuScenes [3], mostly formulating driving quality as a measure of similarity to the expert human trajectory, NAVSIM-v1 introduces metrics inspired from closed-loop simulation. The main metric, Predictive Driver Model Score (PDMS), is an aggregation of penalties, e.g., collisions with other, non-reactive, agents, staying on-road and in the correct direction, and avoiding near-misses with other agents. These scores are combined with quality-related scores such as the comfort and progress. Progress is measured as a comparison to the centerline-progress of a PDM agent [11] given access to complete ground-truth information. For training, we use default PDMS weights defined in the benchmark [12].

The results obtained on the NAVSIM-v1 benchmark are presented in Tab. 1. DrivoR outperforms all other methods on NAVSIM-v1, and nears human-level performance. We highlight the comparison to RAP [15], which we consider an orthogonal work: the large quantity of rasterized data introduced in the paper may be used in any method.

**NAVSIM-v2.** NAVSIM-v2 [5] builds on NAVSIM-v1 with the objective of closing the gap with closed-loop, simulator driven, benchmarks. NAVSIM-v2 introduces a second stage of evaluation, where novel variations of scenes are generated via Gaussian Splatting. These novel scenes consist of perturbations of the ego vehicle status, i.e., shifts and rotations, forcing the model to generalize outside of the training distribution. NAVSIM-v2 is scored using an extended version of the score from NAVSIM-v1, termed the EPDMS. We present the results on the navhard-two-stage split of NAVSIM-v2 in table Tab. 3, where DrivoR outperforms all existing works. We note that the results in Tab. 3 were computed after an official bug fix, and thus do not include the largest GTRS-Dense model. Results on NAVSIM-2 before the fix are included in the supplementary material. We use warmup-two-stage<fnref n="1" /> as validation set for NAVSIM-v2

<table><thead><tr><th>Method</th><th></th><th>NC</th><th>DAC</th><th>TTC</th><th>Comf.</th><th>EP</th><th>PDMS</th></tr></thead><tbody><tr><td>PDM-Closed</td><td>[11] PMLR'23</td><td>94.6</td><td>99.8</td><td>89.9</td><td>86.9</td><td>99.9</td><td>89.1</td></tr><tr><td>Human driver</td><td>[12] NeurIPS'24</td><td>100</td><td>100</td><td>100</td><td>99.9</td><td>87.5</td><td>94.8</td></tr><tr><td>RAP-DINO<sup>†</sup></td><td>[15] arXiv'25</td><td>99.1</td><td>98.9</td><td>96.7</td><td>100</td><td>90.3</td><td>93.8</td></tr><tr><td>Ego-stat. MLP</td><td>[12] NeurIPS'24</td><td>93.0</td><td>77.3</td><td>83.6</td><td>100</td><td>62.8</td><td>65.6</td></tr><tr><td>UniVLA</td><td>[46] arXiv'25</td><td>96.9</td><td>91.1</td><td>91.7</td><td>96.7</td><td>76.8</td><td>81.7</td></tr><tr><td>DrivingGPT</td><td>[7] ICCV'24</td><td>98.9</td><td>90.7</td><td>94.9</td><td>95.6</td><td>79.7</td><td>82.4</td></tr><tr><td>UniAD</td><td>[19] CVPR'23</td><td>97.8</td><td>91.9</td><td>92.9</td><td>100</td><td>78.8</td><td>83.4</td></tr><tr><td>LTF</td><td>[8] TPAMI'22</td><td>97.4</td><td>92.8</td><td>92.4</td><td>100</td><td>79.0</td><td>83.8</td></tr><tr><td>PARA-Drive</td><td>[48] CVPR'24</td><td>97.9</td><td>92.4</td><td>93.0</td><td>99.8</td><td>79.3</td><td>84.0</td></tr><tr><td>DriveX-S</td><td>[41] ICCV'25</td><td>97.5</td><td>94.0</td><td>93.0</td><td>100</td><td>79.7</td><td>84.5</td></tr><tr><td>World4Drive</td><td>[57] ICCV'25</td><td>97.4</td><td>94.3</td><td>92.8</td><td>100</td><td>79.9</td><td>85.1</td></tr><tr><td>DRAMA</td><td>[55] ISRR'24</td><td>98.0</td><td>93.1</td><td>94.8</td><td>100</td><td>80.1</td><td>85.5</td></tr><tr><td>VAD-v2</td><td>[6] arXiv'24</td><td>98.1</td><td>94.8</td><td>94.3</td><td>100</td><td>80.6</td><td>86.2</td></tr><tr><td>PRIX</td><td>[49] arXiv'25</td><td>98.1</td><td>96.3</td><td>94.1</td><td>100</td><td>82.3</td><td>87.8</td></tr><tr><td>DiffusionDrive</td><td>[36] CVPR'25</td><td>98.2</td><td>96.2</td><td>94.7</td><td>100</td><td>82.2</td><td>88.1</td></tr><tr><td>DIVER</td><td>[43] arXiv'25</td><td>98.5</td><td>96.5</td><td>94.9</td><td>100</td><td>82.6</td><td>88.3</td></tr><tr><td>AutoVLA</td><td>[60] NeurIPS'25</td><td>98.4</td><td>95.6</td><td>98.0</td><td>99.9</td><td>81.9</td><td>89.1</td></tr><tr><td>DriveVLA-W0[30]</td><td>arXiv'25</td><td>98.7</td><td>99.1</td><td>95.3</td><td>99.3</td><td>83.3</td><td>90.2</td></tr><tr><td>ReCogDrive</td><td>[32] arXiv'25</td><td>97.9</td><td>97.3</td><td>94.9</td><td>100</td><td>87.3</td><td>90.8</td></tr><tr><td>Hydra-MDP++[29]</td><td>arXiv'25</td><td>98.6</td><td>98.6</td><td>95.1</td><td>100</td><td>85.7</td><td>91.0</td></tr><tr><td>iPad</td><td>[16] arXiv'25</td><td>98.6</td><td>98.3</td><td>94.9</td><td>100</td><td>88.0</td><td>91.7</td></tr><tr><td>Centaur</td><td>[42] arXiv'25</td><td>99.5</td><td>98.9</td><td>98.0</td><td>100</td><td>85.9</td><td>92.6</td></tr><tr><td>DriveSuprim</td><td>[52] arXiv'25</td><td>98.6</td><td>98.6</td><td>95.5</td><td>100</td><td>91.3</td><td>93.5</td></tr><tr><td>DrivoR</td><td></td><td>99.0</td><td>98.9</td><td>96.7</td><td>100</td><td>90.0</td><td><strong>93.7</strong></td></tr></tbody></table>

<table><caption>Table 1. NAVSIM-v1. Comparison to existing camera-only methods on the NAVSIM-v1 benchmark on test set (navtest). Full definition of scores in supplementary material, higher is better.</caption><thead><tr><th rowspan="2">Method</th><th colspan="5">RC</th><th colspan="5">HD-Score</th></tr><tr><th>E</th><th>M</th><th>H</th><th>X</th><th>Avg.</th><th>E</th><th>M</th><th>H</th><th>X</th><th>Avg.</th></tr></thead><tbody><tr><td>VAD</td><td>[24]</td><td>51.3</td><td>31.1</td><td>25.3</td><td>26.5</td><td>31.4</td><td>36.3</td><td>9.5</td><td>8.0</td><td>11.5</td><td>13.4</td></tr><tr><td>LTF</td><td>[8]</td><td>67.8</td><td>35.1</td><td>26.2</td><td>40.5</td><td>38.9</td><td>58.9</td><td>18.0</td><td>9.8</td><td>25.9</td><td>23.7</td></tr><tr><td>UniAD</td><td>[19]</td><td>78.4</td><td>60.5</td><td>33.6</td><td>17.8</td><td>45.9</td><td>64.9</td><td>45.8</td><td>20.6</td><td>6.6</td><td>32.7</td></tr><tr><td>DrivoR</td><td></td><td>80.9</td><td>50.5</td><td>33.8</td><td>47.1</td><td><strong>49.8</strong></td><td>73.3</td><td>34.6</td><td>18.8</td><td>32.5</td><td><strong>35.7</strong></td></tr></tbody></table>

E: Easy, M: Medium, H: Hard, X: Extreme

<caption>Table 2. Photorealistic closed-loop evaluation on HUGSIM [59]. Zero-shot generalization using the DrivoR model from the NAVSIM-v1 evaluation. Scores are per difficulty and overall average road completion (RC) and HD-Score, higher always better.</caption>

containing 7 scenes.

We highlight GTRS-DrivoR-ViT-S (row 4), produced by replacing the GTRS backbone with our ViT-S + register-based compression while keeping their original vocabulary and scorer. This swap removes GTRS's pooling in favor of our learned compression, improving performance over the similarly sized V2-99 backbone and approaching the EVA-ViT-L variants (see supplementary), while delivering over 3× higher throughput. Notably, our full SOTA model differs from this variant only in the scoring pipeline, demonstrating the gains from our scorer.

<footnote n="1">¹warmup-two-stage intersects with navhard-two-stage, after request, benchmark authors validated its use as validation set.</footnote>

<footnote>†: RAP [15] is trained on a dataset that is 10× larger than navtrain (the default training set).</footnote>
<table><thead><tr><th rowspan="2">Method</th><th colspan="10">Stage 1</th><th colspan="10">Stage 2</th></tr><tr><th>NC</th><th>DAC</th><th>DDC</th><th>TLC</th><th>EP</th><th>TTC</th><th>LK</th><th>HC</th><th>EC</th><th>NC</th><th>DAC</th><th>DDC</th><th>TLC</th><th>EP</th><th>TTC</th><th>LK</th><th>HC</th><th>EC</th><th>EPDMS</th></tr></thead><tbody><tr><td>RAP-DINO (VIT-H)</td><td>[15]</td><td>97.1</td><td>94.4</td><td>98.8</td><td>99.8</td><td>83.9</td><td>96.9</td><td>94.7</td><td>96.4</td><td>66.2</td><td>83.2</td><td>83.9</td><td>87.4</td><td>98.0</td><td>86.9</td><td>80.4</td><td>52.3</td><td>95.2</td><td>52.4</td><td>39.6</td></tr><tr><td>GTRS-D (V2-99)</td><td>[35]</td><td>98.9</td><td>96.2</td><td>99.4</td><td>99.3</td><td>72.9</td><td>98.9</td><td>95.1</td><td>96.9</td><td>39.1</td><td>91.2</td><td>89.4</td><td>94.4</td><td>98.8</td><td>69.5</td><td>90.0</td><td>54.3</td><td>94.0</td><td>48.7</td><td>45.0</td></tr><tr><td>GTRS-A (V2-99)</td><td>[35]</td><td>98.9</td><td>95.1</td><td>99.1</td><td>99.6</td><td>76.2</td><td>99.1</td><td>94.9</td><td>97.6</td><td>54.2</td><td>88.1</td><td>88.8</td><td>89.3</td><td>98.9</td><td>98.9</td><td>85.9</td><td>53.7</td><td>96.8</td><td>56.9</td><td>45.4</td></tr><tr><td>GTRS-DrivoR (VIT-S)*</td><td></td><td>98.0</td><td>95.8</td><td>99.7</td><td>99.3</td><td>72.9</td><td>98.2</td><td>95.6</td><td>96.9</td><td>51.6</td><td>91.6</td><td>86.7</td><td>90.2</td><td>98.8</td><td>73.2</td><td>88.9</td><td>51.9</td><td>94.9</td><td>46.4</td><td>45.8</td></tr><tr><td>ZTRS (V2-99)</td><td>[34]</td><td>98.9</td><td>97.6</td><td>100</td><td>100</td><td>66.7</td><td>98.9</td><td>96.2</td><td>96.7</td><td>44.0</td><td>91.1</td><td>90.4</td><td>95.8</td><td>99.0</td><td>63.6</td><td>89.8</td><td>60.4</td><td>97.6</td><td>66.1</td><td>48.1</td></tr><tr><td>DrivoR (VIT-S)</td><td></td><td>98.8</td><td>95.1</td><td>98.9</td><td>100</td><td>72.6</td><td>98.7</td><td>94.0</td><td>97.6</td><td>73.3</td><td>90.2</td><td>88.4</td><td>91.9</td><td>98.6</td><td>70.0</td><td>88.0</td><td>50.1</td><td>98.5</td><td>76.2</td><td><b>48.3</b></td></tr></tbody></table>

<caption>Table 3. **NAVSIM-v2 navhard-two-stage.** Comparison to existing methods on the NAVSIM-v2 benchmark test set using the EPDMS. Full definition of all scores in supplementary material, larger always better. Note: other scores reported in the literature before the official benchmark bug fix of the metrics are reported in supplementary material.</caption>

**HUGSIM.** For the closed-loop evaluation, we use HUGSIM [59], a benchmark with scenarios adapted from the original scenes of KITTI-360 [37], nuScenes [3], PandaSet [50], and Waymo [44]. These scenarios are reconstructed as photorealistic 3D environments in which an E2E model controls the ego agent to navigate within each scenario. The planner perceives the 3D environment through RGB cameras whose viewpoints are determined by the ego agent's position in the scenario.

Tab. 2 reports results on the pre-challenge HUGSIM test set (345 scenarios across four difficulty levels). We follow the zero-shot protocol and evaluate with Road Completion (RC) and the HUGSIM Driving Score (HD-Score), the latter combining RC with averaged NC, DAC, TTC, and comfort. DrivoR, trained only on NAVSIM-v1 with no finetuning, achieves an RC of 49.8 and an HD-Score of 35.7—the highest among the reported baselines.

Note that we identified several anomalies in the official evaluation and simulation code, including inconsistent acceleration bounds in the comfort metric computation and an incorrect heading computation for the planned trajectory provided to the controller. After applying the necessary fixes, we reproduced all scores using our corrected implementation, since the results produced by the original code are not directly comparable and do not ensure a reliable evaluation.

**Efficiency.** We benchmark the runtime performance of DrivoR against a ViT-L baseline (GTRS) on a single element batch and an A100 GPU without quantization nor acceleration process. DrivoR obtains a more than 3x throughput improvement (from 400ms/forward to 110ms/forward), with 3x reduction in GFLOPS and peak memory usage, with improved scores, demonstrating a step towards real time usage of a ViT backbone.

<table><caption>(a) Pretaining.</caption><thead><tr><th>Init.</th><th>Random</th><th>ImageNet 21k</th><th>DINOv2</th></tr></thead><tbody><tr><td>PDMS</td><td>70.1</td><td>87.5</td><td>90.0</td></tr></tbody></table>

<table><caption>(b) **Compression and finetuning.** Note the higher performance of register based compression, nearing the model using 250x as many tokens.</caption><thead><tr><th></th><th>Compres-<br>sion</th><th>Cam.<br>tokens</th><th>Scene<br>tokens</th><th>Img. Enc.<br>training</th><th>Parameters<br>Optim</th><th>Total</th><th>PDMS</th></tr></thead><tbody><tr><td>(a)</td><td rowspan="2">No</td><td rowspan="2">4k</td><td rowspan="2">16k</td><td>Frozen</td><td>18.2</td><td>41.2</td><td>88.2</td></tr><tr><td>(b)</td><td>LoRA</td><td>18.8</td><td>41.8</td><td>90.2</td></tr><tr><td>(c)</td><td>Pooling</td><td>16</td><td>64</td><td>LoRA</td><td>18.2</td><td>41.2</td><td>89.7</td></tr><tr><td>(d)</td><td rowspan="2">Decoder</td><td>16</td><td>64</td><td>Frozen</td><td>19.3</td><td>42.3</td><td>86.9</td></tr><tr><td>(e)</td><td>16</td><td>64</td><td>LoRA</td><td>19.9</td><td>42.9</td><td>89.3</td></tr><tr><td>(f)</td><td rowspan="3">Registers</td><td>16</td><td>64</td><td>Full ft.</td><td>41.2</td><td>41.2</td><td>88.4</td></tr><tr><td>(g)</td><td>16</td><td>64</td><td>Frozen</td><td>18.2</td><td>41.2</td><td>84.4</td></tr><tr><td>(h)</td><td>16</td><td>64</td><td>LoRA</td><td>18.8</td><td>41.8</td><td><b>90.0</b></td></tr></tbody></table>

<table><caption>(c) **Scene token count influence.**</caption><thead><tr><th># Tokens<br>per cam.</th><th>per scene</th><th>Registers</th><th>PDMS</th></tr></thead><tbody><tr><td>5</td><td>20</td><td>DINOv2</td><td>88.1</td></tr><tr><td>5 + 16</td><td>84</td><td>DINOv2 + Rand. init.</td><td>89.8</td></tr><tr><td>5</td><td>20</td><td>Rand. init.</td><td>89.7</td></tr><tr><td>8</td><td>32</td><td>Rand. init.</td><td>89.7</td></tr><tr><td>16</td><td>64</td><td>Rand. init.</td><td><b>90.0</b></td></tr><tr><td>32</td><td>128</td><td>Rand. init.</td><td>89.8</td></tr></tbody></table>

<caption>Table 4. **Ablations of the perception.** All results are presented on navval using a ViT-S backbone.</caption>

## 4.2. Ablation Studies

### 4.2.1. Perception

**Image backbone initialization.** Various previous methods [15, 16] use pretrained backbones. We first study the impact of such an initialization on the planning results in Tab. 4a. First, a good initialization of the perception ViT is crucial: using a pretrained backbone improves scores by a

<footnote>*: uses the same ViT-S backbone with registers as DrivoR, the prediction and scoring heads remain the same as in GTRS.</footnote>
<figure><img src="image_4.png" /><figcaption>Figure 3. Cosine similarity between scene tokens. Darker indicates lower cosine similarity. Note the specialized tokens in the front cam, and collapsed tokens in the back cam, showing relative camera compression. Averaged on navval.</figcaption></figure>

large margin (more than 15 PDMS points). Second, using large-scale pretrained DINOv2 [39] improves further over pretraining on ImageNet21k [26]. In all subsequent experiments, we use a pretrained DINOv2 backbone.

**Compression to low number of perceptual tokens.** As argued in Sec. 3, using few perceptual tokens is of interest as it makes the trajectory prediction and scoring lightweight and faster. In Tab. 4b, first column, we study three compression approaches: using a pooling operation of the output feature map as in [35] (c), using a transformer decoder with 16 queries per camera (e), and our proposed approach using 16 additional registers in the model (h). For comparison purpose, we also provide models using the full feature maps, i.e., 16k scene tokens in (b). We observe that our register-based approach outperforms the pooling operation while introducing a low-overhead (0.6M parameters) at training. It also nearly reaches the performances of the no-compression model, despite using 250 times fewer tokens for downstream processing. Additionally, we observe that using a transformer decoder (with roughly the same number of parameters) does not reach the same performance.

**Register token correlation.** Fig. 3 shows inter-register cosine similarity for each camera. Front-camera tokens are largely de-correlated, suggesting per-register specialization. Fig. 4 confirms this: different front camera registers attend to distinct regions (e.g., lead vehicle, traffic lights, sidewalk).

Moving toward the rear cameras, similarity increases sharply: most tokens collapse to the same representation, and within the back camera only one remains distinct. The attention maps (second row of Fig. 4) reflect this collapse.

This pattern aligns with driving intuition: most attention is devoted to the scene ahead, with only brief checks behind. We hypothesize that collapsing less informative views (side/back) reduces noise for downstream planning, an effect which is impossible to observe with uniform pooling.

<table><caption>Table 5. Ablations of the trajectory prediction. Influence of the number of trajectories on navval.</caption><thead><tr><th>Num traj.</th><th>1</th><th>8</th><th>16</th><th>32</th><th>64</th><th>128</th></tr></thead><tbody><tr><th>PDMS</th><td>80.1</td><td>87.6</td><td>88.1</td><td>89.5</td><td><strong>90.0</strong></td><td><strong>90.0</strong></td></tr></tbody></table>

**Finetuning strategy.** Next, we study the finetuning strategy in Tab. 4b, second column, with three different settings: full finetuning (d, f), frozen backbone (a, d, g) and LoRA finetuning [18] (b, c, e, h). For frozen backbone with registers, only the registers are learnable. First, we observe that LoRA finetuning improves the results by a large margin, reaching similar conclusion as in [1] over frozen backbone. It is also the case when comparing LoRA (h) and Full finetuning (f), but to our understanding, it should be possible to close this gap with careful learning rate scheduling specific to the backbone. LoRA being more robust to these meta parameters, we use LoRA finetuning as default.

**Number of registers.** We present in Tab. 4c the evolution of the validation score depending on the number of camera tokens. We either use new registers randomly initialized (the 4 original registers of the DINOv2 backbone are discarded) or, we keep the DINOv2 registers along with our randomly initialized ones. In the later case, to discriminate the cameras, we add per-camera learnable positional encoding to the DINOv2 registers at the image backbone output.

First, using the DINOv2 registers does not help compared to random initialization. We observe that the already specialized registers could be a bad initialization for driving tasks. We hypothesize that similarly to full finetuning, a careful learning rate scheduling could mitigate this gap.

Second, we observe that using more registers improves the performances up to a plateau between 16 and 32 registers per camera, we thus select 16 registers.

### 4.2.2. Trajectories

The number of trajectory queries strongly affects performance. As shown in Tab. 5, increasing queries from 1 (human-only regression) to 128 yields gains that plateau around 64, which we adopt as our default.

### 4.2.3. Scoring

Tab. 6 shows our scoring pipeline ablation results.

**Single vs. dual branches:** (a) Using one transformer branch for both trajectory generation and scoring (with separate MLP heads) harms performance. As shown in Fig. 5, the two tasks attend to different cameras: generation focuses on the front view even for left turns, while scoring draws on left- or rear-camera features depending on trajectory sharpness or collision risk. This motivates separate branches.
<figure><img src="image_5.png" /><figcaption>Figure 4. Attention maps of scene tokens. From the final attention layer, front-camera tokens specialize to distinct regions (traffic light, lead vehicle, road edges), while back-camera tokens largely collapse to the same features, aside from a single distinct token.</figcaption></figure>

<table><caption>Table 6. Ablations of the scoring on navval. Disentanglement refers to a stop-gradient followed by an embedding of decoded trajectories. Behavior control stands for predicting all 6 PDMS components.</caption><thead><tr><th></th><th>Separate decoders</th><th>Disentanglement</th><th>Score num.</th><th>PDMS</th><th>Behavior control</th></tr></thead><tbody><tr><td>(a)</td><td>✗</td><td>-</td><td>6</td><td>84.7</td><td>✓</td></tr><tr><td>(b)</td><td>✓</td><td>✗</td><td>6</td><td>86.8</td><td>✓</td></tr><tr><td>(c)</td><td>✓</td><td>✓</td><td>6</td><td><strong>90.0</strong></td><td>✓</td></tr><tr><td>(d)</td><td>✓</td><td>✓</td><td>1</td><td>88.2</td><td>✗</td></tr></tbody></table>

<figure><img src="image_6.png" /><figcaption>Figure 5. Scoring head disentanglement. Dominant cameras are identified via cross-attention between scene tokens and score or trajectory tokens. Trajectory prediction consistently relies on the front camera, while scoring shifts attention based on trajectory behavior—underscoring the need to separate the two pipelines.</figcaption></figure>

**Disentanglement:** We next examine whether the scoring branch should embed trajectories in a new space and block gradients to the generator. Variant (b) does not disentangle; (c, d) do. Increased separation consistently improves performance.

**Sub-score prediction:** Comparing (c) and (d), predicting multiple sub-scores not only enables behavior control but also improves accuracy. This is likely due to the fact that learning the final output of the scoring formula in Eq. 3 is more difficult than predicting its components.

### 4.2.4. Training

**Longer trajectory.** In Sec. 3, we introduced an augmentation that regresses to a second, more aggressive trajectory. Tab. 7 compares this double objective to standard regression on the human trajectory. It improves NAVSIM-v1, which rewards progress over comfort, but hurts performance on NAVSIM-v2 warmup-two-stage, where perturbed agent states require more cautious driving to avoid collisions and recover safely.

**Final training setup.** For the final model setting, we evaluated longer training lengths. We observe that PDMS on navval increase with the number of epochs, reaching a plateau at 25 epochs. Our final model for NAVSIM-v1 is then trained for 25 epochs, on the competition split (navtrain + navval). On NAVSIM-v2

<table><caption>Table 7. Ablations. Multiple targets for WTA regression, we report PDMS score for NAVSIM-v1 navval and EPDMS for NAVSIM-v2 warmup-two-stage.</caption><thead><tr><th>Targets</th><th>navval (PDMS)</th><th>warmup (EPDMS)</th></tr></thead><tbody><tr><td>(t + T)</td><td>90.0</td><td><strong>39.4</strong></td></tr><tr><td>(t + T) &amp; (t + T')</td><td><strong>90.6</strong></td><td>37.8</td></tr></tbody></table>

(warmup-two-stage), we observe an opposite trend, with EPDMS decreasing with the number of training epochs as well as training using the competition split. We therefore use 10 epochs for NAVSIM-v2.

**Safety-oriented agent.** We evaluate the behavior of our agent obtained after tuning the score weights on warmup-two-stage. Intuitively we expect safer driving to be required for NAVSIM-v2 due to out-of-distribution scenes. In Fig. 6 we represent this agent in dark blue (“Safety-Oriented Agent”), and indeed see improved performance on safety and comfort metrics, but decreased
<figure><img src="image_7.png" /><figcaption>Figure 6. **Safety-oriented agent.** Dark blue was tuned on *warmup-two-stage*, light blue is our NAVSIM-v1 model. The result of our behavior tuning is a more cautious, but safer agent.</figcaption></figure>

progress, representing more passive, safe, driving.

## 5. Conclusion

We present DrivoR, a novel E2E driving method using register-based compression and disentangled scoring representations. DrivoR highlights that full-transformer architectures without complex intermediate states nor large trajectory dictionaries can achieve state-of-the-art results. Future works may explore compression incorporating historical frames or additional sensors, or exploring data and model scaling effects.

## Acknowledgments

We thank Loick Chambon for constant support throughout the project and Lan Feng for helpful discussions. This work was granted access to the HPC resources of IDRIS under the allocations AD011016241 and AD011016239R1 made by GENCI. We acknowledge EuroHPC Joint Undertaking for awarding the project ID EHPC-REG-2024R02-210 access to Karolina, Czech Republic. Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Commission. Neither the European Union nor the European Commission can be held responsible for them. This work was supported by the European Union's Horizon Europe research and innovation programme under grant agreement No 101214398 (ELLIOT).

## References

[1] Merve Rabia Barın, Görkay Aydemir, and Fatma Güney. Robust bird's eye view segmentation by adapting dinov2. In *ECCV Workshops*, 2024. 4, 7

[2] Daniel Bolya, Cheng-Yang Fu, Xiaoliang Dai, Peizhao Zhang, Christoph Feichtenhofer, and Judy Hoffman. Token merging: Your vit but faster. In *ICLR*, 2023. 2

[3] Holger Caesar, Varun Bankiti, Alex H. Lang, Sourabh Vora, Venice Erin Liong, Qiang Xu, Anush Krishnan, Yu Pan, Gi-ancarlo Baldan, and Oscar Beijbom. nuscenes: A multi-

modal dataset for autonomous driving. In *CVPR*, 2020. 5, 6

[4] Holger Caesar, Juraj Kabzan, Kok Seang Tan, Whye Kit Fong, Eric Wolff, Alex Lang, Luke Fletcher, Oscar Beijbom, and Sammy Omari. nuplan: A closed-loop ml-based planning benchmark for autonomous vehicles. In *CVPR Workshops*, 2021. 5

[5] Wei Cao, Marcel Hallgarten, Tianyu Li, Daniel Dauner, Xunjiang Gu, Caojun Wang, Yakov Miron, Marco Aiello, Hongyang Li, Igor Gilitschenski, Boris Ivanovic, Marco Pavone, Andreas Geiger, and Kashyap Chitta. Pseudosimulation for autonomous driving. In *CoRL*, 2025. 1, 2, 5

[6] Shaoyu Chen, Bo Jiang, Hao Gao, Bencheng Liao, Qing Xu, Qian Zhang, Chang Huang, Wenyu Liu, and Xinggang Wang. Vadv2: End-to-end vectorized autonomous driving via probabilistic planning. *arXiv preprint arXiv:2402.13243*, 2024. 1, 2, 5, 3

[7] Yuntao Chen, Yuqi Wang, and Zhaoxiang Zhang. Driving-gpt: Unifying driving world modeling and planning with multi-modal autoregressive transformers. In *ICCV*, 2025. 5, 3

[8] Kashyap Chitta, Aditya Prakash, Bernhard Jaeger, Zehao Yu, Katrin Renz, and Andreas Geiger. Transfuser: Imitation with transformer-based sensor fusion for autonomous driving. *TPAMI*, 2022. 2, 5, 3, 4

[9] OpenScene Contributors. Openscene: The largest up-to-date 3d occupancy prediction benchmark in autonomous driving. In *CVPR*, 2023. 5

[10] Timothée Darcet, Maxime Oquab, Julien Mairal, and Piotr Bojanowski. Vision transformers need registers. In *ICLR*, 2024. 2

[11] Daniel Dauner, Marcel Hallgarten, Andreas Geiger, and Kashyap Chitta. Parting with misconceptions about learning-based vehicle motion planning. In *CoRL*, 2023. 5, 3, 4

[12] Daniel Dauner, Marcel Hallgarten, Tianyu Li, Xinshuo Weng, Zhiyu Huang, Zetong Yang, Hongyang Li, Igor Gilitschenski, Boris Ivanovic, Marco Pavone, et al. Navsim: Data-driven non-reactive autonomous vehicle simulation and benchmarking. In *NeurIPS*, 2024. 1, 2, 4, 5, 3

[13] Alexey Dosovitskiy, Lucas Beyer, Alexander Kolesnikov, Dirk Weissenborn, Xiaohua Zhai, Thomas Unterthiner, Mostafa Dehghani, Matthias Minderer, Georg Heigold, Sylvain Gelly, Jakob Uszkoreit, and Neil Houlsby. An image is worth 16x16 words: Transformers for image recognition at scale. In *ICLR*, 2021. 1, 2, 3

[14] Yuxin Fang, Wen Wang, Binhui Xie, Quan Sun, Ledell Wu, Xinggang Wang, Tiejun Huang, Xinlong Wang, and Yue Cao. Eva: Exploring the limits of masked visual representation learning at scale. In *CVPR*, 2023. 1

[15] Lan Feng, Yang Gao, Eloi Zablocki, Quanyi Li, Wuyang Li, Sichao Liu, Matthieu Cord, and Alexandre Alahi. Rap: 3d rasterization augmented end-to-end planning. *arXiv preprint arXiv:2510.04333*, 2025. 1, 2, 5, 6, 3, 4

[16] Ke Guo, Haochen Liu, Xiaojun Wu, Jia Pan, and Chen Lv. ipad: Iterative proposal-centric end-to-end autonomous driving. *arXiv preprint arXiv:2505.15111*, 2025. 1, 2, 4, 5, 6, 3
[17] Abner Guzman-Rivera, Dhruv Batra, and Pushmeet Kohli. Multiple choice learning: Learning to produce multiple structured outputs. In NeurIPS, 2012. 4
[18] Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, Weizhu Chen, et al. Lora: Low-rank adaptation of large language models. In ICLR, 2022. 4, 7
[19] Yihan Hu, Jiazhi Yang, Li Chen, Keyu Li, Chonghao Sima, Xizhou Zhu, Siqi Chai, Senyao Du, Tianwei Lin, Wenhai Wang, Lewei Lu, Xiaosong Jia, Qiang Liu, Jifeng Dai, Yu Qiao, and Hongyang Li. Planning-oriented autonomous driving. In CVPR, 2023. 1, 2, 5, 3
[20] Boris Ivanovic, Cristiano Saltori, Yurong You, Yan Wang, Wenjie Luo, and Marco Pavone. Efficient multi-camera tokenization with triplanes for end-to-end driving. arXiv preprint arXiv:2506.12251, 2025. 2
[21] Andrew Jaegle, Felix Gimeno, Andy Brock, Oriol Vinyals, Andrew Zisserman, and João Carreira. Perceiver: General perception with iterative attention. In ICML, 2021. 3
[22] Andrew Jaegle, Sebastian Borgeaud, Jean-Baptiste Alayrac, Carl Doersch, Catalin Ionescu, David Ding, Skanda Kop-pula, Daniel Zoran, Andrew Brock, Evan Shelhamer, Olivier J. Hénaff, Matthew M. Botvinick, Andrew Zisser-man, Oriol Vinyals, and João Carreira. Perceiver IO: A gen-eral architecture for structured inputs & outputs. In ICLR, 2022. 2, 3
[23] Xiaosong Jia, Junqi You, Zhiyuan Zhang, and Junchi Yan. Drivetransformer: Unified transformer for scalable end-to-end autonomous driving. arXiv preprint arXiv:2503.07656, 2025. 2
[24] Bo Jiang, Shaoyu Chen, Qing Xu, Bencheng Liao, Jiajie Chen, Helong Zhou, Qian Zhang, Wenyu Liu, Chang Huang, and Xinggang Wang. Vad: Vectorized scene representation for efficient autonomous driving. In ICCV, 2023. 2, 5
[25] Xuefeng Jiang, Yuan Ma, Pengxiang Li, Leimeng Xu, Xin Wen, Kun Zhan, Zhongpu Xia, Peng Jia, XianPeng Lang, and Sheng Sun. Transdiffuser: End-to-end trajectory gen-eration with decorrelated multi-modal representation for au-tonomous driving. arXiv preprint arXiv:2505.09315, 2025. 3
[26] Alexander Kolesnikov, Lucas Beyer, Xiaohua Zhai, Joan Puigcerver, Jessica Yung, Sylvain Gelly, and Neil Houlsby. Big transfer (bit): General visual representation learning. In ECCV, 2020. 7
[27] Youngwan Lee, Joong-won Hwang, Sangrok Lee, Yuseok Bae, and Jongyoul Park. An energy and gpu-computation efficient backbone network for real-time object detection. In CVPR Workshops, 2019. 1
[28] Derun Li, Changye Li, Yue Wang, Jianwei Ren, Xin Wen, Pengxiang Li, Leimeng Xu, Kun Zhan, Peng Jia, Xianpeng Lang, Ningyi Xu, and Hang Zhao. Learning personalized driving styles via reinforcement learning from human feed-back, 2025. 3
[29] Kailin Li, Zhenxin Li, Shiyi Lan, Yuan Xie, Zhizhong Zhang, Jiayi Liu, Zuxuan Wu, Zhiding Yu, and Jose M Alvarez. Hydra-mdp++: Advancing end-to-end driving via expert-guided hydra-distillation. arXiv e-prints, pages arXiv-2503, 2025. 1, 2, 5, 3

[30] Yingyan Li, Shuyao Shang, Weisong Liu, Bing Zhan, Haochen Wang, Yuqi Wang, Yuntao Chen, Xiaoman Wang, Yasong An, Chufeng Tang, et al. Drivevla-w0: World models amplify data scaling law in autonomous driving. arXiv preprint arXiv:2510.12796, 2025. 5, 3
[31] Yingyan Li, Yuqi Wang, Yang Liu, Jiawei He, Lue Fan, and Zhaoxiang Zhang. End-to-end driving with online trajectory evaluation via bev world model. ICCV, 2025. 3
[32] Yongkang Li, Kaixin Xiong, Xiangyu Guo, Fang Li, Sixu Yan, Gangwei Xu, Lijun Zhou, Long Chen, Haiyang Sun, Bing Wang, et al. Recogdrive: A reinforced cognitive framework for end-to-end autonomous driving. arXiv preprint arXiv:2506.08052, 2025. 2, 5, 3
[33] Zhenxin Li, Kailin Li, Shihao Wang, Shiyi Lan, Zhiding Yu, Yishen Ji, Zhiqi Li, Ziyue Zhu, Jan Kautz, Zuxuan Wu, et al. Hydra-mdp: End-to-end multimodal planning with multi-target hydra-distillation. arXiv preprint arXiv:2406.06978, 2024. 1, 3
[34] Zhenxin Li, Wenhao Yao, Zi Wang, Xinglong Sun, Jingde Chen, Nadine Chang, Maying Shen, Jingyu Song, Zuxuan Wu, Shiyi Lan, et al. Ztrs: Zero-imitation end-to-end autonomous driving with trajectory scoring. arXiv preprint arXiv:2510.24108, 2025. 2, 6, 4
[35] Zhenxin Li, Wenhao Yao, Zi Wang, Xinglong Sun, Joshua Chen, Nadine Chang, Maying Shen, Zuxuan Wu, Shiyi Lan, and Jose M Alvarez. Generalized trajectory scoring for end-to-end multimodal planning. arXiv preprint arXiv:2506.06664, 2025. 1, 2, 6, 7, 4
[36] Bencheng Liao, Shaoyu Chen, Haoran Yin, Bo Jiang, Cheng Wang, Sixu Yan, Xinbang Zhang, Xiangyu Li, Ying Zhang, Qian Zhang, et al. Diffusiondrive: Truncated diffusion model for end-to-end autonomous driving. In CVPR, pages 12037-12047, 2025. 1, 2, 5, 3
[37] Yiyi Liao, Jun Xie, and Andreas Geiger. KITTI-360: A novel dataset and benchmarks for urban scene understanding in 2d and 3d. TPAMI, 2023. 6
[38] Thomas M Moerland, Joost Broekens, Aske Plaat, Catholijn M Jonker, et al. Model-based reinforcement learning: A survey. Foundations and Trends in ML, 2023. 1
[39] Maxime Oquab, Timothée Darcet, Théo Moutakanni, Huy V. Vo, Marc Szafraniec, Vasil Khalidov, Pierre Fernandez, Daniel Haziza, Francisco Massa, Alaaeldin El-Nouby, Mido Assran, Nicolas Ballas, Wojciech Galuba, Russell Howes, Po-Yao Huang, Shang-Wen Li, Ishan Misra, Michael Rab-bat, Vasu Sharma, Gabriel Synnaeve, Hu Xu, Hervé Jégou, Julien Mairal, Patrick Labatut, Armand Joulin, and Piotr Bo-janowski. Dinov2: Learning robust visual features without supervision. TMLR, 2024. 1, 4, 7
[40] Luke Rowe, Roger Girgis, Anthony Gosselin, Bruno Carrez, Florian Golemo, Felix Heide, Liam Paull, and Christopher Pal. Ctrl-sim: Reactive and controllable driving agents with offline reinforcement learning. In CoRL, 2024. 4
[41] Chen Shi, Shaoshuai Shi, Kehua Sheng, Bo Zhang, and Li Jiang. Drivex: Omni scene modeling for learning generalizable world knowledge in autonomous driving. In ICCV, 2025. 5, 3
[42] Chonghao Sima, Kashyap Chitta, Zhiding Yu, Shiyi Lan, Ping Luo, Andreas Geiger, Hongyang Li, and Jose M Al-
varez. Centaur: Robust end-to-end autonomous driving with test-time training. arXiv preprint arXiv:2503.11650, 2025. 5, 3
[43] Ziying Song, Lin Liu, Hongyu Pan, Bencheng Liao, Mingzhe Guo, Lei Yang, Yongchang Zhang, Shaoqing Xu, Caiyan Jia, and Yadan Luo. Breaking imitation bottlenecks: Reinforced diffusion powers diverse trajectory generation. arXiv preprint arXiv:2507.04049, 2025. 5, 3
[44] Pei Sun, Henrik Kretzschmar, Xerxes Dotiwalla, Aurelien Chouard, Vijaysai Patnaik, Paul Tsui, James Guo, Yin Zhou, Yuning Chai, Benjamin Caine, Vijay Vasudevan, Wei Han, Jiquan Ngiam, Hang Zhao, Aleksei Timofeev, Scott Ettinger, Maxim Krivokon, Amy Gao, Aditya Joshi, Yu Zhang, Jonathon Shlens, Zhifeng Chen, and Dragomir Anguelov. Scalability in perception for autonomous driving: Waymo open dataset. In CVPR, 2020. 6
[45] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. Attention is all you need. In NeurIPS, 2017. 3
[46] Yuqi Wang, Xinghang Li, Wenxuan Wang, Junbo Zhang, Yingyan Li, Yuntao Chen, Xinlong Wang, and Zhaoxiang Zhang. Unified vision-language-action model. arXiv preprint arXiv:2506.19850, 2025. 5, 3
[47] Yan Wang, Wenjie Luo, Junjie Bai, Yulong Cao, Tong Che, Ke Chen, Yuxiao Chen, Jenna Diamond, Yifan Ding, Wenhao Ding, et al. Alpamayo-r1: Bridging reasoning and action prediction for generalizable autonomous driving in the long tail. arXiv preprint arXiv:2511.00088, 2025. 2
[48] Xinshuo Weng, Boris Ivanovic, Yan Wang, Yue Wang, and Marco Pavone. Para-drive: Parallelized architecture for real-time autonomous driving. In CVPR, 2024. 1, 5, 3
[49] Maciej K Wozniak, Lianhang Liu, Yixi Cai, and Patric Jensfelt. Prix: Learning to plan from raw pixels for end-to-end autonomous driving. arXiv preprint arXiv:2507.17596, 2025. 5, 3
[50] Pengchuan Xiao, Zhenlei Shao, Steven Hao, Zishuo Zhang, Xiaolin Chai, Judy Jiao, Zesong Li, Jian Wu, Kai Sun, Kun Jiang, Yunlong Wang, and Diange Yang. Pandaset: Advanced sensor suite dataset for autonomous driving. In ITSC, 2021. 6
[51] Zebin Xing, Xingyu Zhang, Yang Hu, Bo Jiang, Tong He, Qian Zhang, Xiaoxiao Long, and Wei Yin. Goalflow: Goal-driven flow matching for multimodal trajectories generation in end-to-end autonomous driving. In CVPR, 2025. 1, 3
[52] Wenhao Yao, Zhenxin Li, Shiyi Lan, Zi Wang, Xinglong Sun, Jose M Alvarez, and Zuxuan Wu. Drivesuprim: Towards precise trajectory selection for end-to-end planning. arXiv preprint arXiv:2506.06659, 2025. 2, 5, 3, 4
[53] Qihang Yu, Mark Weber, Xueqing Deng, Xiaohui Shen, Daniel Cremers, and Liang-Chieh Chen. An image is worth 32 tokens for reconstruction and generation. In NeurIPS, 2024. 1, 2
[54] Rui Yu, Xianghang Zhang, Runkai Zhao, Huaicheng Yan, and Meng Wang. Distildrive: End-to-end multi-mode autonomous driving distillation by isomorphic hetero-source planning model. arXiv preprint arXiv:2508.05402, 2025. 3
[55] Chengran Yuan, Zhanqi Zhang, Jiawei Sun, Shuo Sun, Zefan Huang, Christina Dao Wen Lee, Dongen Li, Yuhang

Han, Anthony Wong, Keng Peng Tee, et al. Drama: An efficient end-to-end motion planner for autonomous driving with mamba. In ISRR, 2024. 5, 3
[56] Bozhou Zhang, Nan Song, Jingyu Li, Xiatian Zhu, Jiankang Deng, and Li Zhang. Future-aware end-to-end driving: Bidirectional modeling of trajectory planning and scene evolution. NeurIPS, 2025. 3
[57] Yupeng Zheng, Pengxuan Yang, Zebin Xing, Qichao Zhang, Yuhang Zheng, Yinfeng Gao, Pengfei Li, Teng Zhang, Zhongpu Xia, Peng Jia, et al. World4drive: End-to-end autonomous driving via intention-aware physical latent world model. In ICCV, 2025. 5, 3
[58] Zhiyu Zheng, Shaoyu Chen, Haoran Yin, Xinbang Zhang, Jialv Zou, Xinggang Wang, Qian Zhang, and Lefei Zhang. Resad: Normalized residual trajectory modeling for end-to-end autonomous driving. arXiv preprint arXiv:2510.08562, 2025. 3
[59] Hongyu Zhou, Longzhong Lin, Jiabao Wang, Yichong Lu, Dongfeng Bai, Bingbing Liu, Yue Wang, Andreas Geiger, and Yiyi Liao. HUGSIM: A real-time, photo-realistic and closed-loop simulator for autonomous driving. CoRR, abs/2412.01718, 2024. 1, 2, 5, 6
[60] Zewei Zhou, Tianhui Cai, Seth Z Zhao, Yun Zhang, Zhiyu Huang, Bolei Zhou, and Jiaqi Ma. Autovla: A vision-language-action model for end-to-end autonomous driving with adaptive reasoning and reinforcement fine-tuning. NeurIPS, 2025. 5, 3
# Driving on Registers

## Supplementary Material

### A. Description of PDMS and EPDMS metrics

The Predictive Driver Model Score (PDMS), main metric of NAVSIM-v1, and the Extended Predictive Driver Model Score (EPDMS), main metric of NAVSIM-v2, follow a similar definition, based on a group G of sub metrics. G can be divided into two kinds of metrics: a group $G_p$ of penalties, and a group $G_b$ of behavioral metrics. $G_p$ contains the metrics measuring the compliance to driving rules, such as drivable area compliance or collision occurrence. $G_b$ contains the metrics measuring more driver-related metrics, such as comfort or progress towards the goal. The PDMS and EPDMS metrics are defined as:

$$ \text{Score}(\tau_i) = \prod_{c \in G_p} \mathcal{G}_c(\tau_i)^{\kappa_c^p} \times \frac{1}{Z} \sum_{c \in G_b} \kappa_c^b \mathcal{G}_c(\tau_i) \quad (5) $$

for $\tau_i$ a candidate trajectory, $Z = \sum_{c \in G_b} \kappa_c^b$ and $\kappa$ as defined in Tab. 8. $G_p$ metrics are multiplicative, meaning one failure to comply to a targeted driving rule, i.e., $\mathcal{G}_c(\tau_i) = 0$ results in a score equal to zero. On the contrary, $G_b$ metrics are additive and allow compromise between the metrics, e.g., comfort and progress.

<table><caption>Table 8. Weights of the sub-scores in the PDMS and EPDMS.</caption><thead><tr><th rowspan="2">Abbr.</th><th>Sub-score</th><th rowspan="2">Grp.</th><th>PDMS</th><th>EPDMS</th></tr><tr><th>c</th><th>κ<sub>c</sub></th><th>κ<sub>c</sub></th></tr></thead><tbody><tr><td>NC</td><td>No-at-fault Collisions</td><td>G<sub>p</sub></td><td>1</td><td>1</td></tr><tr><td>DAC</td><td>Drivable Area Compliance</td><td>G<sub>p</sub></td><td>1</td><td>1</td></tr><tr><td>DDC</td><td>Driving direction Compliance</td><td>G<sub>p</sub></td><td>0</td><td>1</td></tr><tr><td>TLC</td><td>Traffic-line compliance</td><td>G<sub>p</sub></td><td>-</td><td>1</td></tr><tr><td>TTC</td><td>Time to Collision</td><td>G<sub>b</sub></td><td>5</td><td>5</td></tr><tr><td>EP</td><td>Ego Progress</td><td>G<sub>b</sub></td><td>5</td><td>5</td></tr><tr><td>Comf.</td><td>Ego Comfort</td><td>G<sub>b</sub></td><td>2</td><td>-</td></tr><tr><td>LK</td><td>Lane Keeping</td><td>G<sub>b</sub></td><td>-</td><td>2</td></tr><tr><td>HC</td><td>History Comfort</td><td>G<sub>b</sub></td><td>-</td><td>2</td></tr><tr><td>EC</td><td>Extended Comfort</td><td>G<sub>b</sub></td><td>-</td><td>2</td></tr></tbody></table>

### B. Training loss weights

We recall here the equation of the score loss defined in the main paper:

$$ \mathcal{L}_{\text{score}} = \sum_{c} \lambda_{c} \sum_{i} \text{BCE}(\mathcal{G}_{\theta_{c}}(\tau_{i}), \mathcal{G}_{c}(\tau_{i})) \quad (6) $$

which corresponds an individual loss for each sub-score of the PDMS. During training, the predicted sub-scores and their associated weight $\lambda_c$ are set as defined in Tab. 9, i.e., all $\lambda_c$ are set to 1.

<table><caption>Table 9. Training loss weights of the sub-scores.</caption><thead><tr><th>Sub-score</th><th>NC</th><th>DAC</th><th>DDC</th><th>TTC</th><th>EP</th><th>Comf.</th></tr></thead><tbody><tr><th>λ<sub>c</sub></th><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr></tbody></table>

Similarly, as defined in the main paper, the final loss is:

$$ \mathcal{L} = \mathcal{L}_{\text{traj}} + \lambda_s \mathcal{L}_{\text{score}}. \quad (7) $$

where, again, $\lambda_s$ is set to 1.

### C. Inference weights of the sub-scores

<table><caption>Table 10. Inference weights of the sub-scores.</caption><thead><tr><th rowspan="2">Abbr.</th><th>Sub-score</th><th rowspan="2">Grp.</th><th>PDMS</th><th>EPDMS</th></tr><tr><th>c</th><th>κ<sub>c</sub></th><th>κ<sub>c</sub></th></tr></thead><tbody><tr><td>NC</td><td>No-at-fault Collisions</td><td>G<sub>p</sub></td><td>1</td><td>10</td></tr><tr><td>DAC</td><td>Drivable Area Compliance</td><td>G<sub>p</sub></td><td>1</td><td>13</td></tr><tr><td>DDC</td><td>Driving direction Compliance</td><td>G<sub>p</sub></td><td>0</td><td>6</td></tr><tr><td>TTC</td><td>Time to Collision</td><td>G<sub>a</sub></td><td>5</td><td>14</td></tr><tr><td>EP</td><td>Ego Progress</td><td>G<sub>a</sub></td><td>5</td><td>15</td></tr><tr><td>Comf.</td><td>Ego Comfort</td><td>G<sub>a</sub></td><td>2</td><td>2</td></tr></tbody></table>

The subscore prediction design in DrivoR enables flexible weighting strategy. In Tab. 10, we provide the sub-score weights for both PDMS (NAVSIM-v1) and EPDMS (NAVSIM-v2). For simplicity, the model trained for NAVSIM-v1 keeps the same weights as in the standard PDMS metrics [12]. For NAVSIM-v2, we adjust the weights with the exception of the Comfort. The adjustment is validated with NAVSIM-v2 warmup-two-stage, see Figure 6 in the original paper.

### D. Implementation details

We conduct our experiments on a node of 8 × A100 GPUs. We run each training on 4 × A100 GPUs with a base learning rate of 0.0002 and batch size of 16, using AdamW optimizer and a cosine annealing learning rate scheduler. The training lasts around 1.5 hours per epoch for the competition split (navtrain + navval) and around 1 hour per epoch for navtrain only. As described in the main paper, we train for 25 epochs for the NAVSIM-v1 (navtrain + navval) and 10 epochs for NAVSIM-v2 navtrain.

### E. Efficiency analysis

Tab. 11 shows the full results of the throughput analysis. We benchmarked each model on a single batch on
<table><thead><tr><th>Method</th><th>Encoder</th><th>Parameters ↓</th><th>GFLOPs ↓</th><th>Peak Memory ↓</th><th>Throughput (ms) ↓</th><th>NAVSIM-v2 EPDMS ↑</th></tr></thead><tbody><tr><td>RAP-Dino [15]†</td><td>ViT-H</td><td>888M</td><td>4760</td><td>4.2GB</td><td>690ms</td><td>39.6</td></tr><tr><td colspan="7">GTRS uses extra trajectories from a diffusion-based model, introducing extra overheads.</td></tr><tr><td>+GTRS-DP [35]</td><td>+V2-99</td><td>+116M</td><td>+731</td><td>+0.75GB</td><td>+389ms</td><td>-</td></tr><tr><td>GTRS-D [35]</td><td>V2-99</td><td>81M</td><td>404</td><td>1.0GB</td><td>96ms</td><td>45.0</td></tr><tr><td>GTRS-A [35]</td><td>V2-99</td><td>171M</td><td>439</td><td>1.42GB</td><td>243ms</td><td>45.4</td></tr><tr><td>GTRS-D [35]‡</td><td>ViT-L</td><td>321M</td><td>1730</td><td>1.6GB</td><td>400ms</td><td>47.0</td></tr><tr><td>ZTRS [34]</td><td>V2-99</td><td>81M</td><td>840</td><td>1.0GB</td><td>193ms</td><td>48.1</td></tr><tr><td>DrivoR</td><td>ViT-S</td><td><strong>34M</strong></td><td><strong>341</strong></td><td><strong>0.5GB</strong></td><td><strong>110ms</strong></td><td><strong>48.3</strong></td></tr></tbody></table>

†: RAP [15] is trained on a dataset that is 10× larger than navtrain (the default training set).

‡: Reproduced.

<caption>Table 11. **Efficiency.** We compare the number of parameters, GFLOPs, peak memory consumption, and throughput w.r.t. the NAVSIM-v2 EPDMS performance. GTRS-A refers to GTRS-Aug and GTRS-D for GTRS-Dense.</caption>

a single A100 GPU. FLOPs counts were conducted using the FVCore library. Peak memory was counted using Pytorch's `max_memory_allocated` function. (Note: FVCore currently excludes Scaled Dot Product Attention and thus FLOPs counts do not reflect the real count for each model, though relative performance should remain consistent.) Throughput was counted on a single forward pass after three warm-up iterations, with the final number averaged over 10 iterations. DrivoR has much improved throughput and lower memory consumption, demonstrating the best tradeoff between performance and efficiency.

## F. Single- vs multi- token per trajectory

Previous works such as [16] have used a single token per trajectory pose, decoding each token into an $(x, y, \theta)$ tuple. We ablate the choice of decoding a single token to a full trajectory vs decoding a set of tokens. Tab. 12 shows that mapping a single token to a trajectory leads to a large jump in performance. Fig. 7 visualizes the same scene, with trajectories decoded either from multi- or single-token. The trajectories mapped from a single token are much smoother and contain less noise, showing that representing trajectories with a single token simplifies learning.

<table><caption>Table 12. **Single- vs multi-token trajectory.** Quantitative comparison on navval.</caption><thead><tr><th>Trajectory representation</th><th>Multi-token</th><th>Single-token</th></tr></thead><tbody><tr><td>PDMS</td><td>83.9</td><td>90.0</td></tr></tbody></table>

## G. Expanded NAVSIM-v1 results

We provide in Tab. 13 a full comparison to state-of-the-art methods, including methods with LiDAR inputs and with post-processing such test-time training, Best-of-N scoring and ensembling. We note that the Best-of-N practice aims to

<figure><img src="image_8.png" /><figcaption>Figure 7. **Single- vs multi- token trajectory.** Qualitative comparison: single-token trajectories are much smoother and less noisy.</figcaption></figure>

score all predicted trajectories with ground truth and select the best trajectory based on the scores from the evaluation, which is not aligned with the evaluation protocol defined in NAVSIM [5, 12].

We note that the goal of DrivoR is to provide a simple and efficient baseline model with registers for end-to-end driving. Without bells and whistles, DrivoR still achieves competitive performance compared to methods with post-processing techniques or additional sensor modality.

## H. NAVSIM-v2 results before benchmark fix

We provide in Tab. 14 the full NAVSIM-v2 state-of-the-art comparison, including the results of methods before the benchmark bug fix (Issue #151 in NAVSIM official GitHub), which is related to the failure of filtering out human driver errors.

From the table, we see that DrivoR ranks among the best-performing methods, with a much lighter model design (see more detail in App. E) and without extra training data. Also, DrivoR ranks first among state-of-the-art methods after the bug fix. This indicates that the errors made by DrivoR are mostly due to human errors, which are not penalized after the fix according to the NAVSIM-v2 benchmark [5].
<table><thead><tr><th>Method</th><th>Mod.</th><th>NC</th><th>DAC</th><th>TTC</th><th>Comf.</th><th>EP</th><th>PDMS</th></tr></thead><tbody><tr><td>PDM-Closed</td><td>[11] PMLR'23</td><td>-</td><td>94.6</td><td>99.8</td><td>89.9</td><td>86.9</td><td>99.9</td><td>89.1</td></tr><tr><td>Human driver</td><td>[12] NeurIPS'24</td><td>-</td><td>100</td><td>100</td><td>100</td><td>99.9</td><td>87.5</td><td>94.8</td></tr><tr><td colspan="9"><em>Test-time training.</em></td></tr><tr><td>Centaur</td><td>[42] arXiv'25</td><td>C</td><td>99.5</td><td>98.9</td><td>98.0</td><td>100</td><td>85.9</td><td>92.6</td></tr><tr><td colspan="9"><em>Best-of-N scores.</em></td></tr><tr><td>AutoVLA</td><td>[60] NeurIPS'25</td><td>C</td><td>99.1</td><td>97.1</td><td>97.1</td><td>100.0</td><td>87.6</td><td>92.1</td></tr><tr><td>DriveVLA-W0</td><td>[30] arXiv'25</td><td>C</td><td>99.3</td><td>97.4</td><td>97.0</td><td>99.9</td><td>88.3</td><td>93.0</td></tr><tr><td>TransDiffuser</td><td>[25] arXiv'25</td><td>C+L</td><td>99.4</td><td>96.5</td><td>97.8</td><td>99.4</td><td>94.1</td><td>94.9</td></tr><tr><td colspan="9"><em>Ensemble methods.</em></td></tr><tr><td>Hydra-MDP-C (v2.99)</td><td>[33] arXiv'25</td><td>C+L</td><td>98.7</td><td>98.2</td><td>95.0</td><td>100</td><td>86.5</td><td>91.0</td></tr><tr><td colspan="9"><em>Methods using 10× more training data.</em></td></tr><tr><td>RAP-DINO†</td><td>[15] arXiv'25</td><td>C</td><td>99.1</td><td>98.9</td><td>96.7</td><td>100</td><td>90.3</td><td>93.8</td></tr><tr><td colspan="9"><em>Multi-modal methods.</em></td></tr><tr><td>TransFuser</td><td>[8] TPAMI'22</td><td>C+L</td><td>97.7</td><td>92.8</td><td>92.8</td><td>100</td><td>79.2</td><td>84.0</td></tr><tr><td>DistillDrive</td><td>[54] arXiv'25</td><td>C+L</td><td>98.1</td><td>94.6</td><td>93.6</td><td>100</td><td>81.0</td><td>86.2</td></tr><tr><td>TrajHF (EM)</td><td>[28] arXiv'25</td><td>C+L</td><td>96.6</td><td>96.6</td><td>92.1</td><td>100</td><td>84.5</td><td>87.6</td></tr><tr><td>DiffusionDrive</td><td>[36] CVPR'25</td><td>C+L</td><td>98.2</td><td>96.2</td><td>94.7</td><td>100</td><td>82.2</td><td>88.1</td></tr><tr><td>WOTE</td><td>[31] ICCV'25</td><td>C+L</td><td>98.5</td><td>96.8</td><td>94.9</td><td>99.9</td><td>81.9</td><td>88.3</td></tr><tr><td>Hydra-MDP (v2.99)</td><td>[33] arXiv'24</td><td>C+L</td><td>98.0</td><td>97.8</td><td>93.9</td><td>100</td><td>86.5</td><td>90.3</td></tr><tr><td>GoalFlow (v2.99)</td><td>[51] CVPR'25</td><td>C+L</td><td>98.4</td><td>98.3</td><td>94.6</td><td>100</td><td>85.0</td><td>90.3</td></tr><tr><td>ResAD (v2.99)</td><td>[58] arXiv'25</td><td>C+L</td><td>98.9</td><td>97.8</td><td>94.9</td><td>100</td><td>87.0</td><td>90.6</td></tr><tr><td>SeerDrive (v2.99)</td><td>[56] NeurIPS'25</td><td>C+L</td><td>98.8</td><td>98.6</td><td>95.8</td><td>100</td><td>84.2</td><td>90.7</td></tr><tr><td colspan="9"><em>Camera-only methods.</em></td></tr><tr><td>Ego-stat. MLP</td><td>[12] NeurIPS'24</td><td>C</td><td>93.0</td><td>77.3</td><td>83.6</td><td>100</td><td>62.8</td><td>65.6</td></tr><tr><td>UniVLA</td><td>[46] arXiv'25</td><td>C</td><td>96.9</td><td>91.1</td><td>91.7</td><td>96.7</td><td>76.8</td><td>81.7</td></tr><tr><td>DrivingGPT</td><td>[7] ICCV'24</td><td>C</td><td>98.9</td><td>90.7</td><td>94.9</td><td>95.6</td><td>79.7</td><td>82.4</td></tr><tr><td>UniAD</td><td>[19] CVPR'23</td><td>C</td><td>97.8</td><td>91.9</td><td>92.9</td><td>100</td><td>78.8</td><td>83.4</td></tr><tr><td>LTF</td><td>[8] TPAMI'22</td><td>C</td><td>97.4</td><td>92.8</td><td>92.4</td><td>100</td><td>79.0</td><td>83.8</td></tr><tr><td>PARA-Drive</td><td>[48] CVPR'24</td><td>C</td><td>97.9</td><td>92.4</td><td>93.0</td><td>99.8</td><td>79.3</td><td>84.0</td></tr><tr><td>DriveX-S</td><td>[41] ICCV'25</td><td>C</td><td>97.5</td><td>94.0</td><td>93.0</td><td>100</td><td>79.7</td><td>84.5</td></tr><tr><td>World4Drive</td><td>[57] ICCV'25</td><td>C</td><td>97.4</td><td>94.3</td><td>92.8</td><td>100</td><td>79.9</td><td>85.1</td></tr><tr><td>DRAMA</td><td>[55] ISR'R'24</td><td>C</td><td>98.0</td><td>93.1</td><td>94.8</td><td>100</td><td>80.1</td><td>85.5</td></tr><tr><td>VAD-v2</td><td>[6] arXiv'24</td><td>C</td><td>98.1</td><td>94.8</td><td>94.3</td><td>100</td><td>80.6</td><td>86.2</td></tr><tr><td>PRIX</td><td>[49] arXiv'25</td><td>C</td><td>98.1</td><td>96.3</td><td>94.1</td><td>100</td><td>82.3</td><td>87.8</td></tr><tr><td>DiffusionDrive</td><td>[36] CVPR'25</td><td>C</td><td>98.2</td><td>96.2</td><td>94.7</td><td>100</td><td>82.2</td><td>88.1</td></tr><tr><td>DIVER</td><td>[43] arXiv'25</td><td>C</td><td>98.5</td><td>96.5</td><td>94.9</td><td>100</td><td>82.6</td><td>88.3</td></tr><tr><td>AutoVLA</td><td>[60] NeurIPS'25</td><td>C</td><td>98.4</td><td>95.6</td><td>98.0</td><td>99.9</td><td>81.9</td><td>89.1</td></tr><tr><td>DriveVLA-W0</td><td>[30] arXiv'25</td><td>C</td><td>98.7</td><td>99.1</td><td>95.3</td><td>99.3</td><td>83.3</td><td>90.2</td></tr><tr><td>ReCogDrive</td><td>[32] arXiv'25</td><td>C</td><td>97.9</td><td>97.3</td><td>94.9</td><td>100</td><td>87.3</td><td>90.8</td></tr><tr><td>Hydra-MDP++</td><td>[29] arXiv'25</td><td>C</td><td>98.6</td><td>98.6</td><td>95.1</td><td>100</td><td>85.7</td><td>91.0</td></tr><tr><td>iPad</td><td>[16] arXiv'25</td><td>C</td><td>98.6</td><td>98.3</td><td>94.9</td><td>100</td><td>88.0</td><td>91.7</td></tr><tr><td>DriveSuprim</td><td>[52] arXiv'25</td><td>C</td><td>98.6</td><td>98.6</td><td>95.5</td><td>100</td><td>91.3</td><td>93.5</td></tr><tr><td>DrivoR (ours)</td><td></td><td>C</td><td>99.0</td><td>98.9</td><td>96.7</td><td>100</td><td>90.0</td><td><strong>93.7</strong></td></tr></tbody></table>

<caption>Table 13. NAVSIM-v1 scores. Full comparison to existing methods, possibly with different modalities (Mod.), on the NAVSIM-v1 benchmark on test set (navtest). ‘C’ refers to camera, and ‘L’ to LiDAR.</caption>

## I. Limitations and additional visualizations

Fig. 8, Fig. 9, and Fig. 10 show DrivoR navigating diverse scenarios, and show the camera focus between the scoring and prediction pathways.

Fig. 9 shows a surprising case where the scoring attention is mainly focused on the back camera, despite the visible traffic light. We hypothesize that adding traffic light compliance as a score component, as in the EPDMS, could force the scoring modules attention to focus more on the traffic light as it crosses the intersection. However we

highlight that despite no active scoring on this component, DrivoR still displays very high TLC score.

Fig. 10 shows a failure case, highlighting the challenge of predicting viable trajectories without historical (past) frames. DrivoR operates only on the current timestep, which makes examples like Fig. 10 challenging, due to the ambiguous nature of the vehicle’s position in the scene. The front camera does not contain easily interpretable objects, and we see the model focusing entirely on the right camera. The resulting trajectories undercut the turn, and could result in the model driving in the wrong way. Future work could include the use of historical frames for planning, potentially alleviating these ambiguous failure cases.

Finally, Fig. 11 compares the predicted and selected trajectories of the two models on the same scene from the NAVSIM-v1 validation set. We can see that the trajectories of our default trained NAVSIM-v1 agent are more aggressive, traveling faster and with less spread than the trajectories from our agent tuned to have more passive behavior. The “passive” agent is however better able to navigate the out-of-distribution (OOD) scenes in NAVSIM-v2.

<footnote>†: RAP [15] is trained on a dataset that is 10× larger than navtrain (the default training set).</footnote>
<table><thead><tr><th rowspan="2">Method</th><th colspan="10">Stage 1</th><th colspan="10">Stage 2</th></tr><tr><th>NC</th><th>DAC</th><th>DDC</th><th>TLC</th><th>EP</th><th>TTC</th><th>LK</th><th>HC</th><th>EC</th><th>NC</th><th>DAC</th><th>DDC</th><th>TLC</th><th>EP</th><th>TTC</th><th>LK</th><th>HC</th><th>EC</th><th>EPDMS</th></tr></thead><tbody><tr><td colspan="21" style="text-align: left; font-weight: bold;">Results before official metric bug fixing.</td></tr><tr><td>PDM-Closed</td><td>[11]</td><td>94.4</td><td>98.8</td><td>100</td><td>99.5</td><td>100</td><td>93.5</td><td>99.3</td><td>97.7</td><td>36.0</td><td>88.1</td><td>90.6</td><td>96.3</td><td>98.5</td><td>100</td><td>83.1</td><td>73.7</td><td>91.5</td><td>25.4</td><td>51.3</td></tr><tr><td>Const. Vel.</td><td>[12]</td><td>88.8</td><td>42.8</td><td>70.6</td><td>99.3</td><td>77.5</td><td>87.3</td><td>78.6</td><td>97.1</td><td>60.4</td><td>83.2</td><td>59.1</td><td>76.5</td><td>98.0</td><td>71.3</td><td>81.1</td><td>47.9</td><td>97.1</td><td>61.9</td><td>10.9</td></tr><tr><td>Ego Hist. MLP</td><td>[12]</td><td>93.2</td><td>55.7</td><td>86.6</td><td>99.3</td><td>81.2</td><td>92.2</td><td>83.5</td><td>97.5</td><td>77.7</td><td>77.2</td><td>51.9</td><td>74.4</td><td>98.2</td><td>77.1</td><td>75.0</td><td>40.8</td><td>97.8</td><td>79.8</td><td>12.7</td></tr><tr><td>LTF</td><td>[8]</td><td>96.2</td><td>79.6</td><td>99.1</td><td>99.6</td><td>84.1</td><td>95.1</td><td>94.2</td><td>97.6</td><td>79.1</td><td>77.8</td><td>70.2</td><td>84.3</td><td>98.1</td><td>85.1</td><td>75.7</td><td>45.4</td><td>95.8</td><td>76.0</td><td>23.1</td></tr><tr><td>RAP-DINO (ViT-H)†</td><td>[15]</td><td>97.1</td><td>94.4</td><td>98.8</td><td>99.8</td><td>83.9</td><td>96.9</td><td>94.7</td><td>96.4</td><td>66.2</td><td>83.2</td><td>83.9</td><td>87.4</td><td>98.0</td><td>86.9</td><td>80.4</td><td>52.3</td><td>95.2</td><td>52.4</td><td>36.9</td></tr><tr><td>GTRS-D (V2-99)</td><td>[35]</td><td>98.7</td><td>91.4</td><td>95.8</td><td>89.2</td><td>99.4</td><td>94.4</td><td>99.3</td><td>98.8</td><td>72.8</td><td>69.5</td><td>98.7</td><td>90.1</td><td>95.1</td><td>54.6</td><td>96.9</td><td>94.1</td><td>40.4</td><td>49.7</td><td>41.7</td></tr><tr><td>GTRS-A (V2-99)</td><td>[35]</td><td>98.9</td><td>87.9</td><td>95.1</td><td>88.8</td><td>99.2</td><td>89.6</td><td>99.6</td><td>98.8</td><td>76.1</td><td>80.3</td><td>99.1</td><td>86.0</td><td>94.7</td><td>53.5</td><td>97.6</td><td>97.1</td><td>54.2</td><td>56.1</td><td>42.1</td></tr><tr><td>GTRS-DrivoR (ViT-S)*</td><td>[35]</td><td>98.0</td><td>95.8</td><td>99.7</td><td>99.3</td><td>72.9</td><td>98.2</td><td>95.6</td><td>96.9</td><td>51.6</td><td>91.6</td><td>86.7</td><td>90.2</td><td>98.8</td><td>73.2</td><td>88.9</td><td>51.9</td><td>94.9</td><td>46.4</td><td>42.3</td></tr><tr><td>GTRS-D (EVA-VIT-L)</td><td>[35]</td><td>97.6</td><td>95.8</td><td>99.8</td><td>99.0</td><td>77.2</td><td>97.8</td><td>95.3</td><td>97.3</td><td>46.7</td><td>91.9</td><td>91.3</td><td>92.7</td><td>99.0</td><td>72.7</td><td>90.4</td><td>53.8</td><td>94.1</td><td>41.6</td><td>43.4</td></tr><tr><td>GTRS-A (ViT-L)</td><td>[35]</td><td>98.7</td><td>98.0</td><td>99.1</td><td>99.8</td><td>75.9</td><td>98.7</td><td>94.7</td><td>97.6</td><td>49.8</td><td>89.5</td><td>89.6</td><td>92.9</td><td>98.5</td><td>78.9</td><td>86.4</td><td>55.3</td><td>96.5</td><td>52.7</td><td>44.7</td></tr><tr><td>DriveSuprim (EVA-VIT-L)</td><td>[52]</td><td>98.7</td><td>98.0</td><td>99.1</td><td>99.8</td><td>75.9</td><td>98.7</td><td>94.7</td><td>97.6</td><td>49.8</td><td>89.5</td><td>89.6</td><td>92.9</td><td>98.5</td><td>78.9</td><td>86.4</td><td>55.3</td><td>96.5</td><td>52.7</td><td>44.7</td></tr><tr><td>GTRS-D (ViT-L)</td><td>[35]</td><td>98.9</td><td>98.2</td><td>99.8</td><td>99.6</td><td>73.9</td><td>98.9</td><td>95.3</td><td>97.3</td><td>40.0</td><td>91.5</td><td>90.8</td><td>94.7</td><td>98.5</td><td>70.8</td><td>90.1</td><td>55.4</td><td>97.2</td><td>54.2</td><td>45.3</td></tr><tr><td>DrivoR (ViT-S) (ours)</td><td>[34]</td><td>98.8</td><td>95.1</td><td>98.9</td><td>100</td><td>72.6</td><td>98.7</td><td>94.0</td><td>97.6</td><td>73.3</td><td>90.2</td><td>88.4</td><td>91.9</td><td>98.6</td><td>69.8</td><td>88.0</td><td>50.1</td><td>98.5</td><td>76.2</td><td>45.3</td></tr><tr><td>ZTRS (V2-99)</td><td>[34]</td><td>98.9</td><td>97.6</td><td>100.0</td><td>100.0</td><td>66.7</td><td>98.9</td><td>96.2</td><td>96.7</td><td>44.0</td><td>91.1</td><td>90.4</td><td>95.8</td><td>99.0</td><td>63.6</td><td>89.8</td><td>60.4</td><td>97.6</td><td>66.1</td><td>45.5</td></tr><tr><td colspan="21" style="text-align: left; font-weight: bold;">Results after official metric bug fixing.</td></tr><tr><td>RAP-DINO (ViT-H)†</td><td>[15]</td><td>97.1</td><td>94.4</td><td>98.8</td><td>99.8</td><td>83.9</td><td>96.9</td><td>94.7</td><td>96.4</td><td>66.2</td><td>83.2</td><td>83.9</td><td>87.4</td><td>98.0</td><td>86.9</td><td>80.4</td><td>52.3</td><td>95.2</td><td>52.4</td><td>39.6</td></tr><tr><td>GTRS-D (V2-99)</td><td>[35]</td><td>98.9</td><td>96.2</td><td>99.4</td><td>99.3</td><td>72.9</td><td>98.9</td><td>95.1</td><td>96.9</td><td>39.1</td><td>91.2</td><td>89.4</td><td>94.4</td><td>98.8</td><td>69.5</td><td>90.0</td><td>54.3</td><td>94.0</td><td>48.7</td><td>45.0</td></tr><tr><td>GTRS-A (V2-99)</td><td>[35]</td><td>98.9</td><td>95.1</td><td>99.1</td><td>99.6</td><td>76.2</td><td>99.1</td><td>94.9</td><td>97.6</td><td>54.2</td><td>88.1</td><td>88.8</td><td>89.3</td><td>98.9</td><td>98.9</td><td>85.9</td><td>53.7</td><td>96.8</td><td>56.9</td><td>45.4</td></tr><tr><td>GTRS-DrivoR (ViT-S)*</td><td>[35]</td><td>98.0</td><td>95.8</td><td>99.7</td><td>99.3</td><td>72.9</td><td>98.2</td><td>95.6</td><td>96.9</td><td>51.6</td><td>91.6</td><td>86.7</td><td>90.2</td><td>98.8</td><td>73.2</td><td>88.9</td><td>51.9</td><td>94.9</td><td>46.4</td><td>45.8</td></tr><tr><td>ZTRS (V2-99)</td><td>[34]</td><td>98.9</td><td>97.6</td><td>100</td><td>100</td><td>66.7</td><td>98.9</td><td>96.2</td><td>96.7</td><td>44.0</td><td>91.1</td><td>90.4</td><td>95.8</td><td>99.0</td><td>63.6</td><td>89.8</td><td>60.4</td><td>97.6</td><td>66.1</td><td>48.1</td></tr><tr><td>DrivoR (ViT-S) (ours)</td><td>[34]</td><td>98.8</td><td>95.1</td><td>98.9</td><td>100</td><td>72.6</td><td>98.7</td><td>94.0</td><td>97.6</td><td>73.3</td><td>90.2</td><td>88.4</td><td>91.9</td><td>98.6</td><td>70.0</td><td>88.0</td><td>50.1</td><td>98.5</td><td>76.2</td><td><b>48.3</b></td></tr></tbody></table>

<figure><img src="image_9.png" /><figcaption>Figure 8. Visualization of generated trajectories (right turn) in a NAVSIM-v1 val set scene. Right turn scenario with right camera as dominant camera used in trajectory scoring and generation.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 9. Visualization of generated trajectories (intersection crossing) in a NAVSIM-v1 val set scene. The ego-vehicle crosses a signalized intersection, but the scoring attention focuses on the rear camera. We hypothesize that the inclusion of the Traffic Light Compliance (TLC) scoring could help in such a case. As a matter of fact, our TLC score on NAVSIM-v2 navhard-two-stage are high (Tab. 14).</figcaption></figure>

<footnote>†: RAP [15] is trained on a dataset that is 10× larger than navtrain (the default training set).</footnote>

<footnote>*: same ViT-S backbone with DrivoR registers, the prediction and scoring heads remain the same as in GTRS.</footnote>
<figure><img src="image_11.png" /><figcaption>Figure 10. Visualization of generated trajectories (failure case) in a NAVSIM-v1 val set scene. Failure case highlighting difficulty of navigation without historical (past) frames. The front camera image is very ambiguous, resulting in full focus on the right camera and trajectories which could result in wrong-way driving.</figcaption></figure>

<figure><img src="image_12.png" /></figure>

<figure><img src="image_13.png" /></figure>

<figure><img src="image_14.png" /><figcaption>Figure 11. Visualization of generated trajectories (agent behavior re-weighting) in a NAVSIM-v1 val set scene.. Left: trajectories are generated from an agent using default PDMS weights on score components. Right: the agent uses our tuned weights. Note the much shorter and less aggressive trajectories of the agent in the second (right) setting, which are better suited for navigating the out-of-distribution (OOD) scenes in the NAVSIM-v2 evaluation.</figcaption></figure>