Should force/torque saturation always stop a warehouse robot?

My default for a warehouse manipulator is to stop when a force/torque channel saturates during a grasp, but I’m not convinced “stop forever until a technician arrives” is always the right policy. Saturation means the sensor or acquisition hardware is outside its calibrated range; that is loss of a trustworthy measurement, not merely a wider error bar. It could be excessive contact, an overload, or an electrical/health fault, and the controller cannot safely infer which from the saturated value alone.

A bounded recovery mode might be reasonable in a risk-assessed cell: slower motion, an independently constrained retreat, redundant sensing, and explicit human confirmation before normal operation. Otherwise, preserve state and request inspection. Unnecessary stops are expensive, but a generic fault code makes diagnosis and judgment worse. Operators should see “measurement saturated,” “overload risk,” and “health fault” distinctly. Where would people who have built or maintained real robots set that boundary?

I’d treat saturation as a trust-boundary failure, not a high reading. Once the value is clipped, the controller has lost the evidence needed to distinguish obstruction from sensor trouble. Recovery can exist, but only behind independent limits and a deliberate operator action. Automatic “try again” feels indefensible here.

The operational cost matters more than safety discussions usually admit. A false stop can strand a tote, consume a shift lead’s time, and train people to rush acknowledgements. I like the bounded mode, provided the interface makes it impossible to confuse “recoverable exception” with “measurement unavailable.”

The important distinction is calibration range versus overload capacity. A saturated signal is not automatically a damaged sensor, but it is also not a force estimate you should keep feeding into control logic. Those are separate states and deserve separate labels.

Exact state beats a red triangle every time. “Fault” tells an operator to escalate; “force channel saturated, overload bit clear, protective stop active” tells them what they are deciding about. Better wording may also reduce the temptation to reset blindly.

I’d set the boundary by task phase. During a constrained insertion, stop immediately. During a low-energy grasp retreat with verified position limits, a slow recovery might be acceptable. The same sensor event should not necessarily produce the same action in every part of the workflow.

If the recovery path needs three independent qualifications and a human confirmation, that is probably a stop with a useful recovery procedure, not autonomous recovery. Naming matters less than making the dangerous shortcut unavailable.

I’m wary of treating redundancy as magic. Two sensors can agree because they share wiring, mounting stress, or the same bad assumption. I’d permit bounded retreat only where the motion is safe even if the saturated channel is completely wrong. Otherwise, stop, log the exact state, and inspect.