Can Robot Play Data Teach Contact-Rich Manipulation?

Yes—but the play cannot simply be mixed into a task policy and expected to help. ForceWAM shows a more careful use: successful demonstrations teach what task-compatible motion and contact should look like, while robot play data teach how local actions change contact. A separate action model connects the two at deployment.

That division is the interesting result. In the authors' four real-robot conditions, the full system reports 85–95% mean success. Adding 200 play episodes per task family raises success by 15–45 percentage points over the same system's task-only executor. Yet adding the same kind of play directly to two end-to-end baselines makes both worse in every condition. The evidence is not that more varied data always wins; it is that data becomes useful when the learning objective matches what the data can actually explain.

A successful demonstration hides useful mistakes

A task demonstration records a route that worked. For force-regulated sliding, that may be one trajectory holding roughly the desired normal force. It does not necessarily show what happens after the tool presses too hard, begins to lose contact, or approaches the surface at a slightly different angle.

Exploratory play can cover those nearby responses. In ForceWAM, play consists of pressing, sliding, and making or breaking contact without an evaluation-task instruction. Each play episode still contains synchronized wrist RGB, a six-axis tool-centre-point wrench, and the robot action that produced the transition. It is task-agnostic, not action-free or sensor-free.

This use of play has a longer history. Learning Latent Plans from Play used continuous teleoperated interaction without task segmentation or reset to learn a reusable behaviour space. ForceWAM asks a narrower question: can off-task contact experience improve execution when the goal still comes from successful task demonstrations?

The answer depends on preserving the distinction between two kinds of evidence:

If those records are flattened into one pile, an exploratory push can look like a task command. ForceWAM instead keeps their roles separate.

Two models divide the learning problem

The first model, ForceWM, learns only from successful task demonstrations. Given the current wrist image, measured wrench, and task instruction, it predicts a short future containing both video and wrench values. That future acts as a reference: it describes where the visual interaction should go and how the contact load should evolve.

The second model learns inverse dynamics. Given the current observation and a recorded visual-wrench future, it predicts the actions associated with that future. Because a play segment contains actions and their consequences, it can train this executor even when the segment never solves the downstream task.

At deployment, the recorded future is replaced by ForceWM's generated one. The executor receives a task-compatible reference from the demonstration-trained model, while its broader action-response knowledge comes from both demonstrations and play. This is how ForceWAM avoids asking play data to supply a goal it never contained.

This is adjacent to a world-action model, but the name deserves care. ForceWM predicts a future and does not itself send motor commands. The inverse-dynamics model turns the predicted future into Cartesian tool-pose and gripper commands. Calling the whole stack one end-to-end policy would hide the very separation the experiment tests.

The future contains contact, not only pixels

A visually plausible future can still be mechanically wrong. Two frames can show the tool against the box while one corresponds to firm contact and the other to a gap, jam, or damaging load. ForceWAM therefore generates a visual future and the next 16 six-component wrench samples together.

The visual target uses wrist-camera frames at four future offsets. The wrench target retains forces and torques along three axes. Both become aligned latent conditions for the executor, while a separate causal stream carries newly measured wrench values during execution. The paper's ablation makes the complementarity unusually clear: visual-only and wrench-only futures both perform far below their joint visual-wrench condition across the four reported tests.

That does not make the predicted force a measurement. The paper shows that generated wrench curves preserve the broad contact stages during box flipping, but local appearance and peak force values differ from the recorded rollout. The generated future is a learned reference; the end-effector sensor provides the live evidence.

Slow prediction and fast response run on different clocks

Generating a multimodal future is expensive, and contact can change while it runs. ForceWAM refreshes the future every six actions, caches that reference, and then repeatedly re-runs the action model using the growing sequence of measured wrench feedback. Only the current action is sent to the low-level controller.

The appendix reports about 100 ms for one ForceWM call and about 60 ms for one five-step action-model call on the deployment system. The previous controller target remains active while a refresh is computed. Those are implementation measurements for this stack, not a universal real-time guarantee, but they expose an important systems point: planning and response do not need to share one update rate.

