A new item learned once, not once per vendor
On a floor with robots from several vendors, a new item has to be taught to each vendor's model separately. A shared pool learns it once, on the site's own captures, for every robot on the floor.
· 4 min read
IN SHORT
On a mixed-vendor floor, a new item normally has to be learned separately by each vendor's model, on each vendor's schedule, often after the item's images have left the building. A Czar Grid serves one shared perception model that Substrate adapts on the site's own captures, so the item is learned once, on the pool, and every robot from every vendor benefits at the same time.
A new item lands on the inbound dock in packaging nobody has seen before. Before long it will have been handled by a pick arm from one vendor, carried by a mobile robot from another, and maybe placed by a humanoid from a third. Each of those robots has to recognize it. On most floors, that means the item has to be taught three times, to three models, by three different processes, on three different schedules.
The floor runs at the pace of the slowest one. A facility pool changes the count. The item is learned once.
How it works without a pool
Each vendor's robot carries its own perception model, trained on that vendor's data. When the model meets an item it does not know, the robot raises an exception and a person steps in. The images of the item, if they are kept at all, go to the vendor's cloud. Eventually the vendor trains a new model, and eventually the robot receives it.
Multiply that by the number of vendors on the floor. The pick arm vendor may be quick and the mobile robot vendor slow. The humanoid vendor may want the images sent somewhere the site would rather not send them. The automation team ends up as the coordinator of three learning loops it does not control, and the new item stays a problem far longer than it needs to.
How it works with one
A Czar Grid serves one perception model to every robot in the building, from any vendor. When the item arrives, the first robot to meet it asks the pool. If the pool does not know it either, the robot falls back and a person resolves the exception as before. The difference is what happens next.
That moment on the floor is a capture: the image, the item, the way it was handled. The capture stays on the operator's hardware. Substrate, the serving system on the Grid, can adapt the shared model on captures like it, on the pool, with nothing leaving the building. The adapted weights stay on the rack.
From then on, every robot that asks the pool about that item gets an answer shaped by what the floor learned. The mobile robot that meets it on the aisle, the arm that picks it at the cell, and the humanoid that shelves it all ask the same model and get the same understanding. The learning happened once, and it happened here.
What the vendors keep
None of this touches the vendors' on-board models. Each robot still carries its own model for reflexes and for fallback, and that model is still the vendor's to update on the vendor's schedule. What the pool learned is in the shared model served from the rack, which is the one the robots ask for the hard perception questions.
The vendors also keep their safety envelopes. Stops, speed limits, reflexes, and motion limits stay on each machine as the vendor shipped them. Learning a new item changes what the pool can recognize; it does not change what any robot is allowed to do.
What the record shows
Adaptation on a Grid is not a quiet background process. The record shows which captures went into each adaptation and when, and the evaluation Substrate runs shows how the adapted model performs against the site's own tests. When an engineer asks how the floor came to recognize a particular item, the answer is traceable from the capture through the adaptation to the model now serving the fleet.
That traceability is also what lets a site decide not to learn something. Some items are better handled by a person or routed to a different cell. The site can see what the model has been taught, decide what it should be taught next, and keep both decisions on a record a person can read.
Why once is the right number
The point is not only speed, though a floor that learns an item in one loop instead of three is faster to settle. The point is that the knowledge of this floor's items belongs to this floor. It was captured here, adapted here, and is served from here. No vendor holds it, no vendor's schedule gates it, and no vendor's cloud has a copy.
For the mechanics of adaptation in more depth, see adapting models on the floor's own captures, and for the pick-cell view of the same problem, pick arms and the unfamiliar item.
Questions this raises
- Does the site have to label captures itself?
- The captures come from the floor's own work, including the moments when a person resolves an exception. How much curation a site applies is the site's choice. Adaptation runs on the pool, and what goes into it is on the record.
- Does adapting the shared model change any vendor's on-board model?
- No. Each robot keeps its own on-board model for reflexes and fallback. Adaptation changes the shared model served from the pool, which is the one the robots ask for perception and decisions.
- What if one vendor's robots see the item differently from another's?
- They ask the same adapted model and receive the same understanding of the item, within each robot's latency budget. The vendors' cameras and controllers differ, but the perception answer comes from one place.
KEEP READING