Safety, Emergency Stop and Who May Command the Robot¶
Three questions, and they belong on one page because the answers depend on each other: what stops a robot, what happens after it has been stopped, and who is allowed to make it move in the first place.
1. The emergency stop¶
Every chassis of the uLog and uServe ranges carries a physical emergency stop. It is wired into the drive, not into our software, and nothing on this platform can override it. That is the property everything else is built around: the last word belongs to a mechanical switch within arm's reach.
| Property | Value | Evidence |
|---|---|---|
| Behaviour after release | manual_release_safe — releasing the button does not resume motion; a person has to acknowledge |
MEASURED GET /device/info |
| Readable from software | Yes, as part of the chassis state | MEASURED |
| Shown in the operator surface | Yes, on the technician page, as free or pressed | MEASURED |
The consequence for anyone building on this platform: a robot that has been stopped is not a robot that is about to continue. Do not design a flow that assumes it will.
2. The software stop¶
Separately from the physical button there is a stop in the surface, and it is deliberately the one control that requires no sign-in.
Whoever stands next to a moving robot and wants it stopped does not have a password with them, and must not need one. A stop button that first asks who you are is not a stop button.
Stopping also empties the queue. Somebody who stops a robot wants a standing robot, not one that starts the next job three seconds later.
3. Who may command the robot — the rule, and where we stand¶
The rule: one writer. Exactly one component in a deployment issues movement commands to a chassis. Everything else — tours, call buttons, level change, voice — submits an intent to that component and lets it decide. Readers keep their direct connections, because telemetry updates several times a second and must not take a detour; only the write is centralised.
The reason is not tidiness. A chassis of this class accepts a new movement command by superseding the one currently running, silently, with no queue and no notion of an owner. Two components that both mean well will therefore interrupt each other, and the robot will do the last thing it was told rather than the right thing.
Where we stand, honestly: more than one of our own components writes movement commands today, and consolidating them onto a single writer is in progress across the group. Until that is finished, two rules apply at every site, and they are commissioning rules, not software:
- Never dispatch two robots to the same destination by hand at the same time. The fleet layer arbitrates the destinations it knows about; a manual command does not pass through it.
- A person who is driving a robot from the technician page owns it for that moment. Nobody else starts a tour on the same robot meanwhile.
4. What the robots do not do for each other¶
A property worth knowing before designing around it: two robots of this class do not reliably avoid one another on a map that was imported through the interface. The vendor's own mutual-awareness feature learns its map through the vendor cloud; a map that arrived through the API is invisible to it. This was measured, not assumed, and it means the fallback most people expect does not exist on premise.
What does exist is our own fleet layer: each robot broadcasts a heartbeat every two seconds on the local network, signed with a per-site key, carrying its position, its map and what it currently occupies. Robots claim destinations, chargers and narrow passages through it, and they release them again. It is described under Fleet.
Two honest limits of that layer:
- It arbitrates destinations and resources, not geometry. It keeps two robots from wanting the same charger; it does not steer one around the other in a corridor.
- It only sees what goes through it. A movement command issued outside it is invisible to it — which is the same sentence as rule 1 above, seen from the other side.
5. What a site gets in writing¶
The robot has a mechanical emergency stop that software cannot override; after releasing it, a person has to acknowledge before it moves again. It can be stopped from its own screen without a password. It does not accept movement commands from the cloud — not from a valid connection with a valid certificate either; from that direction it accepts a software release and a stop, and discards everything else. If your network is down, it keeps working.
6. Open¶
| Question | State |
|---|---|
| Consolidation onto a single writer | In progress across the group |
| Geometric right of way between two robots without a network | Designed, not built. It depends on both sides computing precedence identically and on a shared name for each floor |
| Whether the fleet heartbeat survives a hospital WLAN | OPEN — measured so far only between processes on one host |