Catch defects on the production line, before the customer does

At a glance

For	Manufacturers with high-volume lines and visible-defect risk, furniture, textiles, electronics, auto components, packaging, FMCG
The pain	Defects escape to the customer; manual inspection is slow, fatigue-prone, inconsistent; sampling misses systematic defects until complaints surface weeks later
What you get	typically 88-95% detection accuracy on visually-distinct defects, 40-70% fewer customer-facing defect incidents, 50-80% less manual QA inspection time, and a documented per-unit quality record
Start small	Low-risk MVP from €50k, live in 4-8 weeks as a data-collection rig with humans in the loop. It is a small first step, with no full-automation commitment up front
Proof	In pilot for mattress QC (a mattress manufacturer, two-camera ROS rig) and industrial drilling-safety video analytics. The architecture matches our cargo inspection and ECOBOT production work

The wedge: most CV-inspection projects die on the bootstrap problem. You need a working system to collect data, and data to build a working system. We invert it: the rig ships first as a data-collection tool, and ML inference layers on as the dataset matures. Month one delivers a working pipeline. Production-grade accuracy comes from continuous retraining over the first year. You commit to a small, useful first step, and the rest follows the data.

Discuss a pilot

---

The Problem

Manufacturing quality control sits between two bad options. Manual inspection, a QA operator visually checking every unit on the line, is slow, fatigue-prone, and inconsistent. Sampling, checking 1 in N, misses systematic defects until customer complaints surface them, often weeks later.

Defect detection by computer vision has been promised for two decades. The reason it hasn’t displaced manual QA in many factories is the bootstrap problem: you need a working CV system to start collecting data, and you need data to build a working CV system. Vendor demos use cherry-picked defect examples and a clean lab. Production lines have lighting that changes, camera positions that shift, product variants that proliferate, and defect types nobody anticipated.

Our approach inverts the typical project shape: deploy the rig first as a data-collection system with humans in the loop, then layer ML inference on top as the dataset matures. The first month delivers a working data pipeline; the third month delivers initial automated inspection on the simplest defects; production accuracy comes from continuous retraining over the project’s first year.

What the Solution Does

A two-stage inspection rig: cameras over the production line, ROS-based control, and a continuous retraining pipeline.

1. Trigger, a side-mounted camera reads the product ID (barcode, DataMatrix, etc.) as the unit passes. Optional: trigger from your existing line controllers.
2. Capture, two overhead cameras (top and angled, typically) photograph the unit from above and at 45°.
3. Analyze, CV models detect visible defects in each image: stitching errors, surface damage, contamination, dimensional mismatches.
4. Display and log, an on-line screen shows detection results in real time. All images and classifications get logged to the data warehouse.
5. Continuous retraining, moderators annotate edge cases via Label Studio; Datapipe handles incremental retraining; new model versions auto-deploy.

Where It Fits

This makes sense if you…

• Operate a production line with > 1,000 units / shift and visible defect risk
• See real cost from customer complaints, returns, or recall events on quality issues
• Have a line layout that can accommodate camera mounting (most do; some don’t)
• Are willing to start with a “data collection plus first defects” MVP, where full automation comes later in the project
• Have a QA team that will work alongside the system during the bootstrap phase

This is probably not the right time if you…

• Inspect for defects that are invisible to cameras (internal cracks, internal voids, chemical composition issues, those need other sensors)
• Have a line so high-speed that even fast inference can’t process every unit
• Produce highly varied products with no consistent inspection geometry (changing fixtures every week, possible, but each new product needs setup work)
• Cannot integrate with line control systems for triggering, manual triggers are possible but reduce coverage

Business Value

Customer-defect reduction. Visible defects caught on the line don’t reach the customer. Customer-facing defect incidents typically fall 40-70% once the model matures, which takes 2-6 months depending on defect type complexity.

QA labor reallocation. The QA team shifts from inspecting every unit to handling exceptions and reviewing the model’s confidence boundary. Inspector time typically drops 50-80%.

Documented quality data. Every unit has an inspection record linked to its ID. This is documentation you can hand to customers, regulators, or auditors. Some industries (medical devices, automotive, aerospace) require it; others find the data useful for root-cause analysis even without regulatory pressure.

The bootstrap data asset. The biggest long-term value is the labeled dataset, more than the immediate automation. Six months in, you have tens of thousands of annotated defect examples. That is what makes future model improvements possible, and what makes adjacent CV deployments (new lines, new products, new defect types) much faster.

How It Works

The architecture below is what we proposed for a mattress manufacturer (mattress quality control) and adapted for industrial drilling-process video analytics. The same pattern applies across manufacturing verticals.

1. The rig

Two cameras: one directly overhead, one at 45° from the side. Cameras connect to a single-board computer (Jetson Orin or Raspberry Pi) running ROS 2. A third small camera handles barcode or DataMatrix reading from the side, triggering the inspection capture. Optionally, an on-line monitor displays detection results in real time.

When the side camera sees a code, it sends a signal to the central ROS node, which triggers synchronized capture from the two inspection cameras. The images go to a CV inference node and to a storage node (uploading to the data warehouse for later annotation).

2. The MVP, data-collection mode

In the first month, the system operates as a data-collection rig: every unit gets photographed, every photo gets stored. Moderators annotate via Label Studio, defining the initial defect class taxonomy (start simple: “stripes”, “missing stitching”, “dirt”).

3. The first model

