A robot that stops, not one that guesses
The most important design decision in a facility pool is what happens when it does not answer. The answer is that the robot does what it would have done without the pool, which is to stop or to use its own model.
· 4 min read
IN SHORT
When a Czar Grid cannot answer a robot within that robot's latency budget, the robot treats the silence as no answer. It falls back to its on-board model and does what that model can do alone, or it stops under the vendor's own safety logic. There is no mode in which a robot acts on a stale, partial, or missing answer from the pool.
Any system that answers questions for a robot has to be judged by what it does when it cannot answer. A pool that is brilliant when it is up and dangerous when it is late is not a pool a safety officer can approve, and it is not one Element 31 would build. So the fallback is not an edge case in the design. It is the first thing the design had to get right.
The rule is short. A pool that fails leaves a robot that stops, not one that guesses. The rest of this article is what that rule means on the floor.
The budget
Every question a robot sends to a Czar Grid carries a latency budget. The budget belongs to the question, not to the pool. A mobile robot approaching an intersection has a tight budget. A pick arm deciding how to grasp an unfamiliar item has a slightly looser one. A humanoid parsing a spoken instruction while standing still has a looser one again.
Substrate holds these budgets and serves inference across the pool to meet them. When it can, the robot gets an answer from a model far larger than it could carry. When it cannot, the budget expires, and from the robot's point of view no answer came. There is no partial answer, no best-effort guess returned after the deadline, and no state in which the robot is told to wait a little longer.
What the robot does with silence
Silence hands the decision back to the robot's own model, which is where it was before the pool existed. That model is the vendor's. It handles reflexes, basic obstacle stops, and whatever perception the vendor sized it for, and it carries the stops, speed limits, and motion limits the vendor shipped.
Faced with no answer, the robot does one of two things. If its own model can handle the situation, it carries on with what it can do alone. If it cannot, it stops, raises the exception its vendor designed for that case, and waits for a person. Neither behavior was added by the pool. Both were on the floor already, approved as part of the robot the vendor delivered.
This is why fallback is safe rather than merely tolerable. The robot without a pool answer is not a robot in a new and untested state. It is the robot the site already knows.
What the pool is not allowed to do
The rule has a corollary about the pool's own behavior. The pool never answers after the deadline with something the robot might mistake for a timely answer. It does not return a guess to avoid a fallback. A late answer is dropped, not rushed.
The pool also has no way to reach past the fallback. Stops, speed limits, reflexes, and motion limits are on the robot, not on the rack, and the pool does not participate in them. A failing pool cannot command motion because a working pool cannot either. The article on why safety stays on the robot covers the reasoning.
What failure takes away
A pool failure takes capability off the floor. Robots that were recognizing unfamiliar items, threading past clutter, and following spoken instructions go back to doing what their on-board models allow and stopping more often. Throughput falls. Exceptions rise. People are busier.
What it does not take away is safety, because safety was never on the pool. A floor with a failed Grid is a floor running at the level the vendors shipped. That is a worse day than a normal one and an entirely survivable one, which is the most a site can ask of any shared system.
Reading the fallbacks
Because every question, answer, and fallback is on the record, a site does not have to guess about how the pool is performing. The record shows where budgets were missed, which robots fell back, and what they did next. A cluster of fallbacks in one aisle at one time of day points to a network problem; fallbacks on one kind of question point to a model that needs attention.
That record is on the operator's hardware, readable by a person, and it is the right basis for a conversation with Element 31 about sustainment or with the integrator about the network. For how the pool, the network, and the robots fit together, see the technology overview.
Questions this raises
- Does a robot wait for the pool if the answer is slow?
- No. Substrate holds a latency budget per robot, and when the budget passes the robot proceeds as if no answer came. It does not hold position hoping for a late response and it does not act on one that arrives after the deadline.
- What does the floor look like if the whole Grid is down?
- Every robot runs on its on-board model, which handles reflexes and whatever perception it was sized for, and stops where that model is not enough. That is the floor as the vendors shipped it, before the pool was added.
- How does the site know how often fallback is happening?
- Every question, answer, and fallback is on the record kept by Substrate. The site can read where answers were late, which robots fell back, and what they did, and use that to decide whether the pool or the network needs attention.
KEEP READING