Visual inspection is one of the most common uses of computer vision in manufacturing. It is also a field where projects fail for reasons that have little to do with the model. Poor lighting, unrepresentative data and unclear acceptance targets cause more trouble than the choice of network architecture. This article outlines the planning steps that should be completed before training begins.
Define the decision and its cost
Start with the decision the system will make. It may accept or reject a part, classify a defect type, measure a dimension or count items. Then write down what a wrong decision costs. A false rejection means a good part is scrapped or reworked. A missed defect may reach a customer, trigger a complaint or create a safety risk. These costs differ between products and customers, and they determine how the system should be tuned.
Optics before models
Image quality sets the upper limit for any model. Camera resolution should be derived from the smallest defect that must be detected, with several pixels across it. Lens choice affects distortion, depth of field and working distance. Lighting often matters most, because the right geometry, such as dark field, bright field or diffuse dome lighting, makes a scratch or a dent visible at all.
Fixtures and enclosures should limit ambient light changes and part vibration. Images should be captured on the real line with the real parts before any model work, so that the team can judge whether the defects are visible to a human reviewing the same images.
Defect classes, labeling and data collection
Defect classes need written definitions with example images and clear boundaries between acceptable and unacceptable. Labeling guidelines should be reviewed by quality staff, and a sample of images should be labeled by more than one person to measure agreement. Disagreement between labelers is often a sign that the definition is not clear enough.
Data should be collected across shifts, operators, material batches, tooling states and seasons, since temperature, humidity and daylight can change the appearance of parts. Defects are rare by nature, so a plan for collecting enough examples is needed, which may include deliberately produced defective samples.
Inference location and latency budget
Inference can run on an edge device next to the camera or on a server connected over the plant network. Edge deployment gives low and predictable latency and keeps working if the network fails. A server simplifies model updates and allows heavier models. The decision follows from the latency budget, which starts at the trigger, includes image capture, transfer, preprocessing, inference and the signal to the line, and must end before the part reaches the rejection point.
Operators, thresholds and line integration
Every model trades false positives against false negatives. The operating threshold should be chosen together with line operators and quality engineers, using the cost analysis from the first step. Operators also know which variations are normal, and involving them early improves both the labels and the acceptance of the system.
The vision system has to communicate with the line. A PLC typically provides the trigger and receives the result, and an MES receives records for traceability. The rejection mechanism, such as an air jet, a pusher or a diverter, must be synchronized with part position. Fail-safe behavior should be defined for camera faults, model errors and lost communication.
Feedback, drift and acceptance criteria
After deployment, operators should be able to flag wrong decisions, and those images should flow back into a review and retraining process. Monitoring should track the rejection rate, score distributions and image statistics, since changes in material, lighting or camera position cause drift. Model versions, data sets and approvals should be recorded as part of normal MLOps practice.
Acceptance criteria should be agreed before training starts. They should state the metrics, such as the missed defect rate and the false rejection rate, the test data set, the conditions of the test and who signs off. With these in place, the project has a clear definition of done.