After several weeks of annotated data accumulation, the first defect-detection model trains. We use YOLO-family detection (v5, v7, or v8 depending on license requirements). Initial accuracy on simple defects (visible stains, clear stitching errors) reaches around 85-90% quickly. Harder defects take longer.

4. The continuous-improvement loop

The pipeline runs as a Datapipe-orchestrated cycle: collect data, then moderate, then retrain when enough new labelled data exists, then recompute validation metrics, then register the new model, then optionally auto-deploy after passing automated tests and human approval.

The continuity is real: because the rig runs during normal production, you keep getting new examples of new conditions. The dataset grows daily. Even without ML or DE specialists in the room, your annotation effort accumulates and the models get progressively better over time.

5. ERP and line-control integration

Inspection records ship to your ERP or MES via API. Defects can trigger reject signals to downstream divert systems if your line supports it. PDF inspection reports get generated for compliance and customer-side documentation.

Stack

Python end-to-end (including ROS 2 nodes). Docker containers (cloud or k8s). YOLOv5, v7, or v8 for detection. Datapipe for orchestration. Label Studio for annotation. Metabase for metrics. S3 or MinIO for object storage. PostgreSQL for metadata. Edge runs on Jetson Orin or Xavier. Cloud runs on AWS, GCP, or on-prem k8s.

What You Need to Make This Work

Data. None at the start: the MVP collects it. By month 2-3, you’ll have thousands of annotated examples. Initial moderation effort is 10-20 hours per week for the first month, dropping after.

Integrations. A line trigger signal, or a stable barcode or DataMatrix on units for code-triggered capture. An ERP or MES API for inspection record export. Network access from the line to wherever your data warehouse lives.

Hardware. Two industrial cameras and an ID-reader camera, one or two Jetson Orin units per line, a monitor for on-line display, plus network and power infrastructure. We spec everything during the test phase.

Team. A QA or production-ops lead who co-designs the defect taxonomy. Moderators for annotation (yours or ours). A production-IT contact for ERP integration. A line manager who supports the rig installation logistics.

Implementation Roadmap

1. MVP / Test (4-8 weeks)

Install the rig at one inspection point. Configure ROS, code-triggered capture, and data flow to the warehouse. Wire up annotation in Label Studio. Train the first model on the simplest defect class (typically pure surface contamination, the easiest to recognize). Output: a working rig in data-collection mode, a first model, and measured baseline accuracy.

2. Pilot (3-5 months)

Expand the defect taxonomy. Tune confidence thresholds with the QA team. Wire up real-time on-line alerts. Build the analytics layer for defect-pattern reporting. Begin shifting the QA workflow from “inspect every unit” to “handle exceptions”. Output: a working production deployment, dashboards for QA leads, and documented accuracy per defect type.

3. Production (6-12 months)

Add inspection points and defect types. Quarterly model review. By the end, your team owns day-to-day work, and we stay on for retraining oversight and new product or new defect onboarding.

Keep in Mind

Limits:

• Month one isn’t real automation. It is data collection. If you need immediate automated rejection, the first weeks won’t deliver it. The bootstrap shape of the project is deliberate.
• New defect types cost weeks. Adding “torn stitching” after the model knows “missed stitching” is a 2-4 week cycle: collect examples, annotate, retrain, validate. Plan a defect-coverage roadmap, since same-day additions are not realistic.
• Camera positioning matters more than people expect. Glare, shadow, and lens dirt all degrade accuracy. Quarterly camera maintenance is real ops work.
• Product variants need separate handling. A model trained on Variant A may not generalize to Variant B without fine-tuning. The line-layout decision matters: one rig per product variant, or one variable rig per product.
• ROS-based triggering holds up well but stays rigid. It works very well for stable production lines. For lines that change layout monthly, the setup time becomes a real overhead.
• The model will miss novel defect types. A defect class the model has never seen will pass through. Continuous QA monitoring of the model’s outputs, and tagging the missed cases, is how the dataset grows.

FAQ

How fast can the system inspect?

Up to around 30 FPS on a single line with Jetson Orin (Xavier-class). For typical production-line throughput (1-5 units per second per inspection point), this is sufficient.

What if the defect type changes seasonally / by batch?

We add new defect types as they appear. Each one is a 2-4 week cycle. If your defect mix is highly variable, plan for ongoing taxonomy expansion as part of operations.

Can this work without a barcode trigger?

Yes, motion-triggered capture works for many lines. Barcode triggers are more reliable because the system knows which unit it’s inspecting; motion triggers may capture mid-transition images that are harder to interpret.

How does this differ from industrial CV inspection systems (e.g., Cognex)?

Commercial inspection systems are excellent for well-defined defect detection with rule-based logic. Our approach fits when defect types evolve, when the defect catalogue isn’t fixed upfront, or when you want a continuous-improvement loop in place of a static configuration. We sometimes deploy alongside commercial systems: Cognex handles the well-defined cases, our system handles the evolving and harder ones.

What if our line speed is too high to inspect every unit?

We can deploy with sampling and inspect every Nth unit. Or we can deploy multiple inspection rigs at different points. Inspection against throughput is a trade-off we calibrate per line during the test phase.

Ready to Discuss?

If you operate a production line where visible defect quality is a real customer- or compliance-facing cost, this is a relevant pilot. We’ll walk through your line setup, your defect mix, and your QA process. Then we tell you what an MVP rig would cost and what the realistic timeline to production-grade automation looks like.

Discuss your project