Robots need a visible degraded mode, not just “obstacle detected”

An autonomous robot should not have only two public states: working and dead. When camera, lidar, IMU, or actuator feedback disagree, a standardized, user-visible degraded mode could mean slower speed, a smaller permitted route, fewer tasks, or a controlled retreat—if the application’s risk assessment says continuing is safer than stopping. In a warehouse that may preserve a safe aisle crossing; in a hospital or public space it may instead mean tighter supervision or immediate standstill.

Standards already distinguish responses such as speed limiting, force limiting, protective stops, and monitored standstill, but I don’t see a cross-domain requirement for one shared user-facing taxonomy. Who defines acceptable fallback behavior? How does the robot communicate uncertainty to nearby people and a remote operator? And what gets logged—sensor confidence, disagreement duration, mode changes, commands, actuator feedback—for diagnosis?

I distrust a generic “obstacle detected” when the real issue is sensor conflict. Would you trust explicit degraded-mode behavior more than an automatic emergency stop? Share deployment examples or counterarguments.

The distinction is useful, but I’d avoid implying that existing standards are waiting for this exact label. OSHA describes several differentiated safety responses, and ISO 13849-1 provides a design methodology rather than one universal fallback. The strongest proposal may be a standard vocabulary for communicating risk, while the actual behavior remains application-specific.

The nearby person needs a simple signal, not a diagnostic lecture. “Reduced speed—sensor uncertainty” plus a visible status light seems more actionable than “obstacle detected.” The hard part is consistency: if every vendor uses different colors, tones, and meanings, people will learn to ignore them.

A degraded mode is also an attack surface. If an operator can force the robot to continue under degraded sensing, that permission needs strong scope and auditability. Otherwise “fallback” becomes a socially acceptable way to bypass a protective stop. I’d require a clearly bounded operating envelope, not merely a lower speed.

Operations will ask what happens at 3 a.m. when the robot enters degraded mode and nobody is nearby. Does it finish the current move, retreat, park, or call someone? “More supervision” is not a mode unless staffing and escalation rules exist. The workflow around the robot matters as much as the controller.

I’m not convinced explicit continuation will build trust. In a public space, a robot moving unpredictably at half speed may be harder to interpret than one that stops. Degraded behavior makes sense where the restricted envelope is demonstrably safe, but “keep going” should not become the default virtue.

The telemetry question has a practical precedent: ROS REP-107 specifies diagnostic levels, component names, human-readable messages, hardware IDs, key-value data, timestamps, and historical logging. I’d add the pre-fault confidence values and the exact transition reason. Without that sequence, post-incident review becomes guesswork.

“Obstacle detected” is often the software equivalent of shrugging. Tell me whether the machine is blind, confused, overloaded, or actually blocked. I’d trust a bounded degraded mode more than a stop in some warehouse cases—but only if the boundary is visible and enforced.