Should robots expose sensor uncertainty before they move?

I deploy mobile robots in places where floors, lighting, and people routinely defeat the lab assumptions. I’m increasingly convinced a robot should expose sensor health and calibration uncertainty before acting, not just emit one polished confidence score. Model confidence answers whether its output resembles familiar patterns; it does not establish that the camera is unobstructed or the pose estimate is trustworthy.

Wheel slip is a good example: encoders can suggest progress while the robot’s actual position and heading drift. A sensible system should detect disagreement with its other measurements, then widen its safety margin or slow down. If localization is materially unreliable, it may need human confirmation—or to refuse the task—rather than confidently improvising.

I’m not arguing for a dashboard nobody reads. I’m asking what should be mandatory at the action boundary. Would you prioritize transparent uncertainty, graceful degradation, or uninterrupted task completion? Real deployment examples and counterarguments welcome.

The distinction seems operationally important, not cosmetic. A sensor can be available yet stale, valid yet poorly calibrated, or internally healthy while disagreeing with the rest of the stack. I’d support exposing those states, but I’d describe this as a proposed engineering requirement rather than implying a universal rule already exists.

A single score is also a poor security boundary. If an attacker, obstruction, or environmental change can make the inputs untrustworthy while the model remains confident, the score hides the failure. I’d want the action policy to consume freshness and cross-sensor consistency, not merely display them to an operator.

The product problem is alert fatigue. If every minor lighting change triggers confirmation, operators will train themselves to click through. The interface needs consequence-based thresholds: keep moving with a larger margin when the task is forgiving, interrupt only when the cost of being wrong is high.

Small precision point: uncertainty in odometry or IMU messages is not the same thing as a sensor-health status. Those answer different questions. That separation is useful precisely because a numerical covariance should not be treated as proof that the underlying sensor is functioning normally.

I’d rather see a boring state machine than a fancy confidence number: normal, degraded, waiting, and minimum-risk. The hard part is defining transitions without making the robot unusable. “Refuse” sounds sensible until the blocked task is moving a cart out of someone’s way.

Human confirmation only works if someone is actually assigned to respond. In a busy operation, “ask a human” can mean a robot sits in an aisle for twenty minutes. Degradation rules need an owner, a timeout, and a safe parking behavior, otherwise the uncertainty policy just moves the failure into workflow.

I’m not sure mandatory exposure belongs at the action boundary in every deployment. For low-consequence routes, uninterrupted completion may be the more reliable system behavior. I’d mandate auditable signals and documented response policies, then let the operator set thresholds according to the task.

There’s a resilience angle here: the robot should retain enough local state to explain why it degraded even if the network is unavailable. A remote dashboard cannot be the only place where calibration validity or sensor freshness exists. Otherwise the robot loses both autonomy and diagnosability during the same outage.

Procurement teams will ask for a field in the interface, but the contract question is what happens afterward. “Uncertainty exposed” is not a control measure unless the vendor specifies when the robot slows, stops, requests approval, or resumes. I’d evaluate those transitions in acceptance testing.

The robot saying “87% confident” while looking through a dirty lens is exactly the sort of progress report that gets people hurt. Give me a plainly named stale-camera warning and conservative behavior. Glamorous telemetry can wait.

Operators need explanations they can act on, not a wall of diagnostic vocabulary. “Camera partly blocked; speed reduced” is more useful than three uncertainty fields with no suggested response. Transparency is a design problem as much as a systems problem.

The implementation trap is assuming the sensors fail independently. Wheel slip, vibration, and lighting changes can arrive together and make the fused estimate look deceptively consistent for a while. I’d log the raw health signals and the decision that followed, otherwise postmortems will be guesswork.