For a humanoid, this multi-rate distinction becomes even more important. A high-level future might describe hand-object motion and intended load, while whole-body control must react to foot contact, balance, joint limits, and external disturbance at shorter timescales. ForceWAM does not solve that humanoid stack, but it demonstrates why one slow visual plan should not be mistaken for the complete feedback loop.

What the real-robot comparison establishes

The authors collect 200 successful demonstrations and 200 play episodes for each of three task families; ordinary and disturbed box flipping share their training data. All experiments use one Flexiv Rizon 4S seven-degree-of-freedom collaborative arm, a wrist RGB camera, and a six-axis end-effector force–torque sensor. Sliding and flipping use kinesthetic teaching, while Hanoi ring placement uses Meta Quest 3 teleoperation.

Each reported evaluation uses 20 matched-start trials per condition with the same safety limits and controller interface. Success requires completion without a safety stop or human intervention; sliding also has the 5–15 N force criterion.

These are author-reported mean success rates, not independent replication. They do support three bounded conclusions within this setup:

1. The task-only ForceWAM executor already outperforms the compared external baselines, so the full result cannot be attributed to play alone.
2. Holding demonstrations, the future model, and optimizer-update count fixed, adding the full play pool raises success by 15–45 percentage points.
3. Naive data mixture is not enough. The play-augmented ImplicitRDP and Cosmos Policy variants perform worse than their task-only versions in all four conditions.

The third point is the most transferable. Play actions are intentionally not optimized for the task instruction. Training one model to imitate them alongside successful actions can shift its distribution away from task completion. ForceWAM lets play supervise the local mapping from intended consequence to action while reserving goal prediction for successful demonstrations.

A 45-point gain is not a data-efficiency claim

The play-scaling experiment keeps 200 demonstrations per task family and adds 0, 50, 100, 150, or 200 play episodes. It shows the marginal value of play inside this architecture; it does not show that 200 play episodes can replace 200 demonstrations, that play costs less to collect, or that the same gain appears on a new robot.

The intermediate subsets are sampled independently rather than nested, so the curve combines quantity with which episodes happened to be selected. Twenty evaluation trials make a five-point step equal to one additional success. The large gains are still meaningful, but small differences should not be over-interpreted.

There is also a release boundary. As reviewed on 15 October 2026, the project page provides the paper, figures, and extensive first-party videos, but labels code as “coming soon” and does not link a downloadable task-and-play dataset. An external team can inspect the method and results but cannot yet reproduce the full training pipeline from the linked artifacts.

What this changes for humanoid data collection

ForceWAM is an arm-manipulation study, not a humanoid experiment. It does not test floating-base dynamics, changing foot contacts, whole-body collision, balance recovery, or an embodiment transfer. Its value for humanoid data is therefore architectural and procedural rather than a direct performance claim.

A humanoid play corpus would need more than wrist video and one tool wrench. Depending on the task, it may need synchronized joint state, commands, estimated or measured torque, hand contact, foot contact, base motion, inertial sensing, external loads, safety stops, and operator intervention. The collection team should preserve:

• whether an episode is a successful task demonstration, exploratory play, recovery, or failed deployment;
• the task instruction when one exists, without inventing one for play;
• raw and compensated force–torque streams, sensor frame, reference point, calibration, filtering, saturation, and timestamps;
• the action actually sent, the measured state that followed, and the controller version that connected them;
• episode lineage so windows from one interaction are not counted as independent tasks;
• safety stops and human interventions, because excluding them changes the meaning of reported success.

This extends the site's data-collection gripper comparison: sensing force is only the first step. The learning design must decide whether that force is an observation, a prediction target, a task criterion, or part of the action-response supervision. A six-axis stream can serve several of those roles, but not if its timing and provenance have been stripped away.

The practical lesson is about assigning evidence

ForceWAM does not establish that unstructured exploration is universally better than expert data. It shows something more useful: a successful trajectory and an exploratory contact transition answer different questions.

The successful trajectory says which future is compatible with the goal. The play transition says which action produced a local visual and force response. The live sensor says what contact is happening now. When the model preserves those roles, off-task experience can improve task execution without being treated as a task demonstration.

That is the data-design lesson to carry into humanoids. Collect broader interaction experience, but keep its intent, action, consequence, sensor frame, and evaluation status explicit. More data helps only after the training objective knows what each record is evidence for.