Cone detection: stereo vs lidar vs known-size mono camera

You are speccing perception for a formula student driverless car: find the track cones, read their colours, and build a map accurate enough to plan a racing line over several laps. Three sensor options sit on the table — a stereo camera pair, one camera that sizes the known cones, and a camera fused with a lidar. This comparison gives you the numbers that decide it: the depth-error law each option obeys, a worked example with the arithmetic written out, and the integration work each architecture hides. The short answer: stereo wins the ranging job, the single camera holds only to short range, and the lidar fusion pays only after you prove calibration and sync.

The three options at a glance

All three must deliver the same two outputs: a range per cone and a colour class. They differ in how they get the range, how the error grows, and what you must calibrate before the first lap.

The error row comes from the worked example below; substitute your own baseline, focal length and cone height and the same arithmetic returns your numbers.

Why both camera options obey the same error law

Triangulation and size comparison are one measurement in two costumes. Stereo reads the pixel shift of a cone between two cameras separated by baseline b; the single camera reads the cone's apparent pixel height against its known height H. Both convert one angular measurement into range, so both follow the same law:

Here σz is the depth standard deviation in metres, z the range in metres, f the focal length in pixels, σd the disparity error in pixels, δh the pixel error on the apparent cone height, and b and H the two "baselines" in metres. Geometry alone favours the bigger baseline, and the cone's 0.50 m beats a nose bar — but the pixel-error multipliers run the other way: subpixel correlation lands near 0.2 px, while a detection box edge sits 2 px or more off the true tip. A lidar breaks the pattern: each return's range error is roughly constant with distance (centimetre-level for typical time-of-flight ranging), so per-point accuracy holds at the far ranges. What falls with distance is returns per cone, as the fixed angular pitch spreads the spots apart.

Worked example: depth error at 10 m for a 0.2 m stereo pair and a known-size camera

Inputs, each with where it comes from:

• Baseline b = 0.2 m — the rig assumption for this comparison, a practical width for a bar across a formula car nose.
• Focal length f = 1000 px — a 2 MP-class sensor behind a wide lens, roughly an 88° horizontal field of view, chosen to keep the track edges in frame.
• Disparity error σd = 0.2 px — what subpixel block matching delivers on a textured patch.
• Cone height H = 0.50 m — an assumed track-cone height; set it to your rulebook's value and rerun every line below.
• Height error δh = 2 px — how far a detection box edge typically sits from the true cone tip; loose detections run 2-5 px.

The rule in words: range error grows with the square of range and shrinks in proportion to baseline times focal length, or focal length times cone height for the single camera. With z = 10, so z² = 100:

• Stereo: σz = 100 × 0.2 px / (0.2 m × 1000 px) = 20 / 200 m = 0.1 m.
• Single camera: σz = 100 × 2 px / (1000 px × 0.50 m) = 200 / 500 m = 0.4 m.

Both errors scale with z², so the same inputs give:

Decision: take ±0.30 m per cone observation as the mapping target. With these inputs the single camera holds that to about 8-9 m, the 0.2 m stereo pair to about 17 m, and widening the baseline to 0.30 m stretches stereo to about 21 m (σz = z² × 0.2/300). If your sight lines never pass 8 m, the one-camera build is enough; a full autocross map needs the stereo pair.

Option 1 in hardware: two global-shutter GigE cameras on a rigid bar

Two MV-CU020-90GC cameras — 2.5 MP, colour, global shutter, GigE, C-mount on a 1/1.7" sensor — give you the pair the example describes. Mount them on a measured bar with parallel optical axes, set the baseline to 0.2-0.3 m, and trigger both from one pulse so the exposures align within microseconds. A square-wave trigger for five cameras shows the wiring, and global versus rolling shutter for moving targets explains why rolling sensors smear differently frame to frame at speed.

Cones are orange and nearly texture-free, so plain block matching can drop them. Match the textured surround of the cone patch, or run the detector in both views and match bounding boxes — the error then follows the same stereo law with σd nearer 1 px. For the longer-range view of the same trade, see choosing stereo baseline distance and long-range stereo accuracy with a wide baseline. Rig flex and vibration shift depth over a run; the stereo depth jitter troubleshooting guide lists the checks that catch it.

Option 2 in hardware: one camera and the known cone height

