Stereo depth scale differs between identical cameras: verify and fix

Three identical stereo cameras stand side by side on one robot, all aimed at the same wall, and each returns a different depth. The geometry inside every cloud looks clean: surfaces are flat, corners are sharp, nothing tears. Only the scale is wrong, and it is wrong by a different percentage on each unit. That pairing — clean geometry, per-camera scale offset — is the signature of a calibration fault inside the camera, and it is almost never the URDF, the transforms or the depth settings. This guide gives you the two-distance test that proves it, the arithmetic that separates scale error from disparity noise, and the fix order that works: reload factory calibration, match firmware, recalibrate with the vendor tool, then replace. Worked case: a 5.40 m target read as 5.13, 5.43 and 6.13 m by three same-model units.

Why do three identical stereo cameras disagree on depth?

Each unit computes depth from its own factory calibration — depth equals focal length times baseline, divided by disparity — so a per-unit error in that product shifts every reading by the same percentage; three identical cameras read a 5.40 m target as 5.13, 5.43 and 6.13 m.

The spread was 1.00 m between the outer two, about 18% of the distance, and it appeared in every depth mode the SDK offered, classical and neural alike. That detail matters: the modes run different matching engines, but all of them consume the same rectified images and the same per-serial calibration. A fault that survives a change of depth algorithm sits upstream of the algorithm, in the calibration data. Random matching trouble looks different — edges bleed, thin objects tear, boundaries flicker. Here every surface stayed crisp while the whole cloud sat closer or farther. Consistent offset with clean geometry: read that as calibration, and go measure it.

Is my URDF or the transforms to blame?

No — a URDF origin only translates and rotates the published cloud into the robot frame; it cannot change the ranges the camera reports, so no transform can create a 13% depth offset. Fix transforms for tilt and position; they never fix scale.

Transforms still deserve a check, for a different reason. In the worked case each camera carried a 0.2 rad pitch in its URDF origin, about 11.5°, and the clouds showed a small tilt against each other on top of the scale spread. Get the two numbers separately: read depth in the camera's own frame against a measured target, and check cloud alignment in the robot frame in your TF visualizer. The first tests the camera; the second tests your frames. Frame conventions cause their own failures, worked through in the guide on transforming depth point clouds between the optical frame and camera frame. Note that a visualizer showing every camera frame in the right place validates your transforms and nothing about the camera's metres.

What does a depth error that grows with distance mean?

An error that stays a constant percentage of distance is a scale error: in Z = f·B/d, a 13.5% error in the focal-length-times-baseline product makes every reading 13.5% too long, at 2 m and at 10 m alike. Noise from disparity mismatch behaves differently — it scatters.

f is focal length in pixels, B the baseline in metres, d disparity in pixels, and Δd one pixel of disparity error.

Stereo errors come in two families, and the distance test separates them. Mismatch errors pick the wrong correlation: flying pixels along edges, smeared thin parts, depth that flickers between frames. Estimation errors come from the geometry in the formula: a clean surface carrying a stable offset. Sharp surfaces with a constant percentage is estimation, so the calibration is the suspect. The same percent error at two distances confirms an f·B scale fault; an error growing with the square of distance is quantization, and its cure is a wider baseline or longer focal length, as the guide on long-range stereo depth accuracy with a wide baseline and the one on disparity quantization and height overestimation work through. The chain from disparity to metres is derived step by step in the guide on stereo disparity scale and calibration.

How do you verify each camera against a known distance?

Put a high-contrast marker at a tape-measured distance, record a short capture from each camera and read the marker's depth in every unit: percent error = (measured - true)/true. In the worked case, cones taped out at 5.40 m read 5.13, 5.43 and 6.13 m at the midpoint.

Percent error = (midpoint - 5.40)/5.40: (5.43 - 5.40)/5.40 = +0.6%, (6.13 - 5.40)/5.40 = +13.5%, (5.13 - 5.40)/5.40 = -5.0%. The spread is 6.13 - 5.13 = 1.00 m on a 5.40 m target, about 18%. The second marker kept the same ordering — A 6.32, B 7.13, C 5.80 — and B still read about 12.8% long relative to A there (7.13/6.32 = 1.128). A stable percentage across the scene means a scale fault in B and C; camera A is healthy.

