Vision-language-action (VLA) models can learn dexterous manipulation from teleoperated demonstrations, but a policy that has learned a task is not yet a policy that can run unattended on a production line. Two gaps remain: the policy must recover from the failure states it creates for itself, and it must signal reliably when the task is finished so that downstream equipment can take over.
At Nexuni, we are building autonomous robots for a large laundry factory in Singapore, where drying, industrial ironing, and garment folding still depend on manual labor and the goal is continuous 24/7 operation. We post-trained NVIDIA Isaac GR00T 1.7, an open VLA foundation model for generalist robots, on a bimanual towel-handling task and deployed it on hardware that runs the task end to end and hands off to a conveyor. This post covers the two techniques that took the policy from trained to running autonomously in the real world: a DAgger workflow that collects corrections from the policy’s own failures, and a lightweight completion head on the frozen GR00T backbone.
Real-world towel manipulation with GR00T 1.7
The task is towel handling on the factory line (Figure 1). The robot picks up a towel with the right hand, lifts it over the worktable, and releases it. It then grasps both sides with both hands and pulls backward to spread the towel, grasps the two exposed corners, lifts, and places the towel on a conveyor belt.
Towel handling is a useful stress test for a VLA model. The object is deformable, it has no canonical pose, and every episode begins from a different crumple, so the policy cannot succeed by replaying a trajectory. We post-trained GR00T 1.7 using three cameras and a bimanual end-effector action space.
Learning from the policy’s own failures with DAgger
Teleoperated demonstrations only cover the states a skilled operator visits, so they contain almost none of the failure states the policy produces on its own, and collecting more of them does not close that gap. DAgger (dataset aggregation) lets the policy learn from the failure states it actually produces. The policy first executes the task autonomously on the real robot. When it enters a clearly problematic state, a human operator takes over through teleoperation and demonstrates the recovery. That correction is recorded and added to the training data for the next round of post-training (Figure 2).
This matters particularly for deformable-object manipulation. The shape of a towel depends on the entire history of contact that preceded it, so a failure state arranged by hand rarely reproduces the states a policy rollout actually generates. The most valuable correction data comes from the failure states the policy reaches on its own.
The workflow also changed how we collect data. Rather than adding more complete demonstrations, we focus on the failure modes the policy exhibits repeatedly and collect targeted corrections around those states. Each round therefore concentrates new data on the policy’s current weaknesses instead of adding more examples of cases it already handles.
Teaching the policy when the task is complete
Action prediction alone is not enough for automation. The system also needs a reliable indication that the task is complete, so that it can hand off to the conveyor belt without a human watching.
We first evaluated rule-based approaches using robot pose, visual heuristics, and event counts. Intermediate and terminal states in this task are often visually and kinematically similar: the spreading motion and the final lift both hold the towel suspended between two grippers at a similar height, which made fixed rules unreliable in real rollouts. Event-based rules had a related problem. Because the policy retries after a failed grasp, the number of lifts before completion is not fixed. We therefore treated task completion as a learned classification problem.
We added a lightweight auxiliary completion head on top of the frozen GR00T representation (Figure 3). The action head remains unchanged, while the completion head predicts a binary completion signal from the same shared features. In practice this is a small head of roughly 2M parameters that attends over the backbone’s image tokens alongside the state vector, evaluated in the same forward pass the action head already runs.
Three properties made this the right structure:
- The action policy is untouched. A policy server running with the completion head produces identical actions to one running without it; it simply returns one additional output. The action model and the completion signal can be developed independently.
- Inference cost is one small attention block, not a second backbone pass.
- Training takes minutes, not days. With the backbone frozen, the features are constant and can be cached, which turns the completion signal into something we can iterate on quickly rather than a training-run-sized commitment.
Results
Completion head. We evaluated the completion head on 114 held-out episodes, 65 completed and 49 not. Timing error is measured against the labeled completion frame (Table 1).
| Metric | Result |
|---|---|
| Completed episodes triggered | 64 of 65 |
| False triggers on incomplete episodes | 0 of 49 |
| Median trigger timing error | −0.05 s |
The head still has one characterized failure mode on the real robot: it can fire when the towel has been lifted but not fully spread, a state that is visually similar to completion but semantically different.
Full-task behavior. On the real robot, the deployed system runs the full task end to end. The policy takes a towel from the input bin, places it on the work surface, spreads it with both hands, and lifts it by the exposed corners. The completion signal then triggers the handoff and the belt carries the towel away, with no human intervention between consecutive cycles.
Every transfer to the belt is triggered by the completion head rather than by a timer or a fixed motion script. That is the difference between a policy that performs a task and a policy that can be integrated into a production line.
Summary
Real-world policy improvement is not only a model-training problem. It is a continuous iteration across data collection, on-robot rollout, and system integration.
Two practices made the difference on the laundry factory line. First, make each new batch of data respond directly to the problems the policy exposes during real execution, rather than simply pursuing more data. Second, give the policy a way to recognize when a stage is complete, so that it integrates with the surrounding automation equipment and finishes the task more efficiently.