Computer vision that survives a real production line

What this actually solves

A person cannot look at a moving line all day and stay accurate. They start the shift careful and end it tired, and the errors cluster in the last two hours. That is not a training problem or a discipline problem; it is what sustained visual attention does to anybody. So the checking either gets sampled — one carton in twenty, one part in fifty — or it gets done properly and slowly, and the line waits.

The cost of the gap is rarely the individual defect. It is the consignment that comes back because a batch of seals did not close properly, the stock count that disagrees with the system so badly that someone spends a weekend recounting a warehouse, the shelf that sat empty through the busiest four hours of the week because nobody walked past it. A camera that looks at every unit rather than every twentieth unit is not slightly better than a person. It is a different kind of coverage, and it produces a record of what it saw, which is often worth as much as the catch itself.

The honest framing is that this is a physical engineering project with a model in the middle of it. Lighting changes through the day. A camera mount picks up vibration from a motor. Dust settles on a lens over a fortnight and the confidence scores drift downward without anything in the software having changed. Any proposal that treats this as a pure software build is describing a demo, not an installation.

How the work runs

1. Define the decision and measure the humans. What exactly is being detected, what happens when it is detected, and how accurate is the current manual process — measured, not estimated. Without that baseline there is nothing to judge the system against, and "is it good enough" becomes an argument instead of a comparison. One to two weeks.
2. Camera, lens, mounting and lighting. Position, field of view, shutter speed against line speed, and controlled lighting so the same part looks the same at 9am and 9pm. This stage is the one most often skipped, and it is the one that determines how much data the model will need afterwards. One to three weeks.
3. Collect and label a representative dataset. Thousands of images from the installed cameras, deliberately covering the awkward cases — partial defects, overlapping units, the variant that only runs on Thursdays. Every image is annotated by hand. This is the longest and least glamorous phase, and rushing it is the single most reliable way to produce a system that works in the lab and fails on the floor. Three to eight weeks.
4. Train, tune and evaluate against held-out data. YOLO-family detectors for most detection and counting work, managed through Roboflow, with OpenCV handling the pre-processing. Evaluation is per-class and reports false negatives separately from false positives, because on an inspection line those two errors have very different costs. Two to four weeks.
5. Deploy to edge hardware and test on the live line. Inference running next to the line rather than in a cloud region, integrated with whatever acts on the result — a reject arm, a dashboard, an alert. Then a run against real production long enough to see a shift change, a batch change and a bad-light hour. Two to four weeks.
6. Monitoring and a retraining route. Confidence distribution tracked over time so gradual degradation shows up as a trend rather than as a complaint, plus the documented path for adding a new product variant. About a week.

What moves the price

The range is $3,000–$40,000 over 2–5 months, and three things decide where a particular installation lands in it.

Whether labelled data already exists. This is the dominant factor by a distance. If you have an annotated archive from your own cameras you are at one end of the range; if you are starting from zero, a data collection and annotation programme sits inside the same project, and that shifts both cost and timeline substantially.

Whether hardware is in scope. Cameras, lenses, lighting rigs, mounts and edge devices are a separate class of work from the model, and specifying and commissioning them is real engineering time. Sites that already have suitable machine vision cameras installed skip a large piece of this.

Real-time versus batch, and how strict the tolerance is. Inspecting at line speed with a hard latency ceiling is a different build from analysing footage overnight. And the accuracy requirement compounds it: the last half percent is not a rounding adjustment on the quote, it is a second phase of work on the hardest examples in the dataset.

What usually goes wrong

The data question is asked last instead of first. Someone agrees a scope, agrees a price, and only then discovers that there are no labelled images at all — which is the common case, not the unusual one. At that point the plan is rebuilt around a collection and annotation effort nobody budgeted for. Ask on the first call how many annotated images exist, from which cameras, and under what lighting.

An accuracy figure is written into the contract without pricing its tail. Ninety-nine percent sounds like a reasonable ask and is often achievable. The trouble starts when the requirement is written as 99.5 or higher, because the remaining cases are the genuinely hard ones — occluded, unusually lit, or borderline even for a human inspector. That is a second project wearing the same name.

A physical fault gets diagnosed as a model fault. Detection rate falls, so the model is retrained, and it falls again a fortnight later. The actual cause is a film on the lens, a mount that has loosened next to a vibrating motor, or a new overhead light someone installed in the corner of the frame. Monitoring the confidence distribution over time is what separates these two situations, and it is why it goes in at deployment rather than after the first mystery.