Conveyor video analytics: what breaks on the line
A missed defect in conveyor video analytics is almost never due to the defect having been "not seen." More often it coincided with glare from a lamp, turned out to be smaller than the analyzed area, or passed through the frame at the moment the belt accelerated.
Then the defective unit goes into packaging, and it is the recipient who finds it — along with a claim and reverse logistics.
The other side of the same problem is false triggers. A threshold set too strictly stops the line on glare, dust, and shadows from guards, and over a shift the operator gets used to the signals.
A weakened threshold brings back missed defects, and running between these two extremes manually means having no controllable setting at all. Without statistics by event class, it is impossible to set the threshold correctly.
Camera blind spots do not live on even sections, but at junctions. A part rotates between two fields of view, lighting changes at the transition, part of the image is blocked by a frame or airflow — and the event falls between two detectors.
On a long line, that is exactly where the main share of defects is lost, even though each section individually looks configured.
A separate loss category is manual shift recounting. Defect accounting is kept from logs and photos after the fact, the numbers between sections do not match, and the line summary appears by the next morning, when the batch has already been shipped. Quality control on the line in this mode works as a recorder, not as a management tool.
There is an engineering answer for each of these failure classes — we break down how it is closed.
What changes in line operation after implementation
The effect of video analytics is measured not by the number of cameras, but by line metrics: the share of defects found automatically, incident investigation time, and downtime duration.
Before implementation, these figures rest on the operator: they watch the stream on a loop and sort out disputed frames from memory, and do not review the entire shift recording.
Below is what changes after launch. The order of magnitude is typical for assembly and packaging sections with a continuous belt; on your line, a control run refines them.
What we check at the output
- Automatic defect control. A defect is recorded at the moment it passes through the zone of interest, not at final acceptance: the defective item leaves with a label, frame, and timestamp.
- Incident investigation time. Instead of searching through a shift's archive, it is the segment around the label: the disputed episode is retrieved in minutes.
- Reduced downtime. Belt skew, jam, or workpiece displacement are visible as an event before an emergency stop, not after disassembling the unit.
- Operator workload. Instead of continuous monitoring, a few labels per shift are reviewed: the system filters out routine, and a person looks at the disputed frame.
- Eliminated failure class. A foreign object, break, or double feed stop surfacing at the customer — the incident is tied to a section and time.
- Retraining without stopping the line. A new defect class is added by labeling and retraining the model on ONNX; old rules continue to work.
We take metrics during a control run before and after launch — the effect is visible in numbers, not in words.
Conveyor video analytics: cloud, local loop, hybrid
The scheme is dictated by three constraints: the quality of communication between the site and the external loop, conditions in the premises, and how many people are ready to allocate to operation.
Cloud video analytics removes computation from the site, but moves the entire camera stream into the uplink: when communication degrades, recognition loses frames rather than merely slowing down.
A local processing loop keeps the stream inside the shop, but adds requirements for the premises and on-duty staff. A hybrid scheme separates the tasks: detection and buffering on site, event aggregation, archive, and model training in the external loop.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud video analytics | Multiple sites, stable uplink, no space for a server room | The channel is the bottleneck: a communication break stops recognition, and the archive lives in the external loop |
| Local processing loop | One site with a dense camera stream, closed perimeter, reaction latency is critical | Requires prepared premises, on-site maintenance, and a model update procedure |
| Hybrid scheme | Multiple lines and sections, some tasks sensitive to latency, others to analytics | More complex surveillance system architecture: coordination of synchronization rules and a single point for model version control |
For conveyor video analytics, the boundaries are blurred not by equipment but by the load profile: how many cameras look at the line, how long to store the archive, and what the system does when communication is lost.
These answers are obtained at a pilot section — the scheme is chosen based on the measured bandwidth and behavior during breaks.
Work stages: from line survey to shift handover
The order of steps here is not a formality: the angle, camera overlap, and line mode determine which events are distinguishable at all, and rework after installation costs more than a thoughtful survey. Therefore each subsequent stage relies on the recorded result of the previous one.
- Line survey — time study of operations, speeds and modes, points where product orientation changes, lighting, sources of dust and steam. Output: a list of events the system will reliably distinguish.
- Camera placement scheme — angles, suspension heights, zone overlap, blind spots at belt junctions, cable routes, enclosure protection. We coordinate the scheme with operations before purchase.
- Installation and connection — installation according to the scheme with recording of actual angles, connection to the enterprise network, access separation, and a dedicated channel for the video stream.
- Logic configuration — labeling of frames captured from the line itself, zones of interest, trigger thresholds, event stitching rules. Separately, we suppress false triggers from glare, steam, and containers.
- Commissioning — a run on a real stream, debugging the latency from frame to signal to the actuator, testing rejection and emergency scenarios.
- In-stream verification — several shifts in different modes: speed, raw material batches, shift changes. We compare results with manual control and document discrepancies in a protocol.
- Personnel training — operators and setup technicians receive a procedure: what to do on a false trigger, how to return the system to operating mode, and where to view the event log.
We hand over to the shift with a documentation package and a support period during which we adjust thresholds based on accumulated statistics.
The set of settings and procedures that remains with you
We hand over not only a working system, but everything needed for its independent operation. The set is assembled so that a new operator shift and your engineer can figure it out without us: what is configured, why exactly so, and what to do if behavior changes.
- Detection zone and alarm rule configurations — what is considered a violation, which trigger thresholds are set, and how to reconfigure them when the product or line speed changes.
- Equipment placement scheme — camera installation points, coverage zones, mapping to conveyor sections and units that were intentionally left out of view.
- Video access policies — roles and rights for viewing the archive and exporting fragments, record retention periods, and the procedure for granting access to a new employee.
- Shift instructions — one page: what to check before starting the line, how to respond to an alarm, and to whom to pass the signal.
- Failure response procedure — typical scenarios: camera stream lost, false triggers began, archive unavailable. For each, it states what the operator checks independently and at what point to call an engineer.
- Change procedure and version log — how to record edits so that six months later it is clear what changed and why, and it is possible to return to a previous setting.
Documentation is updated with every system change: an outdated instruction is more dangerous than none. After launch, we conduct a review with your shift — where the procedure failed and what to rewrite.
Case study: how downtime was reduced on a bottling line
Case study: a bottling plant, two lines, three shifts. Quality control relied on operators — they watched fill level, label position, and cap seating, and recorded a conveyor stop after the fact, when bottles were already piling up on the accumulation table. Over a shift, 6–7 unplanned downtimes accumulated.
What it was like before implementation
Defects were detected selectively: at line speed, the operator does not have time to watch the stream, so some defective bottles went into the corrugated packaging and surfaced at the customer.
Reaction time to a stop was measured in minutes — notice, walk over, call a setup technician. No data remained for investigation except the shift's words.
What was changed
On the Krones bottling line, cameras were installed at the filling, labeling, and capping units. Frames are processed on site; only the event with a timestamp and a link to the video fragment goes to the network.
Alarm rules were tailored to specific defects: underfill, label displacement, cap skew, and conveyor jam. The signal goes to the shift board and the duty chat; rollback to video is by click.
Metrics before and after
| Parameter | Before | After |
|---|---|---|
| Share of detected defects | about 60% | 97% |
| Reaction time to a stop | 4–8 minutes | 15–25 seconds |
| Unplanned downtimes per shift | 6–7 | 1–2 |
Shift debriefing now uses a cut of events, not memory: you can see which unit triggered first and what preceded it. False triggers from glare and steam were removed by selecting zones and thresholds on the real stream.
What to do if cameras are already installed on the line?
An existing surveillance system is almost always partially suitable — the question is not whether cameras exist, but what frame they deliver in the control zone.
Therefore the first step is not procurement but a review of angles: at what angle the camera looks at the belt, whether the working zone fits entirely in the frame, and whether there is obstruction by structure or the product flow itself.
The assessment takes a site visit and a couple of shifts of recording — they show the real picture, not datasheet specifications.
Angle suitability is more often fixed by mechanical means than by replacement: rotating the bracket, shifting the point a couple of meters along the line, moving the camera out of the glare zone from metal.
If after that the controlled object consistently appears in the frame at the required angle, the camera remains in operation, and analytics connects to the same stream.
Illumination of the working zone is the second failure point. Infrared lighting burns out glare on shiny containers, and in the shadows under the roller conveyor the part disappears.
We look at the brightness distribution across frames and decide where it is enough to replace the source, where to add local lighting, and where to increase contrast on the processing side.
Modernization without replacement is possible where the frame is predictable in brightness and sharpness throughout the entire shift.
Integration with current equipment runs in parallel with the existing loop: analytics takes the stream from the recorder or camera and does not interfere with recording, archives, or the operation of surveillance posts.
If access is closed, we set up a separate route without breaking someone else's scheme. Ultimately, only those cameras that fail on angle or lighting are replaced — the remaining points move into analytics as they are.
Doubts and limitations: what engineers ask
It is more honest to discuss the boundaries of applicability before work starts: they determine camera placement, the lighting scheme, and requirements for the computing node on the line. Below are the doubts that most often come up during assessment.
What if the shooting conditions turn out to be poor?
Recognition relies on the contrast of the object against the background.
Glare from metal, steam, dust, and oncoming light from gates break the mask, and the defect class begins to "drift." This is treated by the scene, not the model: shields against overexposure, separate lighting for the control zone, fixed exposure.
Before training, we take 2–3 shifts of recording from your line and check that the detector can distinguish the defect from the background at all.
What happens if communication with the server is lost?
The node on the line continues detection autonomously and writes the stream to local storage. Events with snapshots go into a queue with timestamps and are sent later when the channel returns.
Only the live picture in the control room is lost; buffer depth is configurable — from one shift to several days.
How is recognition reliability verified?
We fix the metric before launch: missed defect and false trigger are counted separately, since they have different costs. We manually label a reference sample and run the detector over it; disputed frames are reviewed together with the process engineer.
False triggers are removed by threshold and zone mask, while misses are addressed with a second angle at the line output.
How long does it take to launch for a new product?
Basic checks — item presence, dimensions, orientation — are set up in the first week and do not depend on the product type. A new defect class requires 2–3 shifts of recording, labeling, and additional training with validation on a holdout sample — about two weeks per class. After that, retraining follows the procedure you receive along with the documentation.
Let's discuss the task: send the line diagram and shop floor plan
To keep the conversation specific rather than overview, it is useful to see the line and shop right away: conveyor video analytics depends heavily on the geometry of the section — where cameras stand, what obstructions exist, how light falls, and how the product behaves at transfers.
The more complete the input data, the fewer assumptions in the timeline estimate and the more accurate the risk analysis.
- Line diagram with section lengths, transfer points, and places where personnel work.
- Shop floor plan with camera mounting points, power supply, and network connection.
- List of events to catch: belt tracking deviation, foreign object, jam, stop, product defect.
- Several recordings from current cameras at different times of the shift, including night and peak load.
- Stream characteristics: belt speed, product type and dimensions, intervals between items.
- Infrastructure data — where the computing node can be placed, whether there is a separate room or cabinet.
- Who on the enterprise side accepts the result and by what criterion a trigger is considered correct.
In response, we send an analysis of conditions: what is covered by the algorithm, what will require additional sensors or lighting, and where accuracy is physically limited — steam, dust, vibration, low contrast between product and belt.
Then follows a stage-by-stage work plan with responsible parties and acceptance points, an honest timeline estimate with a range for uncertainties, and a list of risks with how each is mitigated.
If data is insufficient, we will say directly what exactly is missing — and suggest how to collect it on site.