One camera, no sync line, half the mass — and the example spends its accuracy by 8-9 m. The MV-CH120-11UC fits the role: 12 MP, colour, global shutter, a 1.1" sensor in C-mount on USB3. At the example's range the cone fills about 50 pixels, so each pixel of box error is worth 0.2 m of range; resolution is what keeps that fraction small.

Three systematic traps to close. Calibrate the focal length in pixels on a checkerboard rather than the lens datasheet: a 1% error there is a 1% range bias, 0.1 m at the example's range. Keep detection boxes tight to the silhouette, because a loose top edge reads as a taller, nearer cone. Reject partially occluded cones, whose clipped height inflates distance. Estimating the pixel scale from field of view and resolution is its own step — estimating depth camera pixel size walks it. Pick the lens so the nearest cone you must classify still clears the map edge, using the focal length calculator:

Option 3 in hardware: camera plus lidar, and what to prove first

Fusion buys centimetre-level geometry per return with colour classes laid on top, plus redundant perception when one sensor degrades — the reason published driverless-system write-ups pair lidar ranging with vision classification. It also adds three costs the camera-only builds do not have:

• Extrinsic calibration. The camera-to-lidar transform drifts as the mounting takes vibration, so plan a target-based calibration you can rerun on the car; what good numbers look like is covered in extrinsic calibration accuracy beyond reprojection error.
• Timestamp sync. A 10 ms offset between sweep and frame displaces fused points 0.2 m at racing speed — twice the stereo pair's whole error in the example. A shared clock such as PTP, or a hardware trigger, is the fix; see PTP timestamp sync for cameras, lidar and IMU and timestamp drift that grows while running.
• Sparse cone returns. At a 0.2° angular pitch, adjacent spots land 35 mm apart at the example's range and twice that at the far edge, so a 0.30 m cone base is a handful of points. Write-ups from earlier driverless cars add that ground-removal filters delete many cone points on top of that, recovered by clustering the cloud before and after the filter.

For the scanner itself — range, point density, interface — the lidar selection and integration notes walk the same trade from the stationary-automation side.

Which option to choose when

• Full lap mapping, coloured cones, a normal parts budget: the stereo pair. A 0.2-0.3 m baseline of global-shutter GigE cameras holds ±0.30 m to roughly 17-21 m, supplies the colour classes from its own frames, and the mapping filter tightens every cone as repeat views land.
• Weight- or power-capped, or sight lines under about 8 m: the single known-size camera. Keep the filter, and accept that far cones enter the map late.
• A lidar already on the car, or dusk and night events: fuse. The camera classifies, the lidar ranges — but only after extrinsic calibration and the clock are proven on the car, not on the bench.

Checks before you order parts

• Measure the baseline after mounting, not from the CAD model: 1 mm of error on 200 mm biases every range by 0.5%, about 0.1 m at the far edge of the map.
• Both cameras global shutter, exposure at or below 1 ms at racing speeds: the image smears two centimetres per millisecond of exposure.
• One trigger line to both cameras, or a shared clock; software starts drift by milliseconds.
• Calibrate the stereo pair at working range, then re-check disparity at 15-20 m; disparity quantization biases height at range describes the far-edge artifact to expect.
• Validate the finished map against taped cone positions before the first timed run; three validation tests for 3D reconstruction gives the procedure.
• For the single-camera build, log box heights against known distances on a test lane before trusting the range output.

Where the usual advice fails

• Short demo tracks. If cones never pass 8 m, the example says the one-camera build already meets ±0.30 m, and a second camera buys range you will not use.
• A lidar already mandated. When the scanner rides for another task, fusion's hardware bill is paid; the remaining work is calibration and the clock.
• Featureless matching. If block matching drops cones in testing, switch to detect-then-match-boxes and treat σd as 1-2 px in the error law — the example table rescales directly.

The build in one line

Run the stereo pair as the primary ranging sensor and take the colour classes from its own frames; add the lidar only when a second task or night running justifies proving the extrinsic and the clock. Pick the pair from the area scan cameras category or the camera finder, start a configured rig at the camera configurator, and browse the 3D sensors category when the project gains a fixed-station depth job. More on mapping sensors sits on the 3D topic page, and the team can put a rig quote together through the contact page.