Run the protocol like this:

• Measure with a tape or laser meter. 1 cm of tape error at 5.40 m is 0.19%, far below the faults being hunted.
• Repeat at a second distance, roughly half or double the first. The same percentage at both distances confirms scale; a growing percentage points to quantization instead.
• Keep the cameras on the working mount. The mount cannot change internal scale; manual calibration later follows the tool's own rules.
• If three streams saturate bandwidth, test one camera at a time, as in the guide on three depth cameras dropping to low FPS.

What causes a scale error in one unit but not its twins?

Ranked by how often each turns out to be the cause: stale or corrupted factory calibration data on that serial, a lens module swapped without recalibrating, mismatched SDK or firmware versions across the fleet, mechanical shock that moved a lens, thermal drift — the rarest and smallest.

1. Wrong calibration data on that serial. A stored f·B meant for a different lens variant shifts scale by the ratio of the products, and a spread of -5% to +13.5% between twins is far outside same-line manufacturing variation — that points at data, not mechanics. Reload the per-serial factory file from the vendor tool and re-test.
2. Lens swapped, calibration not. If a unit was serviced or a lens module replaced, the mounted focal length no longer matches the stored one, and depth scales by the ratio. Confirm the history, then recalibrate that unit.
3. Version mismatch across the fleet. Mixed SDK or firmware builds can apply calibration differently from host to host. Put every unit and every host on one version and re-run the two-distance test.
4. Mechanical shift. A knocked lens ring shows up as soft or uneven sharpness across the frame. Judge the image before blaming the numbers.
5. Thermal drift. Aluminium expands about 23 ppm/K, so a 40 K swing moves a 0.12 m baseline by 0.11 mm — 0.09% of scale. Real, but nowhere near a 5% fault.

Which fix should you apply: reload, recalibrate, or replace?

Apply the fixes in that order: reload factory calibration and put every unit on one SDK and firmware version, re-run the two-distance test, then recalibrate with the vendor tool for any unit still off by more than about 2%, and send a unit that still fails to service or replacement.

Treat the factory file as the reference: field calibration is the recovery path, not the default, and it can leave residual error the factory data never had. When you do recalibrate, print the pattern and bond it to a rigid, flat backing, wipe both lenses, and capture the poses the tool requests; redo the capture if the tool's quality score misses its own pass line — one published stereo SDK asks for an RMS under 0.5 and a redo above 1.0.

Read the guide on checkerboard calibration failing at distance before printing, and the one on calibration target capture and stream setup before recording. The pass bar is about 1-2% of true distance at both test distances; vendors of this camera class quote around 1% of distance as near-range accuracy. In the worked case, camera A stays in service at +0.6%; B and C start with a reload; a unit still reading +13.5% after reload and recalibration is a service case, not a settings problem.

When the process needs guaranteed absolute depth rather than relative geometry, change the sensor type: laser profilers report factory-calibrated profiles with a published error budget, and projected structured-light cameras hold an area view that does not rely on scene texture.

How do you keep a multi-camera fleet matched?

Verify every camera on receipt with the two-distance test, log serial against result, keep all units and hosts on one SDK and firmware version, never swap a lens without recalibrating that unit, and re-test after any firmware update or impact.

Ten minutes per unit at incoming inspection catches a 13% outlier before it reaches the robot. Two distances — 2.0 m and 5.0 m work — give every serial a baseline number to compare against after updates. Calibration belongs to the serial: never copy a calibration file between units. In software, address each camera by serial number rather than port order, as the guide on multiple depth cameras on one host shows. Verify scale in the camera's own frame before trusting any robot-frame overlay: the URDF positions the cloud, the calibration makes its metres true. More calibration and frame guides sit on the 3D vision topic page.

If you are specifying a new multi-camera cell or replacing a failed unit, browse the 3D sensors category or the camera finder, lay out the station in the system configurator, or contact us with your layout.