Mobile robots and shared perception

Walk a fulfillment floor at shift change and you will see the same thing happen again and again. A mobile robot approaches a spot where a pallet has been left half in the aisle, slows, considers, and either threads past or sits there waiting for a person. Each robot in the fleet makes that judgment alone, with its own cameras and its own small model, and each one makes it slightly differently.

That is the cost of perception sized to the robot. The model on board is as large as the robot's battery and compute allow, which is smaller than the problem. The usual way around it is to push the hard frames to a vendor's cloud, which is slow, leaves the building, and still gives each vendor's fleet a separate answer. A facility pool takes the other route: one larger perception model, in the building, serving every mobile robot on the floor.

What the robot keeps

A mobile robot is a navigation machine first. Its vendor shipped it with localization, path following, obstacle stops, speed zones, and a safety field around its body. All of that stays on the robot when a site adds a Czar Grid. The pool does not drive. It does not take over the planner or override the safety field.

The on-board model also stays. It handles the fast loop, the reflexes that keep the robot from rolling into a person who steps out from behind a rack. The pool is where the robot sends the questions its own model is not large enough to answer well: what is that object, is it the tote I was sent for, is this aisle actually blocked or just cluttered.

What the pool adds

A Czar in the rack is a pool for a small floor; several joined as a Grid are a pool for the whole facility. Every mobile robot on the floor reaches that pool over the facility's own network and gets perception answers from a model larger than any of them could carry.

Shared perception has a quieter benefit than raw capability. When the whole fleet asks the same model about the same aisle, the fleet gets a consistent answer. The pallet is understood as a pallet by every robot that passes it. A spill is a spill to all of them. The site's automation team no longer tunes a different perception behavior for each vendor's robots and then wonders why they disagree.

Substrate, the serving system on the Grid, holds a latency budget for each robot. A navigation question from a robot moving at speed has a tighter budget than a question from a robot waiting at a staging point. If the pool cannot meet the budget, the robot does not wait; it falls back to its own model or stops. A missed budget costs the fleet an answer, never its footing.

A floor the model has actually seen

Generic perception models are trained on generic warehouses. A real floor has its own lighting, its own floor markings, its own strange totes, and its own habit of leaving stretch wrap in exactly the wrong place. Substrate's adaptation runs on captures from the floor itself, on the pool, with nothing leaving the building. Over time the shared model gets better at this floor in particular, and every mobile robot on it benefits at once.

The captures that train it stay where they were taken. Camera feeds, adapted weights, and the record of what the pool decided remain on the operator's hardware. Whether the rack is air-gapped or connected only to the systems the site already secures is a choice per site, and the mobile robot vendor's fleet software is one of the systems the site can choose to declare.

What the record shows

Every question the fleet asks and every answer the pool gives is on the record. When a robot stopped in an aisle and a supervisor wants to know why, the answer is something a person can read: what the robot saw, what the pool said, whether the robot acted on it or fell back. That is more than most fleets can say today, where a hesitation is a log line on a vendor's cloud if it is anywhere at all.

For how this fits a logistics floor with more than mobile robots on it, see the logistics solution and the article on mixed-vendor fleets on one floor.