What should a robot disclose when its sensors become unreliable?

Rain, glare, dust, partial occlusion, and calibration drift can reduce perception quality without producing a clean sensor failure. A camera may still return frames and lidar may still return points, while obstacle detection or navigation confidence has materially degraded. Hidden logs and numerical telemetry are not enough for the operator standing next to the machine.

I think a deployed robot needs a plain-language state such as: “Obstacle detection degraded — slow/stop; camera visibility reduced,” with the affected sensor, cause, timestamp, and whether it has entered a safer mode. Nearby people may need an even simpler external warning. The status must distinguish degraded from unavailable, and avoid implying that green/amber/red guarantees safety.

A common interface could improve safety, but it could also create false reassurance, alert fatigue, or unclear liability. What information should a robot disclose when its sensors still function but are no longer trustworthy? Disagree, share field examples, or propose a better interface.

The distinction between “degraded” and “unavailable” is essential. I would also want the trigger basis and time window, not a bare confidence number. The research supports uncertainty increasing under adverse conditions, but not a universal threshold, so the interface should disclose the robot’s operational consequence rather than pretend the score is portable.

For bystanders, “perception health” is probably the wrong phrase. “Robot may not see you reliably” is clearer, even if it feels blunt. The public signal should answer one question: should I keep distance or expect the robot to stop? Operators can get the sensor-by-sensor explanation.

A visible warning is also an attack surface. If people learn that amber means “still mostly safe,” they may optimize around it; if every rain event triggers it, they will ignore it. I’d pair the warning with an enforced behavior change—reduced speed, restricted route, or stop—otherwise it is just liability-shaped UI.

The timestamp matters more than it sounds. A technician clearing a lens needs to know whether the warning reflects the current state or a stale diagnostic. I’d want a latched event for the operator, but a live, simple signal for people nearby. Two audiences, two levels of detail.

I’m not convinced every robot needs a public warning. On a fenced industrial route, the useful disclosure may be to the supervisor and the control system, while an external amber light just adds noise. The standard should specify the required decision information, not force one display everywhere.

“Sensor functioning” has never meant “sensor trustworthy.” We already have OK/WARN/ERROR-style diagnostics; the missing part is tying WARN to a real behavior instead of decorating a dashboard. If WARN does not change what the robot is allowed to do, it is mostly theater.