Video process monitoring, turning a conveyor camera into a count you can trust

The count on line 6 comes from a photo-eye at the end of the conveyor, and the photo-eye counts anything that breaks the beam, including the operator's hand, a loose strap and the tote that gets pushed back for a rework. The shift report says the line made a number, the ERP says it consumed a different number, and the industrial engineer spends Friday reconciling the two. The dock has the same problem with pallets and a clipboard.

Both cameras already exist. The conveyor camera was put up for a safety review and the dock camera for the insurer. Between them they have watched every part and every pallet for two years, and nobody has asked them for a count.

Object detection gives sightings, and tracking turns them into a count

On each sampled frame the model puts a box on every part on the belt. That is object detection, and it gives a count of what is visible in that frame, which is not the number anyone wants. A part on line 6 is in view for a couple of seconds and shows up in frame after frame, and adding boxes across frames counts it as many times as it was seen.

The count comes from tracking. Each box is matched to the box nearest it on the previous frame, and the chain gets one identity that follows the part along the belt. A line is drawn across the frame where the belt is clearest, and a track that crosses it is counted once and never again. Direction matters too: a tote pushed back for rework crosses the line the wrong way, and the rule can count it out rather than in.

The dock is the same mechanism with bigger objects. Pallets boxed, tracked from the trailer to the floor, counted once as they cross a line at the door, inbound and outbound kept apart.

The labeling settles what a part is before the count can

You type "part" and "tote" once, Lexi proposes the boxes on frames from the line 6 camera, and a person checks them. Most of the checking is at the edges of the definition. Two parts touching, a part half under the guard, a part on its side that looks like nothing in the training frames. Each of those is a decision the reviewer makes once and the model learns, and the count is only as good as those decisions.

On the dock the awkward case is the double-stacked pallet, which is one object to the forklift and two to the receiving clerk. The reviewer picks a side and the label guide records it.

The rule is a sentence with a severity and a cooldown

The count on its own is a record: a part crossed the line at a time, on a camera. The alert is what a person acts on. It is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: parts crossing the line 6 count line at fewer than the shift's target rate for ten minutes, routine, to the line lead. It arrives with the frame and the count so far, which is enough to walk over and look.

The alert written as a sentence is the same shape on the dock: pallets inbound at door 4 with none outbound for an hour, routine, to the dock lead. The cooldown is what keeps either channel usable, because a slow line is slow for a while and one message says so.

On sites we run, the first version of a counting alert goes to a morning digest rather than a phone, until the line lead has seen a week of counts and trusts them. A count that pages people on day one gets muted on day two.

The count lands beside the number the ERP already keeps

The value of a count is where it goes. Line 6's count per hour sits next to the ERP's consumption figure, and for the first time the two can be compared without a Friday. The question of why they differ has an answer with frames behind it, asked of LexInsight in words: what crossed the line 6 count line between 2 pm and 3 pm on Tuesday, and how many went back.

My own view is that the count should not replace the photo-eye in the first quarter. The photo-eye is wrong in known ways, and the camera is wrong in ways nobody has found yet. Running both, and looking at the days they disagree, is how the second set of ways gets found.

Alert volume against its own history is the cheapest signal there is

Six weeks in, the slow-line alert on line 6 starts firing every shift. Nobody changed the model. The parts are being counted correctly, and the line really is slower, because a new supplier's blanks need an extra pass on the press upstream. The threshold that was tuned around the old rate is now wrong for the new one, and a team that reads the alerts as a model failure will retrain a model that was never wrong.

The drift catalog calls this the defect rate changed, and the same shape holds for a throughput rate. Per-detection accuracy holds while the downstream count swings, and the cheapest place to see it is alert volume against its own history, week by week, per camera. A line whose alerts doubled is a line where something upstream changed, and the fix is a conversation with the press, or a threshold, before it is anything to do with the model.

LexData takes the counting model through its whole life. You type what to look for, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the cameras the site already has, in the cloud, on your servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime. The correction rate on those frames is the model's health; the alert volume is the line's. Keeping the two charts apart is most of the job.