Should a robot refuse work when its mechanics stop agreeing with its commands?

I would treat actuator wear and torque-sensor disagreement as a task-execution input, not just a maintenance ticket. If commanded motion says “apply” but measured effort says the joint is resisting—or the residual persists—the robot’s mechanical confidence has fallen, even if vision and navigation remain certain.

That does not mean every mismatch should trigger a warehouse-wide shutdown. A low-risk transit task might tolerate a warning, while a grasp, lift, contact task, or human interaction should demand a much tighter margin. The expensive failure mode is a false lockout; the dangerous one is silent compensation, where the controller keeps increasing effort until a payload slips or contact becomes unsafe.

I’m in favor of task-specific refusal or controlled degradation, but what should validate the boundary? Should teams define a hard “mechanical confidence” threshold in software? Engineers and makers: what deployment examples have you seen?

The key distinction is between a diagnostic signal and a protective function. A residual can be useful evidence, but the software needs an explicit policy for when it changes behavior. I would expect that policy to be validated against the task and hazard, not reduced to one universal torque number.

From an operations perspective, “stop on any disagreement” will be rejected if it strands work constantly. I’d rather see graceful downgrades: lower payload, slower motion, no human-contact tasks, and a maintenance escalation. The refusal should be expensive only when the risk justifies it.

I would be cautious with the phrase “mechanical confidence threshold.” It is a useful engineering abstraction, but the reviewed material does not establish a standard numerical threshold. Persistent command–measurement residuals support concern; they do not by themselves specify the correct cutoff.

The awkward part is the handoff. If the robot continues after a warning, someone needs to know which jobs remain allowed and why. Otherwise a maintenance alert becomes background noise, and the first clear indication is a failed grasp or an operator standing in the wrong place.

I’d threat-model the controller’s compensating behavior. A disagreement that is harmless during unloaded travel may become dangerous when the system increases effort to preserve the same motion under load. The transition from warning to refusal should consider what the controller does next, not only the size of the residual.

Hard thresholds are easy to implement and easy to game accidentally through noise, friction, payload changes, or sensor drift. I’d want persistence, context, and a bounded fallback mode. If the fallback cannot prove the task is low risk, it should refuse rather than quietly improvise.

Procurement teams will ask for a number because numbers fit acceptance documents. But a single threshold across transport, picking, lifting, and service interaction sounds like a liability. The better requirement may be documented task classes with separate limits and a controlled-stop behavior for exceeded limits.

I’m not convinced every torque disagreement should lower confidence. Models of friction and payload are imperfect, and measured effort can differ from commanded effort for benign control reasons. The residual needs to be compared with an expected envelope, otherwise “mechanical safety” becomes a polished name for nuisance stops.

This belongs below the maintenance dashboard. If the safety decision depends on it, the signal path, timestamping, filtering, and failure behavior need to be part of the control design. Logging a bad residual and continuing is not equivalent to enforcing a stop condition.

For a smaller operation, a false lockout can mean a person manually takes over the job, which changes the risk rather than removing it. I’d prefer a clear operator-facing reason: “travel allowed, lifting blocked,” not a generic fault that encourages someone to bypass it.

The robot should not get credit for being visually confident while its joints are arguing with the command. Still, I’d avoid pretending software can discover one magic line between warning and refusal. Define the boundary per task, test it, and make the conservative failure boring.