The problem
Stereo depth fails quietly. Point a stereo camera at a blank wall, a window with glare on it, or a repeating pattern, and the matcher doesn’t report an error. It reports a number, and the number is wrong. A drone flying on that number will fly straight into something it believes is five metres away.
Large robots handle this by adding sensors or running a second perception stack in parallel. Neither fits on a 12 g camera and a processor small enough to carry. So the question I’m actually testing is narrower than “make stereo better”:
Can cheap stereo diagnostics separate an unsafe depth estimate from a safe one accurately enough to be worth acting on, inside the compute budget of a micro drone?
What it measures
Every cue comes from data the stereo matcher already produces, so nothing extra has to run on the board:
- How much of the frame has valid disparity at all
- How much the disparity varies across the region being checked
- Whether left-to-right and right-to-left matching agree
- Whether depth edges line up with image edges
- Proxies for blur, glare, and bad lighting
Those get sorted into two failure cases, because they call for different responses. Missing depth is when there isn’t enough usable disparity to say anything — easy to detect, easy to handle. Valid but wrong is the dangerous one: enough disparity to look confident, values that aren’t real. Depending on which fires, the drone slows, re-scans, or stops rather than acting on the estimate.
Results so far
Tested on public stereo datasets. My first runs scored higher than what’s below, until I found the model was reading invalid-disparity regions and image-border artifacts — both of which correlate with error for reasons that have nothing to do with the scene. These are the numbers with those shortcuts removed.
| Signal | AUC |
|---|---|
| Combined model, valid pixels only | 0.890 |
| Disparity variation alone | 0.829 |
| Left-right inconsistency alone | 0.816 |
The two individual cues scoring in the low 0.8s on their own is the part I find most useful — it suggests the signal isn’t coming from one fragile feature.
What this isn’t yet
An AUC of 0.89 means the cues carry real signal. It does not mean the system knows how confident it should be. There’s no calibrated probability behind it and no threshold I’d trust on a drone that’s actually flying. Public datasets also don’t contain the failures I care about most: indoor glare, blank drywall, and motion blur from a camera that’s moving.
Next
Recording a small physical dataset on the stereo camera below — deliberately pointing it at the things that break stereo — then checking whether the simplified gates survive that data and still run fast enough on the Core1106.
