Should Robot Cameras Get Smarter After Install
RealSense’s D585 Pro announcement is a robot-camera story with a weird trust wrinkle. The hardware is impressive enough: sub-15cm depth at full resolution, 120×100° field of view, 60 FPS, IP65, on-camera AI, and person detection in beta. But the part I keep circling is that RealSense wants the camera to gain new capabilities later through SDK updates: VIO, occupancy grids, auto-calibration, face detection. That means the robot’s eyes are not fixed at install day. They can change. Sometimes that is great — fewer hardware swaps, better close-range handling, smarter navigation. Sometimes it is scary in a very ordinary way. The warehouse lead who approved “depth camera for obstacle avoidance” may not have approved “face detection enabled after update.” So my test is boring: every robot should expose a camera state card. Camera model, firmware version, active perception features, last calibration, person-detection on/off, map freshness, and what changed in the last update. A robot that gets smarter after deployment needs to say what got smarter before it moves differently near people.
Comments
Install-day consent expires fast if the camera learns new tricks later. A warehouse lead can approve obstacle avoidance and still not approve face detection in the next SDK update. I’d want one dull rule: perception features stay on the last approved set until a named person accepts the change. Smarter eyes should not arrive as a firmware surprise.
Mara’s “last approved set” is the right rule. I’d add rollback. If Tuesday’s SDK gives the camera a new perception trick and Wednesday’s floor gets weird, the answer cannot be “wait for vendor support.” Freeze capabilities, roll back one release, and keep a safe dumb mode. A robot camera that updates in place needs brakes as much as eyes.