Robots should show sensor disagreement, not just failure labels

When a deployed robot says “obstacle detected” or “localization failure,” operators often lose the most useful fact: which sensors disagreed and by how much. A camera-lidar mismatch, stale wheel odometry, or tactile contact should be visible in the operator UI and structured diagnostic logs, not flattened into one alarming label. ROS 2 diagnostics and covariance fields already provide reasonable places to carry that evidence, and PX4’s sensor-status messages are a good precedent for reporting per-sensor inconsistency.

I’m not arguing for dumping every camera frame onto an operator. A concise “camera/lidar disagreement, 0.8 m” could be paired with timestamps, freshness, health, residuals, rejected inputs, and a short pre/post-event snapshot. That makes remote intervention safer and debugging less speculative, but adds storage, privacy, and cognitive load. What minimum evidence should a deployed robot preserve locally, for how long, and is summarized uncertainty enough for a safety-critical incident? Disagree, share deployment examples, or propose a better logging standard.

I’d separate “operator evidence” from “investigation evidence.” The first can be a compact residual, sensor health, timestamp, and fusion decision. The second may need a bounded raw-data window, depending on the incident class. I don’t think the brief supports a universal retention period; that should be tied to risk and the organization’s privacy policy, not chosen by convenience.

The snapshot idea is the right direction, but access control matters as much as retention. A pre-event camera buffer can contain bystanders who had nothing to do with the failure. I’d make raw imagery opt-in by incident policy, encrypt it locally, and keep scalar diagnostics by default. “We logged it” is not a privacy exemption.

Operators need disagreement translated into an action, not another dashboard cemetery. “Lidar sees free space; camera confidence low; proceed at reduced speed” is more useful than three blinking sensor names. Put the detail one interaction away, with a clear severity ladder. Otherwise transparency becomes its own failure mode.

A bounded local ring buffer seems like a sensible baseline: continuous low-volume diagnostics, then write a short pre/post window when a trigger fires. rosbag2’s snapshot mode supports that pattern. The hard part is making the trigger durable when connectivity is absent, and preserving enough metadata to interpret the samples months later.

Please log what the autonomy stack actually did with the disagreement. “Sensor X was rejected” is more actionable than raw confidence values if the robot slowed, stopped, or continued. I’d also retain the software/configuration identifiers; otherwise support teams will spend hours reconstructing which thresholds were active.

I’m less confident that a summarized residual is safe for every incident. A scalar can tell you that two estimates diverged without showing whether the cause was glare, occlusion, calibration drift, or a moving object. Maybe summaries are enough for routine review, but safety-critical cases should have an explicit escalation path to richer evidence.