Crowd navigation is the problem of moving a robot safely through a space full of people who are also moving, and a paper accepted to ECCV 2026 has just identified a specific reason compact crowd navigation models are bad at it. The cause is not weak hardware or too little data. It is that two jobs the robot must do at once are quietly fighting over the same weights inside a shared model.
The team, from DGIST and KAIST in South Korea, call this phenomenon Skill Conflict, and their fix is a training method named Disjoint Parameter Training, or DPT. On the JRDB benchmark it cut the planning collision rate from 0.0189 to 0.0091, a reduction of about 52 per cent, while also improving the accuracy of the robot’s predictions about everyone around it. The model that achieves this is small enough for an edge device: 6.44 million parameters, 24.55 megabytes, 10.4 milliseconds per inference.
This article explains what Skill Conflict is, why it appears specifically in the compact models that delivery robots and service robots actually run, how DPT resolves it, and what the published numbers do and do not show. The paper, its supplementary material and a project page are all public, so every figure quoted here is checkable.
Table of contents
- What Crowd Navigation Asks a Robot to Do
- Skill Conflict: The Hidden Cost Inside Compact Models
- How Disjoint Parameter Training Fixes Crowd Navigation Conflicts
- The Crowd Navigation Benchmark Results
- Why Compact Models Matter for Crowd Navigation on Real Robots
- The Three-Way Split That Made Crowd Navigation Worse
- What Crowd Navigation Teams Should Take From This
- Limits of the Crowd Navigation Results
- Frequently Asked Questions About Crowd Navigation and DPT
- References
What Crowd Navigation Asks a Robot to Do
A robot moving through a crowded environment runs two tightly coupled tasks at the same time, and they pull in opposite directions.
Prediction: where is everyone else going?
The first task in crowd navigation is motion prediction. The robot has to forecast where each surrounding person will be over the next few seconds, from their recent trajectory, body pose and bounding box. This is a task about other agents, and it rewards a model that generalises across many people behaving in many ways.
Planning: where should I go?
The second crowd navigation task is motion planning: producing the robot’s own future trajectory so that it reaches its goal without hitting anybody. This is ego-centric and safety-driven, and it rewards conservatism and precision about one agent in particular.
Why both have to live in one model
On a server you would simply run two networks. On a resource-constrained edge device, which is where crowd navigation actually happens, you cannot afford that. The field’s answer has been the unified model: one shared encoder feeding two task-specific decoders. The paper’s backbone extends Social-Transmotion, preserving its multi-modal tokenisation of trajectory, pose and bounding box embeddings, then processing all agent-wise tokens through a shared transformer encoder before splitting into a planning decoder and a prediction decoder.
The assumption nobody checked
Unified models are usually justified by the idea that the two tasks help each other, because understanding the crowd should improve your own route through it. The DGIST and KAIST authors do not dispute that joint reasoning has value. What they show is that it comes bundled with a cost that recent unified crowd navigation models have overlooked.
The paper’s first contribution is naming and measuring the problem. Skill Conflict is defined as a phenomenon where overlapping parameter assignments cause distinct tasks to compete for the same weights, preventing the model from fully specialising in either skill.
How the overlap was measured
The authors identify, for each task, the subset of parameters that matter most to it, controlled by a mask ratio K. They then measure how much the planning set and the prediction set overlap. At a 10 per cent mask ratio there is little conflict. At 50 per cent the overlap rises sharply, and performance on both tasks degrades.
Smaller models suffer more
The most important result for anyone deploying crowd navigation on real hardware is the scaling behaviour. Measured at a fixed 50 per cent mask ratio, compact models with hidden dimensions from 32 to 128 show overlap ratios of 41 to 42 per cent. Larger models at dimensions 256 and 512 show reduced overlap of 34 to 35 per cent.
That result is the whole argument for why this matters. The models small enough to run on a delivery robot are precisely the models in which the two crowd navigation skills collide hardest, so the deployment constraint and the failure mode are the same constraint.
Conflict concentrates in the late layers
The layer-wise picture is uneven. Skill Conflict is small in the early and local layers and spikes in the global layers, peaking at the very last one. That is intuitive: early layers extract shared low-level features from trajectories and poses, while the late global layers are where an ego-centric safety judgement and a neighbour-behaviour forecast genuinely diverge.
How Disjoint Parameter Training Fixes Crowd Navigation Conflicts
DPT is a model-merging framework for crowd navigation rather than a new architecture, which is why it can be applied on top of existing systems.
Step one: train the two skills apart
Instead of training one shared encoder on a joint loss, DPT generates two task-specific models by separating their training regions with binary masks. Planning claims one set of crowd navigation parameters, prediction claims another, and the allocation evolves across steps so that each task progressively occupies distinct territory. Each model keeps its core capability intact before anything is combined.
Step two: merge only the parts that matter
The second idea is Sparse Merging. Rather than combining all task-specific parameters, it integrates only the most influential ones for each task. The paper reports that this prevents interference between adjacent features and concentrates representational capacity where it counts. The headline results use a mask ratio of K equal to 1 per cent, which is a strikingly small fraction.
Step three, optional: put joint reasoning back
Separating the tasks risks throwing away the very thing unified models exist for. The authors address this with an extra fine-tuning stage that applies a joint task loss to the parameter regions left inactive after DPT and Sparse Merging. The core skills stay isolated; the leftover capacity handles cross-task reasoning.
Why this is portable
DPT can be applied in parallel with a variety of merging methods rather than replacing them. The paper demonstrates it on Task Arithmetic, Ties Merging, Localize-and-Stitch and T-Switch, and reports gains in each case. It is a training discipline you layer onto an existing crowd navigation stack, not a rewrite of it.
The Crowd Navigation Benchmark Results
Everything below comes from the paper’s JRDB results table. JRDB and JTA are the two standard crowd navigation benchmarks used; JRDB is captured from a mobile robot moving among people.
| Method | Plan ADE | Collision rate | Plan FDE | Miss rate |
|---|---|---|---|---|
| DIPP | 0.8048 | 0.0167 | 1.3542 | 0.6940 |
| DTPP | 0.6232 | 0.0145 | 1.1338 | 0.6931 |
| Ensemble | 0.5807 | 0.0146 | 0.9000 | 0.4786 |
| Ties Merging | 0.8759 | 0.0167 | 1.1503 | 0.9019 |
| T-Switch | 0.8047 | 0.0199 | 1.1009 | 0.8784 |
| DPT + Sparse Merging | 0.4044 | 0.0091 | 0.7458 | 0.3706 |
| DPT + SM + joint reasoning | 0.3640 | 0.0074 | 0.7105 | 0.3589 |
Reading the collision rate
Collision rate is the crowd navigation safety metric, and it is the one that matters for a robot sharing a corridor with people. Vanilla joint training sits at 0.0189. DPT with Sparse Merging reaches 0.0091, a 52 per cent reduction. Adding the joint reasoning stage takes it to 0.0074, which is 61 per cent below the vanilla baseline and 49 per cent below the best conventional unified model in the table, DTPP at 0.0145.
The merging baselines went backwards
The result worth dwelling on is that several established model-merging methods perform worse than plain joint training on this task. Ties Merging, Task Arithmetic and Localize-and-Stitch all sit above the vanilla collision rate or close to it. The authors attribute this to Skill Conflict: existing merging methods cannot exploit fine-tuned task skills that were never cleanly separated in the first place.
What it costs to train
Better numbers are not free, and the paper is transparent about the bill.
| Method | Collision rate | Prediction ADE | GPU-hours |
|---|---|---|---|
| Joint training (vanilla) | 0.0189 | 0.6552 | 1.58 |
| Joint training (game-theoretic) | 0.0188 | 0.6471 | 2.90 |
| Ties Merging | 0.0167 | 0.9463 | 3.38 |
| DPT + Sparse Merging | 0.0091 | 0.5952 | 4.10 |
DPT costs 4.10 GPU-hours against 1.58 for vanilla joint training, roughly 2.6 times more. For a one-off training run that produces a model deployed across a fleet, that is a trivial price. It also beats Ties Merging on every metric while costing only 21 per cent more compute than it.
Why Compact Models Matter for Crowd Navigation on Real Robots
The inference figures explain why the authors cared about compactness in crowd navigation in the first place.
The deployment envelope
Measured on an RTX 3090 at batch size 1, the model runs at 10.4 milliseconds latency, 1.65 GFLOPs, 6.44 million parameters, 24.55 megabytes of model size and 1.96 megabytes of inference memory. At 10.4 milliseconds the model can in principle be queried far faster than any wheeled robot needs to replan, leaving headroom for perception, control and everything else sharing the compute budget.
Why not just use a bigger model
Because the overlap finding says bigger models have less Skill Conflict, the obvious response is to scale up. The deployment constraint forbids it: a service robot, a warehouse mover or a pavement delivery unit runs on an embedded module with a power budget, not a workstation card. DPT is valuable precisely because it recovers specialisation without spending parameters, which is the resource these platforms do not have.
Where this connects to existing robotics work
Nothing in DPT is specific to pedestrians. The paper also evaluates it on Bench2Drive, comparing end-to-end autonomous driving models in closed-loop and open-loop settings with and without DPT and Sparse Merging. Any system that shares an encoder between an ego-planning head and a world-prediction head is a candidate, which covers a large slice of current machine learning work in mobile robotics.
The ablation that tells you how to tune it
The authors swept the allocation ratio between the two tasks and found the expected trade: a higher DPT allocation to one task lowers performance on the other. They also tested three-way splits, dividing prediction into sub-tasks by velocity, by distance from the ego robot and by crowd density. None beat the plain two-way split of planning against prediction, which is a useful negative result for anyone tempted to over-engineer the partition.
The Three-Way Split That Made Crowd Navigation Worse
One of the most useful parts of the supplementary material is an experiment that failed. If separating planning from prediction helps, the obvious next move is to separate prediction itself into sub-tasks. The authors tried three different ways of doing exactly that.
Three ways to slice prediction
Each three-way split gave planning one parameter region and divided prediction between two more: by pedestrian velocity, separating fast movers from slow ones; by distance from the ego robot, separating near neighbours from far ones; and by crowd density, separating dense scenes from sparse ones.
| Task split | Prediction overlap | Collision rate | Plan ADE | Miss rate |
|---|---|---|---|---|
| Three-way, by velocity | 6.90% | 0.0149 | 0.4947 | 0.3859 |
| Three-way, by distance from ego | 12.99% | 0.0107 | 0.4240 | 0.3790 |
| Three-way, by crowd density | 15.13% | 0.0151 | 0.4739 | 0.3818 |
| Two-way, planning against prediction | Not applicable | 0.0091 | 0.4044 | 0.3706 |
The plain split wins on every column
The simple two-way partition beats all three refinements on collision rate, planning error and miss rate alike. The velocity split is the worst of the three on safety at 0.0149, which is 64 per cent higher than the two-way result. Even the best three-way variant, the distance split at 0.0107, is 18 per cent worse.
Why more separation stops helping
The reading the authors offer is that prediction sub-tasks are not genuinely distinct skills. Forecasting a fast pedestrian and a slow one draws on the same underlying competence, so carving the parameter space between them spends capacity on a boundary that does not exist. Skill Conflict is worth resolving where the objectives really differ, which in crowd navigation means ego safety against neighbour behaviour and nothing finer.
A useful rule for anyone applying it
Partition along the axis where the loss functions disagree, not along the axis where the data looks different. That is a cheap principle to carry into any multi-task system, and this experiment is a clean demonstration of what happens when it is ignored.
What Crowd Navigation Teams Should Take From This
Most readers will not train a crowd navigation model this year, but three of the findings transfer directly.
Check for overlap before adding capacity
The instinct when a compact multi-task model underperforms is to make it bigger or feed it more data. This work suggests measuring parameter overlap between the task heads first, because on a small model the ceiling may be conflict rather than capacity. That diagnostic costs a fraction of a retraining run.
Merging methods are not interchangeable
Several respected model-merging techniques made crowd navigation performance worse than doing nothing clever at all. A merging method that works on classification benchmarks carries no guarantee on a pair of tasks with genuinely opposed objectives, and the only way to know is to measure the collision rate rather than the average.
Budget the training cost honestly
DPT is 2.6 times the compute of vanilla joint training. In an organisation running an ML model development pipeline, that is an easy trade for a halved collision rate on a model shipped to a fleet, and a poor one for a throwaway experiment. The decision is about how many robots run the artefact, not about the elegance of the method.
Measure the metric that matters to you
Planning ADE and collision rate improved together here, but they are not the same quantity and a method can trade one for the other. A warehouse robot working around static shelving cares about displacement error; a robot sharing a pavement cares about the collision rate almost exclusively. Decide which column of the results table is your acceptance criterion before you start, because the paper reports several and they do not always move in the same direction.
Pair the model with conventional sensing
Learned crowd navigation policies improve steadily, and none of them removes the need for the deterministic layer underneath. Proximity sensing, emergency stop behaviour and geofencing remain the things that make a deployment defensible, in much the same way predictive analytics informs a decision without being allowed to make it unsupervised.
Read the negative results
The three-way split experiment and the merging baselines that went backwards are the two most instructive results in the paper, and neither appears in the abstract. On any crowd navigation paper, the supplementary tables are where the deployment-relevant information usually lives.
Limits of the Crowd Navigation Results
The paper is an honest one, but a reader should hold several caveats in mind before treating these numbers as a deployment promise.
Benchmarks are not corridors
JRDB and JTA are offline datasets. A low collision rate on recorded crowd navigation trajectories is evidence about a model, not about a robot. Nothing in the published work reports a physical deployment, and the gap between benchmark crowd navigation performance and real pedestrian behaviour has defeated many methods before this one.
The reported gains are single-architecture
Most of the results use the authors’ own Social-Transmotion-derived backbone. The DTPP experiments and the Bench2Drive evaluation broaden that, and robustness across three random seeds is reported, but the strongest claims still rest on one model family tested on two benchmarks.
Metrics do not capture social comfort
Average and final displacement error and collision rate say nothing about whether a robot’s path feels acceptable to the people around it. A machine that never touches anyone while cutting across their path is still a bad neighbour, and crowd navigation research has no agreed metric for that.
It is a training method, not a safety case
DPT reduces a crowd navigation failure rate substantially. It does not eliminate collisions, and 0.0074 is not zero. Any deployment still needs the conventional safety layer underneath the learned policy, and treating an improved benchmark figure as a substitute for that would be a serious error.
Frequently Asked Questions About Crowd Navigation and DPT
What is Skill Conflict?
A phenomenon the paper defines in which planning and prediction compete for the same weights inside a shared encoder, so neither task can fully specialise. It is measured as the overlap between the parameter regions each task depends on most.
How much does DPT reduce collisions?
On JRDB the collision rate falls from 0.0189 with vanilla joint training to 0.0091 with DPT and Sparse Merging, about 52 per cent, and to 0.0074 with the additional joint reasoning stage.
Does this only apply to robots that walk among people?
No. The same shared-encoder structure appears in end-to-end autonomous driving, and the paper includes a Bench2Drive evaluation. Any model pairing an ego-planning head with a prediction head can exhibit the same conflict.
Who published it, and where?
Taewon Seo, Seonae Jeon, Giwon Lee, Kuk-Jin Yoon and Daehee Park, of DGIST and KAIST, in a paper accepted to ECCV 2026. The preprint is on arXiv and a project page with code links is public.
Is the model small enough for an embedded robot?
The reported model is 6.44 million parameters and 24.55 megabytes, with 1.96 megabytes of inference memory, measured at 10.4 milliseconds on an RTX 3090. Latency on an embedded accelerator would differ and has not been published.
References
Unified Prediction and Planning via Conflict-Aware Disjoint Parameter Training
Full paper text, tables and ablations
DPT project page, DGIST and KAIST
alphaXiv overview of the paper
Collision-Free Robot Navigation in Crowded Environments using Learning based Convex MPC
Visual Target-Driven Robot Crowd Navigation with Limited FOV