Checkerboard calibration fails at distance: depth camera target size

You calibrated a stereo depth camera against a printed checkerboard, and the measurement pipeline behind it works at 60-70 cm. Move the camera out to 1.2 m and corner detection returns nothing, or a pose that twists the output into a diagonal box. Before you touch presets or firmware, measure one thing: how many pixels each checkerboard square spans at the working distance. Below about 15 pixels per square, the standard corner detector becomes unreliable and the whole pose chain breaks with it. This guide gives the formula, works a 25.3 mm board through 0.6 m and the far standoff on a typical stereo module, and shows the three fixes that hold: a larger print with the square size updated in the script, a shorter standoff, or a one-time calibration with stored extrinsics.

The symptom: a sweet spot near half a metre, failure at 1.2 m

The popular open-source multicam box-measure examples assume a printed board lying flat, 25.3 mm squares, and a camera about half a metre above it. At startup each camera finds the board and fits its pose into a shared frame with a Kabsch least-squares fit; the script then measures whatever sits inside that calibrated volume. At 60-70 cm the dimensions come out right. Push the standoff to the far position and the pose stage either finds no board or returns a twisted, diagonal result.

The order of failure tells you where to look. A board that is never found is a detection problem, and at range it is almost always a target-size problem — the depth settings downstream never get the chance to matter. If the board is also missed up close, that is a different fault: start with the checkerboard corner-detection checklist.

The cause: squares that shrink below the pixel limit

