The gap between simulation and the floor

Robots do not fail on the cases you tested. They fail on a pallet wrapped by a different supplier, a cage left in an aisle the map says is clear, a floor still wet from cleaning, and the fact that at 03:00 the light comes from a different direction. None of that is a modelling failure. It is the ordinary gap between a world you specified and a world that does not know it was specified.
Why the gap is structural
A simulator contains what its author thought to include. That is not a criticism; it is the definition. Every simulation is a model, every model is a simplification, and the simplifications get chosen before you know which ones will matter.
The result is a predictable asymmetry. Performance in simulation improves smoothly as you train. Performance on the floor improves in steps, each step corresponding to somebody discovering a category of thing the simulator never contained.
You do not close that gap by building a better simulator, although a better simulator helps. You close it by designing for the case where the world is outside the model — which is a different engineering problem entirely.
The four things that actually go wrong
Perception drift. Lighting, dust, condensation, a new label design, a reflective wrap. The detector was excellent in June and is subtly worse in November, and nothing announced the change.
The map is a claim. Layouts move. A pallet parked in a corridor for two hours does not appear in the site plan, and a machine’s confidence in its own localisation is often highest just before it is wrong.
People do not behave like obstacles. A person will step towards a robot to see what it is doing. Avoidance tuned on things that stay still produces confident behaviour around things that do not.
The long tail is made of ordinary objects. Not adversarial examples. A broom. A dropped glove. Two pallets stacked in a way nobody stacks pallets.
Designing for the world being wrong
The useful shift is to stop treating unexpected states as bugs to be eliminated and start treating them as a category the system must handle by default.
Three habits follow.
Confidence has to be a first-class signal. Not the model’s stated probability, which is poorly calibrated exactly where you need it, but a running comparison between what the machine expected to see and what it saw. Falling agreement should narrow the envelope automatically, before anything hits anything.
Uncertainty resolves towards stopping. In software, ambiguity usually resolves towards “try something”. With mass involved the safe default is the opposite: slow, stop, ask. A robot that pauses is an operational annoyance. A robot that guesses is an incident report.
The envelope carries what the model cannot. A machine structurally incapable of exceeding a force limit does not need to have anticipated the specific object it is pressing against. This is why a harness matters more than another ten points of benchmark score: it converts an open-ended perception problem into a bounded physical one.
The commissioning trap
The most expensive version of this gap is not the first day. It is month four.
The robot works, the team stops watching, and the environment keeps changing: new products, new packaging, a reorganised aisle, a different cleaning schedule. Nobody thinks of any of those as a change to the robot, so nothing gets re-validated. Performance degrades quietly until something makes it loud.
The countermeasure is unglamorous. Log what the machine perceives, decides and refuses. Track refusals over time — a rising refusal rate in one zone is the earliest signal you will get that the world has moved. Replay recorded shifts against the envelope after every change to it. And treat a change in packaging as a change to the system, because it is.
What we are building for
When KyberBot runs a robot, it assumes the simulator was wrong. The harness bounds what the machine may attempt regardless of what the planner believes, the homeostat pulls autonomy back when agreement with the world drops, and the audit trail exists so that month four is diagnosable rather than mysterious. The same assistant that knows you is, in a robot, the one that refuses to guess.
None of that makes a robot smarter. It makes the failures small — which, on a floor with people on it, is the property that actually matters.
- sim-to-real
- deployment
- reliability
- operations