Slip Is the Failure Mode Nobody Trains For

When a robot deployed in a real environment fails at a manipulation task, what usually happens is not that it fails to reach the object or fails to close on it. What usually happens is that it grasped the object, began to move, and lost it. Ask any team that has run policies outside a lab and this pattern will be immediately familiar. Ask any team that has published a benchmark and it will be nearly absent.

Anyone with a fleet of deployed manipulators has telemetry, and the telemetry tells a consistent story. The dominant failure category in real deployments is post-grasp loss, slip, drop, or unintended release during transport. Depending on the environment it ranges from forty to seventy percent of all recorded manipulation failures. Reach failures and closure failures, the categories benchmarks focus on, are a distant second and third.

The mismatch between what fails in the field and what benchmarks measure is not new to robotics or to AI generally. But its specific shape in manipulation is unusually stark because the missing category has a clean physical definition and a clean sensor to detect it, and yet almost none of the standard training data contains that sensor's output.

Two overlapping reasons. First, most collection rigs do not capture force at rates that resolve slip. A grip that begins to slip and is corrected in three hundred milliseconds is invisible at ten hertz. It is barely visible at thirty. It is legible only above about one hundred, and above about three hundred it is diagnostic. Datasets sampling at ten to thirty hertz cannot label slip because they cannot see it.

Second, even when force is captured, slip is rarely labeled. Annotation pipelines optimize for the labels that show up in benchmarks, and benchmarks reward success. The intermediate events, micro-slips that were caught, near-misses that were saved by an operator correction, are the training signal that would make a policy resilient, and they are exactly the events that go into datasets as unmarked frames.

The consequence is that a policy trained on the standard mix has no way to learn what a save looks like, because the corpus does not tell it that saves happened.

A pose-and-vision policy handling a fragile or slippery object under varying conditions is doing something specific: it is executing an open-loop plan, informed by camera frames, hoping that the friction cone at the contact will remain large enough. When it does not, the policy has neither the sensor to detect the excursion nor the learned behavior to correct it. The object is lost.

Increasing the model size does not fix this. Adding cameras does not fix this. The missing capability is not perception or planning in the usual sense; it is closed-loop force behavior in the first several hundred milliseconds after contact, and it can only be learned from data that contains those events labeled as such.

This is the specific reason that policies posting strong benchmark numbers under-perform when deployed. The benchmarks and the deployment are asking different questions, and the training data has answered the benchmark question.

Two things. Capture rigs used to build production training data have to sample force at rates that resolve slip. This is a hardware choice and it is not optional for the class of task most deployments actually run. Second, the labeling and slicing conventions used to construct training curricula have to promote slip events and their corrections to first-class training examples, weighted appropriately given their real-world frequency and impact.

None of this requires new science. It requires alignment between what capture rigs record and what deployments fail on. The dataset side of that alignment is the one BLO LAB was built for, and the next piece describes what a slip-labeled corpus of real human work actually looks like.