Corners are detected on the 2D image — the colour or IR frame — not on the depth map. Double the distance and the frame width doubles, so every square halves in pixels. The classic detector behind most calibration scripts (OpenCV's findChessboardCorners) needs enough pixels per square for its subpixel refinement to lock on: 20 pixels per square is comfortable, and at about 15 pixels it starts missing corners or jittering between frames. Learned detectors in the research literature push the limit lower, but the scripts most teams run inherit the classic 15-20 pixel rule.

Two constraints follow. The squares must be big enough in pixels, and the whole board must stay inside the frame. At the far standoff the frame is more than 2 m wide on a typical wide-angle module, so the frame is never the constraint — the square size is. The depth stream resolution and field of view you set at capture time decide the image width you plug in below.

Sizing the squares for a 25.3 mm board at 0.6 m and 1.2 m

The inputs:

• Square size 25.3 mm — the default the common box-measure scripts declare, in metres, inside the code.
• Image width 1280 pixels, horizontal FOV 87° — typical of short-range stereo depth modules; substitute your stream's values if they differ.
• Standoffs 0.6 m (works) and 1.2 m (fails), from the case above.
• Detector limits: 20 pixels per square comfortable, 15 the floor.

The rule in words: pixels per square equals square size times image width, divided by twice the distance times the tangent of half the horizontal FOV. With tan(87° / 2) = tan(43.5°) = 0.949:

At 0.6 m: frame width = 2 × 0.6 m × 0.949 = 1.139 m. Scale = 1139 mm / 1280 pixels = 0.89 mm per pixel. Square = 25.3 / 0.89 = 28 pixels, comfortably above 20.

At 1.2 m: frame width = 2 × 1.2 m × 0.949 = 2.278 m. Scale = 2278 mm / 1280 pixels = 1.78 mm per pixel. Square = 25.3 / 1.78 = 14 pixels, under the floor — detection dies here.

Maximum standoff for a 25.3 mm square at the 20-pixel target: 25.3 × 1280 / (2 × 20 × 0.949) = 32 384 / 37.96 = 853 mm, about 0.85 m.

Decision: on this module the 25.3 mm board is good to roughly 0.85 m, which is exactly why 60-70 cm worked and the far standoff did not. Holding the longer distance needs squares of 20 × 1.78 = 35.6 mm, so print 40 mm squares and get 40 / 1.78 = 22 pixels per square. The alternatives are a camera at 0.85 m or less, or stored extrinsics (Fix 2).

Test the causes in order

Work down the list; the first test settles most cases.

1. Square size in pixels. Save a frame at the failing distance and measure one square across its middle. Under about 15 pixels confirms the size fault — go to Fix 1.
2. Tilt. Foreshortening scales the squares by the cosine of the tilt angle, so 30° of tilt costs 13% of the pixel width along one axis. Keep the board within about 10° of square-on to the camera, or fold the cosine loss into your sizing.
3. Print and surface. Gloss lamination glares, curled paper bows the grid, and soft focus at range smears the corners. Print matte, glue the sheet to a rigid flat plate, and confirm sharpness at the working distance.
4. Detection stream. If the detector runs on the IR image, the module's own projected pattern sits on top of the print; where the corners look noisy there, capture the calibration pass on the colour stream instead.

Discard any frame where the board is clipped or the corners locked onto the wrong grid — a saved-but-wrong pose is worse than a missing one (when to discard a calibration image). The same measure-first order applies on other platforms too: an IR-guided vision system's standoff-distance calibration mismatch walkthrough works the fault the same way.

Fix 1: reprint the board larger and update the square size in metres

Size the print from the formula. For the case above that means 40 mm squares for the 1.2 m standoff (22 pixels per square), with 36 mm as the absolute minimum. Lay out at least 8 × 6 squares — 320 × 240 mm of board at 40 mm — which still sits well inside the 2.28 m frame width at that distance.

Then update the code. The example scripts declare the square size in metres, and 0.0253 must become 0.040 to match the print. A wrong declared value does not fail loudly: every dimension the script outputs scales by the same ratio, so a 40 mm board declared as 25.3 mm reports lengths at 63% of true size — a 37% error no amount of re-measuring will explain away. When the error looks systematic rather than a detection failure, the grid-pitch mismatch fix covers the declared-size problem in detail.

If your pipeline supports ChArUco boards, they tolerate partial occlusion — but the checker squares obey the same pixel limit, so the print still has to grow (ChArUco board dimensions at distance).

Verify by re-running the pixel count at the working distance, expecting 20 or more per square, then dimension a known box and compare it against calipers.

Fix 2: calibrate once, then load fixed extrinsics

When the camera cannot come closer — it hangs over a conveyor or a cell — stop asking the board to be visible from the working distance. Run the board pass once at the sweet spot, about 0.5 m, where the 25.3 mm board delivers 34 pixels per square and detection is solid. Store the resulting camera-to-world transform and load it at startup instead of detecting live.

That only holds while the camera truly keeps its pose, so the mount becomes part of the design. The LS-MNT-0040 holds a camera on a 700 mm column over a 400 x 450 mm base, and the camera stands range includes slide stages and brackets for permanent cells; the accessories finder filters them by type.

For a single camera the swap is straightforward: the Kabsch fit runs once, its output is frozen, and nothing else in the pipeline changes. For several cameras, remember what the board does in the multicam examples — it hands every camera a pose in one shared frame at startup. Board-less operation then means supplying each camera-to-base transform yourself: practical when every camera is bolted to one rigid frame, fragile when it is not. The extrinsic-accuracy targets article sets the residuals stored calibration should meet, and stereo calibration from paired board images covers the full two-camera pass if you also need intrinsics.

When the usual answer is wrong

Two situations need a different response.

The squares measure 20 pixels or more and detection still fails. The pixel rule is not the fault then — look at motion blur from a long auto-exposure, glare, or focus set for a different range. Magnify the saved frame to 100%: corner junctions should be crisp, not grey smears.

The task genuinely needs 1.5-2 m of standoff with dimensioning. Fighting print size is the wrong tool at both ends there: the squares sink below the pixel floor, and stereo depth noise grows with the square of distance, so doubling the standoff quadruples the depth error. That is the point to change the sensor rather than the target. Structured-light cameras project their own coded pattern onto the scene, so measurement does not depend on a printed board staying in view, and dedicated volume cameras are built around parcel and pallet sizing.

Browse the 3D sensors range or filter the 3D camera finder by type. The palletizing box-sizing guide shows the volume-measurement workflow end to end, and the depth unit and precision settings article explains what the depth stream reports at range.

Prevention: budget the pixels, then freeze the geometry

A calibration that survives the next layout change is mostly bookkeeping:

• Compute pixels per square for the planned standoff before mounting anything; require 20 or more, with the tilt loss included.
• Print 40 mm squares if the standoff could grow past a metre, and write the true square size on the back of the board.
• Keep the declared size in the script equal to the print — one value, in metres, re-checked at every reprint.
• Bolt the camera to a stand or the cell frame, log the standoff, and re-run the fixed-point depth check after any bump. The working-distance and positioning guide walks through standoff choice for the camera itself.
• Keep a golden box: dimension it at commissioning and after any mechanical work, and treat a change beyond your tolerance as a calibration fault.

Set the geometry on the stand configurator once the standoff is decided; the 3D topic page collects the calibration and positioning articles in one place. If the standoff question is really a sensor-selection question, talk to the applications team with your distance, FOV and target tolerance — the sizing is two lines of arithmetic, and we will run them with you.