Learning the shape of a push

PushT looks almost trivial: use a circular pusher to move a T-shaped block into a matching target. The difficulty is hidden in contact. A push that translates the block from one angle can rotate it away from the goal from another. A plan that is geometrically short can be dynamically impossible.

The controller therefore cannot succeed by drawing a path and hoping the object follows it. It has to learn what a push does: when contact begins, how motion transfers through an off-center collision, when rotation dominates translation, and when the current plan should be abandoned.

We started with a controller that could not produce a useful plan. Over a 2.5-hour run, we let the system interact with the environment for 48 episodes and 4,751 real environment steps. The important artifact was not a larger collection of trajectories; it was an executable dynamics model that changed as those trajectories contradicted it.

Across the 2.5-hour run, we evaluated successive frozen versions of the model on a fixed set of 100 unseen initial conditions. At the beginning, success was 0%: the controller returned no viable plan. By episode 13, it solved 95 of 100. At episode 24 it reached 96, and at episode 37 it reached 97. A later checkpoint retained 97 while reducing the mean successful trajectory to 79.7 steps.

This is the clearest evidence of learning in the run. The task distribution did not get easier and the evaluation seeds did not move. We evaluated five frozen model snapshots; the reported final model is the last distinct model, not a checkpoint selected by its evaluation score.

Episode 00 and episode 11 begin from the same seed. The initial controller made contact and reached 63.0% overlap, then became stuck after 95 steps. After the executable model had been revised, the controller returned to that start and solved it at 96.3% overlap in 131 steps.

This is the behavioral comparison that belongs after the learning curve. The difference is not cosmetic smoothness: the later controller approaches contact with a consequence in mind, allows rotation when it is useful, and replans instead of committing to a brittle open-loop trajectory.

The world model and the planner do different jobs. The model answers a local question: given this state and this push, what state should follow? The planner composes those answers to search for a useful sequence. If the model predicts the wrong contact, a more expensive search only finds a more confidently wrong plan.

Our controller continually re-anchors itself to the real observation. It plans through the executable model, acts for a short horizon, compares the predicted transition with the observed one, and replans when the difference becomes meaningful. This is why an approximate model can still be operationally strong: it only has to be trusted long enough to choose the next useful action.

The successes at the top show that the result is not tied to one geometry. The two runs below make the planning difference more explicit: one finishes in 60 steps, while the other needs 131. The same final model handles both without a trajectory lookup or an episode-specific policy.

After 2.5 hours of end-to-end training, we froze the final system and ran it on 100 unseen initial conditions. It solved 97, became stuck on three, and produced zero degenerate episodes. The public LeRobot Diffusion Policy checkpoint reports 65.4% success over 500 PushT episodes using the standard 95% target-overlap threshold.

The direct numerical comparison is 97.0% versus 65.4%: a lead of 31.6 percentage points, or 1.48 times the success rate. Our model is not edging the public baseline; it is solving almost all of the held-out starts that the baseline misses in aggregate.

The setups are not identical. Our current prototype receives simulator velocity, and training budgets, observations, and evaluation counts differ. We state those advantages plainly. They narrow what can be claimed about the learning algorithm in isolation, but they do not erase the system result: this executable-world-model controller reached 97 of 100 on a frozen held-out set.

Three held-out starts still became stuck. That matters more than a polished 97% headline: the failures identify contact arrangements where the current model or search does not recover quickly enough. There were no degenerate episodes and no uncontrolled replan loops, so the remaining problem is narrower than general controller instability.

The next milestone is to remove privileged simulator velocity and reconstruct motion entirely from observation history. Beyond that, we want broader objects, noisier contact, and tasks where the model must retain what it learned across environments rather than rebuilding everything from zero.

PushT is small, but the principle is not. Learning becomes visible when the system's predictions change, its actions improve on a fixed test, and its failures become more precise. That is the trajectory we care about.