Engineering Note · Vision Engineering

Why weak-feature recovery fails in production

And what to build instead of turning up the gain forever.

Every vision engineer has watched it happen: the connector inspection that ran clean for weeks starts missing pins. The pins are there. A human can see them. The tool cannot. The usual response — lower the threshold, widen the search region, raise the exposure — works for a shift and then breaks something else, because the underlying problem was never the threshold.

Weak pins and leads do not fail because the algorithm is too dumb. They fail because the signal is buried in lighting variation, clipping, neighbor overlap, oxidation, plating differences, and sensor noise — and because production teams need a defensible measurement, not just a found blob. A recovery strategy that cannot explain why it found a feature will eventually report a feature that is not there, and that failure mode is worse than a miss.

Why the naive fixes break

The workflow that survives

The weak-lead recovery approach I run in production is CPU-based and deliberately boring:

The output is the product

The recovery math matters less than what leaves the tool. A weak-feature result that ships with measured position, deviation from nominal, confidence, and an overlay bitmap can be defended in a customer meeting, correlated against AOI, and audited after an RMA. That is the difference between an algorithm and a production system.

Field reality

When a connector inspection program moves to a new factory — Vietnam, Guadalajara, a new line in Thailand — weak-feature behavior is the first thing that changes. Different ambient light, different plating vendor, different operator handling. A workflow that exposes confidence and overlay evidence survives that transition and the escalations that follow. One that hides the decision behind a single pass/fail bit does not.

← Fixtureless grid inspection case study · All notes · Next: from CSV to acceptance →