Executive summary
77%
of ML vision-inspection implementations stay stuck at prototype or pilot scale
98%+
detection accuracy on a published gear-inspection system, a clean-signature, high-volume defect
Key conclusions
- Vision inspection pays back when the defect has a stable visual signature that a model can learn. Without one, even a very good model will not pay back.
- Fixed geometry, high continuous volume and a bounded cost of a miss favour vision inspection. Organoleptic defects (judged by smell, taste or feel) and low-mix runs count against it.
- Before scoping the camera, photograph the real defect population, price the false-reject rate and confirm the mounting and lighting on the real line.
A vision project pays back only if the defect produces a clean image that a model can learn, and you can check this before capturing a single frame. Most proposals for automated inspection start with an accuracy figure. The more important question comes first: can a camera at a fixed station, under fixed lighting, reliably see the defect the client wants caught?
On lines where the answer is yes, the case is strong. Gear manufacturing is a clear example. One published machine vision system detects missing teeth, surface irregularities and dimensional deviation on gears in mass production. It reports detection accuracy above 98 percent, with precision and recall both above 96 percent. These defects have a fixed geometry and are inspected from a fixed viewpoint, at a volume that pays for the camera rig within months. Look for this profile before you commit to a build.
Four conditions decide whether vision inspection will pay back
These conditions matter more than any accuracy claim a vendor quotes:
| Condition | Points to vision inspection | Points away from it |
|---|---|---|
| Defect signature | Fixed geometry: missing feature, crack, dimensional deviation, colour or surface break | Organoleptic: off-odour, texture, taste, or a defect defined by feel rather than appearance |
| Product variability | Manufactured part with a consistent 'normal' to compare against | Natural or agricultural product where normal itself varies unit to unit |
| Run volume | High and continuous, amortising the camera rig and the labelling effort behind it | Low-volume or high-mix runs, changing over before the model has seen enough examples |
| Cost of a miss | Bounded and recoverable: a reject, a rework, a returned unit | Severe enough that a probabilistic system needs a human check behind it anyway |
Four checks to make before you scope the camera
- Photograph the full population of actual defects first. Check whether the defects look alike to a person before you assume a model will find them alike.
- Price the false-reject rate as well as the miss rate. A system tuned to catch every defect will also flag good product, and the original business case does not always include that cost.
- Confirm that the mounting and lighting are fixed on the real line. A camera that worked in a trial under even light often fails once it is bolted next to a vibrating motor or a window that lets in daylight.
- Ask what happens when the system meets a defect it has never seen. It will either pass the item to a person as a hard reject or make a guess with a confidence score attached. The second behaviour is the failure mode that costs the most later.
Most vision projects stall because they target the wrong defects
A recent review of machine-learning vision inspection across automotive, aerospace, assembly and general manufacturing found that 77 percent of implementations remain stuck at prototype or pilot scale. That matches what scoping usually finds. Most stalled projects targeted a defect closer to the organoleptic end of the scale, or a run with too little volume to justify the fixture.
With enough labelled examples, a model can learn most defects to some level of accuracy. The commercial question is whether the defect's signature is stable enough, and the volume high enough, for automation to justify its costs. Those costs include changing the line to mount a camera and handling the false rejects the system will produce. This is an engineering and economics question, and the team can answer it during the site walk, before anyone writes code.
