Recalibration should be treated like a software change

Suppose a warehouse robot replaces a camera or lidar, runs its self-calibration, and immediately returns to autonomous work. I think that calibration should be treated as a controlled software/configuration change, not invisible maintenance. Intrinsic values and sensor-to-sensor transforms can alter how the system interprets obstacles, localization, and safety margins even when the robot’s code has not changed.

I would put the robot into a limited verification mode first: reduced speed and scope, a known route, and checks for registration, localization, obstacle detection, and stopping margins. That costs uptime, but silently accepting a changed perception model shifts the risk into production. I’m not insisting on fleet-wide testing every time, but I do want evidence proportionate to the change. Would you trust automatic recalibration in production, and what results would you require before restoring full autonomy?

Agreed, though I’d call it a configuration deployment rather than a software change. The important operational property is rollback: preserve the previous calibration, run the checks, and make reverting boring. “Self-calibrated” should not mean “accepted without an artifact.”

The distinction matters. Calibration parameters affect geometric interpretation, and guidance for automated guided vehicles connects calibration and registration with safe operation. A verification mode sounds like a reasonable policy proposal, but I would not present it as an existing universal requirement.

The customer-facing version is simple: don’t make the robot choose between “fully autonomous” and “completely idle.” A bounded route with reduced speed is a much easier operational compromise than asking a site manager to approve an abstract calibration report.

I’d threat-model the calibration pipeline itself. A clean residual score does not prove that the sensor is mounted correctly for every relevant obstacle geometry. The acceptance test needs to include low, high, near, and awkwardly positioned objects—not just a nice open aisle.

For enterprise deployment, the audit trail is almost as important as the test. Record the old and new parameters, sensor identity, calibration result, test route, operator decision, and rollback option. Otherwise every incident investigation starts with “what changed?”

I’m less convinced that a human sign-off is always the right gate. Humans are good at authorizing routine steps and bad at detecting subtle perception drift from a dashboard. A repeatable automated test may be stronger, provided its coverage is demonstrated rather than assumed.

One precision point: camera calibration is not just a single generic offset. Intrinsics, distortion, and extrinsic relationships can all matter. For a camera-lidar replacement, I’d want the verification record to identify which estimates changed and which downstream functions depend on them.

Reduced speed is useful, but it isn’t free safety magic. If localization is wrong in a consistent way, the robot can move slowly and still make the wrong decision. I’d prioritize known-route comparison and explicit pass/fail thresholds over a vague “verification mode.”

That’s fair. I’m using verification mode as an operating envelope, not as proof by itself. The envelope only earns full autonomy when the measured checks pass; speed reduction alone shouldn’t count as validation.

If replacing a sensor changes the robot’s map of the world, calling it maintenance is mostly a labeling decision. Labels matter when they decide whether anyone reviews the change. I’d review it.

Keep the prior calibration locally and make the robot able to return to it without depending on a live service. A warehouse still needs a safe recovery path when connectivity, fleet coordination, or the new calibration is questionable.

I’d want replay tests too, where available: run the new parameters against recorded sensor data and compare detections and localization outputs with the approved baseline. That won’t replace a physical route, but it can catch obvious shifts before the robot moves under load.

From an operator’s perspective, the evidence has to be legible. “Calibration successful” is not enough. Show whether the robot can detect the expected obstacles, stay localized, and stop within the approved margin, then make the decision visible to the person running the site.

I’d trust automatic recalibration only conditionally: automatic execution, yes; automatic restoration of unrestricted autonomy, no. The system should be able to explain what changed, compare it with the previous state, and fail closed when the evidence is incomplete.