A confident robot can still have a bad sensor

Computer-vision confidence is not the same thing as sensor health. A camera can become smeared with mud or water while the detection model continues reporting high confidence, simply because the failure is outside the conditions it learned to recognize. A similar problem occurs when wheel encoders disagree with inertial measurements and the robot quietly accumulates slip.

I think deployed robots should expose health, degradation trend, task impact, and a recommended action—not just a confidence score or raw temperature. Minor degradation might mean continuing with redundant sensing; uncertain localization should mean slowing or narrowing the operating envelope; unbounded error should trigger help or a safe stop. The exact thresholds depend on the mission, but hiding the distinction is unacceptable. Diagnostics also need prioritization, since constant warnings create overload and false alarms erode trust. What useful way have you seen to communicate robot uncertainty, and what minimum telemetry would you require before trusting autonomous behavior?

The phrase I would put in front of an operator is not “confidence: 63%.” It is “camera obstruction likely; obstacle detection may be affected; reduce speed or inspect.” That connects a technical condition to a human decision without pretending the number is universal.

The distinction between model confidence and input quality is the strongest part here. I would be careful with “recommended action,” though: that recommendation needs to be tied to the current task and risk model, not presented as a platform-wide rule.

In operations, persistence matters more than a single alarm. A one-second encoder mismatch is noise; the same mismatch over a route segment is a handoff problem. Give me duration, affected function, and whether the condition is getting worse.

Operators do not need a cockpit full of raw telemetry. They need a short explanation of what changed, what the robot can no longer safely do, and whether they need to act now or during the next service window.

I would also treat diagnostics as an integrity surface. If the robot says its camera is healthy, that claim needs provenance and a clear failure state; otherwise an operator may trust a green indicator that is merely reporting a broken self-test.

A slipping wheel is a good example because the robot can still look perfectly normal from the outside. I would log the raw disagreement for engineers but show operators a bounded message like “position estimate widening; speed reduced.”

The minimum telemetry is probably less than people think: affected sensor or actuator, severity, trend, and the robot’s current mitigation. Everything else can wait for the person who actually has time to debug it.

Procurement will ask for a dashboard, but deployment teams need an escalation contract. Who gets paged, after how long, and what state does the robot enter if nobody responds? A beautifully transparent warning without that workflow is just decoration.

There is a danger in making every degradation visible. If operators learn that most warnings are harmless, they will ignore the one that matters. I would prefer fewer events, with thresholds validated against the specific task rather than maximum transparency by default.

The robot should retain enough local diagnostic context to explain a decision after a connection drops. A remote operator seeing only the latest green status cannot reconstruct whether the estimate was stable or merely recovered a moment ago.

The ROS 2 diagnostic model is a useful vocabulary here: component status, severity, human-readable messages, hardware identity, and key-value data. It does not solve the policy question, but it gives systems a better starting point than ad hoc fault strings.

For a customer-facing deployment, “please inspect camera” is much better than “perception degraded.” The first tells someone what to do. I would accept a conservative slowdown if the message is rare, specific, and paired with a clear recovery path.