SparseDrive unifies detection, mapping, motion and planning around one sparse scene representation

The sparse centric idea, and the three stages it replaces

SparseDrive is a Sparse-Centric paradigm for end-to-end autonomous driving, and the introduction states the three contributions plainly.

First, it explores the sparse scene representation for end-to-end autonomous driving and proposes a paradigm named SparseDrive, which unifies multiple tasks with a sparse instance representation.

Second, it revises the great similarity shared between motion prediction and planning, correspondingly leading to a parallel design for the motion planner, and adds a hierarchical planning selection strategy incorporating a collision-aware rescore module to boost planning performance.

Third, on the challenging nuScenes benchmark, SparseDrive surpasses previous state of the art methods in terms of all metrics, especially the safety-critical metric of collision rate, while keeping much higher training and inference efficiency.

The overview figure's caption describes the pipeline: SparseDrive first encodes multi-view images into feature maps, then learns a sparse scene representation through symmetric sparse perception, and finally performs motion prediction and planning in a parallel manner, with an instance memory queue devised for temporal modeling.

Three things in that sentence carry the design. Symmetric sparse perception unifies detection, tracking and online mapping in a symmetric structure, which is what lets one representation serve three tasks rather than three separate heads. The parallel motion planner performs motion prediction and planning simultaneously and outputs a safe planning trajectory. And the instance memory queue is how the model carries instances across frames without re-deriving them.

The practical consequence of unifying tasks in one representation is that the model gets better at each of them, because the features are shared. The cost is that a change to the representation touches everything downstream, which is a real consideration for a codebase you intend to modify.

The results tables say the efficiency story is the strongest part

The paper results table compares SparseDrive against UniAD on the nuScenes benchmark, and the training time and FPS columns are the ones worth reading first.

UniAD scores NDS 0.498, AMOTA 0.359, minADE 0.71, L2 average 0.73 and a collision rate of 0.61 percent, with 144 hours of training time and 1.8 FPS. SparseDrive-S scores NDS 0.525, AMOTA 0.386, minADE 0.62, L2 average 0.61 and a collision rate of 0.08 percent, with 20 hours of training and 9.0 FPS. SparseDrive-B scores NDS 0.588, AMOTA 0.501, minADE 0.60, L2 average 0.58 and a collision rate of 0.06 percent, with 30 hours of training and 7.3 FPS.

The pattern is that the small variant is seven times faster to train and five times faster at inference than UniAD, and the large variant is close behind on both while scoring better on every metric. The open-loop planning table tells the same story with VAD added, where VAD reaches 4.5 FPS and SparseDrive-S reaches 9.0.

Those are paper numbers on a benchmark, and the open-loop caveat applies to any planning result on nuScenes. What is notable is the shape of the comparison, which is that the efficiency gain is not traded against the accuracy gain. A design that unified tasks and got slower on both axes would be a hard sell, and this one is not that.

The detailed planning table adds a row that matters for interpretation. UniAD without post-optimization reaches L2 average 0.61 and a collision rate of 0.29 percent, which is close to SparseDrive-S on L2 and worse on collisions by a factor of nearly three. So a meaningful part of UniAD's apparent advantage in the first table comes from a post-optimization step rather than from the learned model, and the second table is the one that separates the learned planning from the applied safety filter.

The released checkpoints are two stage, and the collision metric was re-implemented

The main results table lists what the released checkpoints actually achieve, and it comes with a correction that any reader should know about.

The note says: we found that some collision cases were not taken into consideration in our previous code, so we re-implement the evaluation metric for collision rate in released code and provide updated results.

That is a significant caveat. The paper's collision numbers and the released code's collision numbers are not the same measurement, and the released numbers are the corrected ones. The Stage 1 configuration, `projects/configs/sparsedrive_small_stage1.py`, with its checkpoint and training log, reports detection NDS 0.5260, mapping mAP 0.5689, tracking AMOTA 0.385 and AMOTP 1.260, with the motion and planning columns empty. Stage 2, `projects/configs/sparsedrive_small_stage2.py`, reports detection NDS 0.5257, mapping mAP 0.5656, tracking AMOTA 0.372 and AMOTP 1.248, plus motion EPA car 0.492, minADE car 0.61, minFDE car 0.95, MissRate car 0.133, planning CR 0.097 percent and planning L2 0.61.

The two-stage structure is worth understanding. Stage 1 covers the perception tasks, and Stage 2 adds motion prediction and planning, which is why the later columns are blank for Stage 1. The checkpoints and logs are linked from the releases page for v1.0, and the log files are published alongside them, which is a practice worth praising because a training log is what lets you check whether a reproduced run matches.

The one release tag is v1.0 from 2024-06-24, the same day the README notes the code was reorganised for better readability and the code and models were released. The paper itself is on arXiv as 2405.19620, published on 2026-05-31 per the news list, and it was accepted at ICRA 2025 in March of that year.

The repository is a research layout, and the successor already exists

The top level of the repository is what you would expect from a research release rather than a library. There is a `projects/` directory, which holds the configs the results table links to, `tools/`, `scripts/`, `docs/` with the quick start, `resources/` for the figures, a `requirement.txt` rather than a full package manifest, and a `LICENSE` file.

That `requirement.txt` is the clearest signal about how to use it. There is no package to install and no versioned API, so the quick start document in `docs/quick_start.md` is the entry point, and the configs are the unit of configuration rather than command line flags.

The acknowledgements are also informative, because they name the lineage of the approach. Sparse4D is listed first, along with UniAD, VAD, StreamPETR, StreamMapNet and mmdet3d, which is the perception backbone and the toolchain most of this work sits on.

The most important item in the news list, though, is the first one. On 1 April 2026 the following work, SparseDriveV2, was released, with its own arXiv paper and its own code repository.

That changes how you should read this repository. SparseDrive is the first generation, it is complete enough to run and to publish checkpoints for, and it has been superseded by a project with the same authors and a more mature design. If you are starting a research project in this area now, SparseDriveV2 is where the current work is and this repository is the reference implementation you would compare against. If you are reproducing the ICRA 2025 paper, or building on the released checkpoints, this is the code you need, and the fact that the metrics were corrected in the released code is something to check against the paper.

Editorial conclusion

Adopt SparseDrive if you are researching end-to-end autonomous driving on nuScenes and you want a sparse, instance-based perception stack you can read and modify. Do not adopt it as a production driving stack, because it is a research codebase with a single 1.0 release and a successor project already out. Verify first that the nuScenes data and the compute environment are available to you, that the two-stage checkpoint and config pair in the README match each other, and that the collision metric in the released evaluation is the one you want, because the README says the metric was re-implemented after the paper.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. swc-17/SparseDrive on GitHub