Plans Are Not Executions: Adapting Frozen World-Model Planners to Controller-Induced Execution Shift
ExecutionBridge, a preprint from Tsinghua University and DENSO's China unit, raised a frozen world-model driving planner's score on the hardest NAVSIM scenes by 44% (PDMS 32.0 to 46.1) when the vehicle's low-level controller differed from the one seen in training, across ten unseen controller settings. Simply feeding the planner the trajectory the controller would actually drive gained almost nothing (0.05 PDMS on the full test set, against 0.61 for the new method).
When a self-driving planner that imagines the future with a learned world model is deployed with a different steering and speed controller, how can it account for the changed execution without retraining the planner or the world model?
World-model planners score candidate trajectories by predicting what happens if each one is driven. That prediction silently assumes the relationship between plan and motion seen in training. A new controller, different gains, steering lag or another chassis can drive the same plan differently, so the imagined future no longer matches the real one and the planner may pick the wrong candidate.
Adaptation methods such as RMA, CaDM and AdaWM infer dynamics from interaction history or retrain parts of the model. The obvious shortcut is to replace each planned trajectory with the trajectory the controller is predicted, or known, to execute. The authors test that shortcut and find it improves geometric accuracy but barely changes which candidate is chosen, because the world model was trained to read a plan, not an already executed motion.
ExecutionBridge keeps the planner, world model and reward head frozen and keeps the original plan as input. A controller encoder looks at a support set of planned and executed trajectory pairs from the deployment controller and compresses them into a compact controller code, computed once and cached. For each candidate, a small latent bridge uses that code to apply a gated, bounded correction to the ego-vehicle part of the world model's predicted latent state, and the unchanged reward head scores the corrected future.
Averaged over ten controller configurations held out from all training, NAVSIM PDMS rose from 87.976 for the frozen WoTE planner to 88.589 (+0.613), against +0.048 for substituting predicted executions, about 13 times smaller. On the subset of scenes where the frozen planner scored below 80, PDMS rose from 32.04 to 46.13 (+14.09), against +4.49 for substitution. Time-to-collision improved from 94.53 to 94.86. Under the standard NAVSIM setting the method added 0.6, 0.4 and 0.3 PDMS to the WoTE, ResWorld and WorldDrive planners. A support set of 64 pairs worked as well as 1,024.
This is a preprint, and every test runs in NAVSIM, a non-reactive benchmark built from logged driving data; no vehicle was driven. The controllers are simulated configurations such as aggressive, conservative, steering-lag and steering-gain styles. On the full test set the gain is under one PDMS point; the large gain sits on a subset chosen because the frozen baseline did badly there, which favours any method that changes the baseline's decisions, although the paper applies the same subset to all methods. The paper reports no added latency and does not mention a code release.
For automotive suppliers the problem is practical: one planning model is meant to ship across many vehicle platforms whose controllers and actuators differ. A cheap adapter that learns a controller's quirks from about 64 logged trajectory pairs, without retraining the planner, would cut validation work per platform; DENSO's co-authorship signals that interest. The same gap appears in robots whose world-model planners hand plans to different low-level controllers. Practical use needs closed-loop tests on real vehicles first, likely a two-to-four-year path.
The full text is not republished here because the paper's license does not allow it. Read the original on arXiv.