Counting objects on a conveyor belt without counting any of them twice

The bolt line feeds a bagging station that wants exactly fifty in a bag. The counter on the vibratory feeder is a mechanical wheel that was accurate when the bolts were the old length and is off by one or two a bag on the new ones, and the packer has been weighing bags since March to catch it. A camera over the belt, a hand's width before the chute, can count what the wheel cannot, provided it never counts the same bolt twice.

That last clause is the whole job. Object detection is the easy half.

Object detection finds every bolt, and that is the wrong number

On each frame the detector puts a box on every bolt it can see. A bolt on a belt is in the frame for a second or two, which at the sampling rate the line runs is many frames, and a counter that adds up boxes per frame counts every bolt many times over. The per-frame count is not a count of bolts. It is a count of sightings.

The detector still has to be right, because a bolt it misses on every frame is a bolt that never gets counted at all. The labeling is a person typing "bolt" once, Lexi proposing the boxes on frames from the belt camera at its mounted height, and a person checking them. The frames come from the belt itself, at the line's speed, under the line's lights, because a bolt at rest on a bench and a bolt moving under a strip light are different pictures.

A track follows each bolt so it is counted once

Tracking is what turns sightings into a count. Each detection is matched to the detection nearest it on the previous frame, and the chain of matches gets one identity that follows the bolt from the edge of the frame to the chute. A bolt is counted when its track crosses a line drawn across the belt, and a track that has crossed once is never counted again, whether the belt is running at 8 am or at the end of the second shift.

Two settings decide whether that works on a real belt. A new track has to persist for a few frames before it counts, so that a glint off the belt does not become a bolt. And a track that loses its detection for a frame or two, because a bolt passed under a guard or the light flickered, has to survive the gap rather than start over as a new bolt on the far side.

The line the tracks cross sits where the belt is cleanest. On this line that is the last hand's width before the chute, where the bolts have spread out and the guard's shadow does not reach.

Touching parts are the label the plant has to settle

Bolts on a vibratory belt touch. Two lying side by side, one across another, three in a clump at the feeder end on a Monday morning when the hopper has been overfilled: this is where the count goes wrong and where the labeling has to decide what a box means. If a clump is labeled as one box, the model learns that a clump is one bolt. If each bolt in the clump gets its own box, tight to the visible part, the model learns to separate them, and it can, most of the time.

My own view is that the second rule is the only one worth training, even though it makes the labeling slower and the reviewer's disagreements more frequent. A count that is right on spread bolts and wrong on clumps is wrong exactly when the packer needs it.

The frames the model doubts are the clumps. They come back to a person, get their boxes corrected, and train the next version, and after a few rounds the clumps stop coming back. The assembly verification use case counts fasteners on a part rather than on a belt, and the touching-parts rule is the same one.

The count goes to the bagger as a record, and a mismatch is an alert

The count itself lands where the line already looks: a value per bag, with the time and the camera, into the system the bagger reads. An alert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: a bag count from the belt camera that disagrees with the feeder wheel by more than one, routine, to the packer's screen. What arrives is the frame with the tracked bolts drawn on it and the two counts side by side. The packer weighs that bag and not every bag.

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 belt camera the line 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.

A compression change on the camera is the step that breaks the count

The failure that arrives without warning is not on the belt. An IT update goes out across the plant's cameras overnight and the bitrate on the belt camera drops by half. Bolts become soft grey shapes, the detector's boxes wander, tracks break and restart mid-belt, and the count on Tuesday morning is a third high on every bag, to the hour the patch landed.

The drift catalog calls this a firmware or encoding change, and the shape is the clue: a cliff on one hour, confined to the cameras that received the change, while the belt itself is unchanged. It is the cheapest failure to reverse and the first to rule out. The plant's change log for that night is worth more than any retraining, and a camera setting put back is a count restored by lunch.

The packer, who has been weighing bags for a year, keeps weighing every tenth bag for a month after the camera goes in. On the bolt line that is the reference the count is checked against, and the day the scale and the camera disagree is the day something changed.