Seven Ways Vision Projects Fail (and How to Avoid Them)

Most vision system integration projects that fail do not fail on algorithms. They fail on definitions, samples, lighting, and part handling, which are decided, or not decided, before the first line of code. Industry veterans routinely estimate that a large share of installed inspection systems end up bypassed, detuned into uselessness, or quietly tolerated at false-reject rates that everyone hates. The encouraging part: the failure modes are few, well known, and preventable, and almost all of them are cheap to fix at kickoff and expensive to fix after commissioning.

Here are the seven we see most, and what avoiding each one looks like in practice.

Why do so many vision projects fail?

Because a vision system is held to a standard no other machine on the floor faces: it automates a judgment, and the judgment was often never actually defined. A CNC gets a drawing with tolerances. A vision system frequently gets "catch the bad ones," a stack of assumptions about what bad means, and a go-live date. The technology then takes the blame for an unresolved quality-management question.

The second structural reason is that vision sits at the intersection of optics, mechanics, controls, software, and quality, and projects run by any single one of those disciplines tend to neglect the others. The camera gets specified beautifully while the fixturing that determines whether the camera sees the same scene twice gets improvised from unistrut in the last week. That is why vision work is fundamentally systems integration work, not device installation.

The seven failure modes

1. Nobody wrote down what a defect is

The project starts with "reject scratches," and month three reveals that quality, production, and the customer each mean something different by scratch. How long, how deep, on which surfaces, visible from what distance? Without a written standard with dimensional limits and boundary samples, the system's threshold becomes a negotiation held over and over at the reject chute. Fix it first: a defect catalog with photographed examples of pass, fail, and borderline for every class, signed by quality, before anyone specs hardware.

2. The sample set was too small and too clean

The system is developed against fifteen pristine parts and two hand-made defects, then meets production, where good parts vary in color, gloss, and mold texture across cavities, suppliers, and seasons. The result is a false-reject storm, and false rejects are what get systems bypassed. Collect production samples across shifts, cavities, lots, and suppliers, and treat ugly-but-good parts as more precious than defects, because they define the boundary the system must respect.

3. Lighting was an afterthought

The camera gets weeks of attention; the light gets whatever bar was in the drawer, mounted wherever it fit. Then the contrast is marginal, and the software team is asked to fix in code what optics failed to capture, which cannot be done. Lighting geometry deserves the first engineering effort of the project, not the last, and the argument for that is laid out in our lighting guide. While you are at it, shroud the station; ambient light that changes with the seasons has undone more deployed systems than any algorithm bug.

4. Part presentation was left to chance

Vision quotes assume the part arrives in a repeatable position, and conveyors are under no obligation to cooperate. Parts rotate, tumble, overlap, and arrive coated in the oil of the upstream process. Every degree of presentation variability becomes either mechanical fixturing, software tolerance, or false rejects, and mechanical repeatability is by far the cheapest of the three. Decide who owns fixturing and part singulation at kickoff, in writing, because this is the gap projects most often fall into between vendor and customer.

5. False rejects weren't in the acceptance criteria

The purchase spec says "detect 100 percent of defects" and says nothing about how many good parts may be failed doing it. Any system can catch every defect if it is allowed to reject a third of production. The catch rate and the false-reject rate are two ends of one threshold, and specifying only one is specifying nothing. Put both numbers in the acceptance test, verify them statistically on a seeded and audited sample run, and budget a tuning phase, because the ROI math dies quickly at production rates when false rejects go unmanaged.

6. The system was proven on a bench, not on the line

Everything worked in the integrator's shop: clean power, still air, one part gently placed by hand. The line adds vibration that blurs images, forklift traffic, washdown humidity, temperature swings that walk the focus, and an operator who needs the guard open. Insist on a runoff at production rate on the production line, over enough hours to meet real variation, before final payment milestones. A system that has only inspected stationary parts in a lab has not yet been tested.

7. No one owned it after handoff

Commissioning ends, the integrator leaves, and the system becomes an orphan. Six months later a light has dimmed, a product tweak shifted the histogram, thresholds got "adjusted" by whoever had the password, and nobody knows what the settings should be. Successful plants name an owner, train them during commissioning rather than after, put spare cameras and lights on the shelf, and version-control the job files and any model weights like the production assets they are. A vision system is a process, and processes need owners.

How to structure a project that survives production

The countermeasures above compress into a sequence. Start with the defect catalog and boundary samples, signed. Run a feasibility study on real production samples, including a lighting study, before committing to full system price; a modest paid feasibility phase is the cheapest insurance in this industry, and it is the model we favor in R&D and prototyping engagements. Specify acceptance criteria with both catch rate and false-reject rate at production rate on the production line. Assign fixturing ownership explicitly. Plan a shadow-mode period where the system records but humans still disposition. Name the post-handoff owner before commissioning starts.

None of this is exotic. It is mostly the discipline of refusing to let unstated assumptions ride along until they become change orders.

A note on vendor demos

A demo on your parts is genuinely useful evidence, and you should still discount it. Demos run on the samples you sent, which were probably your clearest defects, under lighting tuned for an afternoon, with no cycle-time pressure and no conveyor. The questions that predict production success are different ones: what is the expected false-reject rate and how was it estimated, what happens at full line rate, who owns fixturing, what does the changeover procedure look like for the next product variant, and what does support look like in year two? A vendor with crisp answers has shipped systems that lived. A vendor with a beautiful demo and vague answers has shipped demos.

FAQ

What is the most common reason vision systems get bypassed?

False rejects. A system that fails good parts creates immediate, visible pain for production, and the response is predictable: thresholds get loosened until the system catches nothing, or it gets switched off outright. Preventing this means realistic sample sets during development, false-reject limits in the acceptance criteria, and a tuning phase in the schedule.

How many sample parts do I need before starting a vision project?

Enough to represent real variation: parts from multiple shifts, lots, cavities, and suppliers, typically dozens to hundreds of good parts and every confirmed defect example you can find. Cosmetically varied good parts matter most, because they define the false-reject boundary. If defects are rare, start archiving them now, months before the project.

Should vision system acceptance testing happen at the integrator's shop or on my line?

Both, in that order. A shop runoff proves the application logic under controlled conditions; a production runoff at full rate, with real parts and real ambient conditions, proves the system. Tie a meaningful payment milestone to the production runoff, with catch rate and false-reject rate both specified.

Who should be involved in a vision project kickoff?

Quality (owns the defect standard), production (owns rate and operator reality), maintenance (inherits the system), controls engineering (owns the PLC handshake and reject mechanism), and the integrator. Projects scoped by any one of those groups alone tend to discover the others' requirements as change orders.

If you are planning an inspection project and want it to land in the successful minority, the money-saving conversations all happen before the purchase order. Willowark approaches vision and sensing as an integration discipline first, feasibility before commitment, and we are happy to pressure-test your project plan. Contact us.