What you will take away
- Lighting and fixturing decide accuracy more than the model does.
- Defect images are scarce by definition - plan the collection before the build.
- Inference belongs at the edge when the line cannot wait for a round trip.
The problem it solves
Manual visual inspection is inconsistent by nature. Attention degrades over a shift, standards drift between inspectors, and full inspection of every unit is usually too slow, so sampling is used and defects reach customers. A camera does not get tired and applies the same threshold at hour eight as at hour one.
The realistic goal is not zero defects. It is consistent detection of the defect classes that cost the most - the ones that trigger recalls, warranty claims or line stoppages downstream.
Optics and lighting are the actual project
Teams new to vision assume the model is the hard part. In practice, most accuracy comes from controlling what the camera sees: consistent lighting geometry, the right angle for the defect type, fixturing so the part presents the same way every time, and a lens and sensor matched to the smallest feature you must resolve.
A scratch visible only under raking light will never be detected under diffuse light, regardless of model size. Get the imaging right and a modest model performs; get it wrong and no amount of training data compensates.
If a human cannot see the defect in your image, the model will not either. Fix the picture first.
The data problem is defect scarcity
A well-run line produces very few defects, which is the point and also the difficulty: you may need months to gather enough examples of a rare failure. Plan for it rather than discovering it.
- Start capturing images before the model project begins, even without labels.
- Keep and label the physical rejects that already exist in the quality department.
- Use synthetic and augmented examples for rare classes, and validate on real ones only.
- Consider anomaly detection - trained on good units only - where defect classes are open-ended.
Edge inference and the line rate
If the decision has to be made in the time between two parts, inference runs on the line. A round trip to a data centre adds latency you cannot control and a dependency on a network link that will fail during a shift.
The usual architecture is inference at the edge with results, images and model versions synchronised centrally for retraining and reporting. That also keeps the line running when connectivity drops, which is a requirement in most plants rather than a nice-to-have.
The workflow decides adoption
The system must tell an operator what to do, not just produce a score. What does a borderline result mean, who reviews it, how is a disputed rejection recorded, and how does that feedback reach the next training run?
Deployments fail on this more often than on accuracy. If operators cannot correct a wrong call in a way that visibly improves the system, they will route around it - and a bypassed inspection station is an expensive camera pointed at a conveyor.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
