Red zone monitoring with a camera over the forklift lane

The lane between the racking and the dock doors in the despatch area is painted yellow, and the paint is worn through where the forklifts turn. A camera on the column above dock door 3 has looked down on that lane for years, recording. During a shift change at 2 pm a picker cuts across the lane on foot with a clipboard while a forklift reverses out of the trailer, and the recording shows it clearly, to anyone who watches the recording the following week.

Red zone monitoring is the job of watching that lane while it matters, and it is three separate problems: finding people and vehicles, knowing where the lane is, and deciding how long is too long.

The COCO dataset knows a person and not this lane

A stock detector trained on the COCO dataset will find a person on that camera on the first day. It will also find the forklift about half the time, because a forklift is not among the everyday things that dataset was built from, and the trucks and cars it does know look nothing like a reach truck seen from above. The person class is a start. The vehicle class is the site's own.

So the classes are person and vehicle, both boxes, and the frames they are trained on come from the camera above door 3 at its mounted height and angle. In LexAnnotate you type the two classes, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The reviewer's time goes on the forklift seen end-on with its mast up, the picker partly behind a pallet, and the reflective stripes on a vest that a stock model sometimes reads as a second person.

On the manufacturing lines we run, 99%+ accuracy maintained in production is a per-detection figure. Whether the picker was in the lane is a question the detection alone cannot answer.

The zone is a polygon drawn once in the frame

The lane is drawn as a polygon in image coordinates on the view from door 3, once, by the person who wrote the safety rule, and my view is that it should be that person at the monitor and never whoever set up the model. The polygon follows the worn yellow paint and stops at the dock plate. A detection counts as inside the zone when the bottom centre of its box, the point nearest the floor, falls inside the polygon. The hazard zone intrusion detection use case describes why this is as cheap as detection gets: the whole decision is whether a point crosses a line.

Two zones are better than one on this lane. The lane itself, where a person on foot is the event, and the trailer apron beyond the dock plate, where a person is expected and a forklift reversing is the event.

Dwell inside the zone is the rule, entry starts it

Crossing the lane at door 3 takes a picker four seconds. Standing in it to read a clipboard takes thirty. The rule that produces an alert people act on is dwell: a person inside the lane polygon for longer than the crossing time while a vehicle is also inside it, or for longer than a set window whether or not a vehicle is present.

Dwell needs tracking, because the same person has to be the same person from frame to frame or the timer restarts every time the tracker loses them behind a pallet. Sampling every couple of seconds is enough for a dwell rule and much too slow for a collision warning, which is a different product and a different camera. The honest scope of this camera is the picker who has stopped in the lane.

The paint on a forklift lane wears through first at the turns, which is also where the forklifts are slowest and the pickers most tempted to cut across.

The supervisor gets the frame and the seconds

An alert in LexAlert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live. For this lane it reads: a person in the lane at door 3 for longer than the crossing window, to the despatch supervisor's Slack or to the site's own webhook, with the frame attached. The frame shows the picker, the polygon and the forklift, and the supervisor can judge from a phone whether to walk over.

The cooldown is per person rather than per frame. A picker who stands in the lane for thirty seconds produces one message, and the supervisor's response to it, a word with the picker or a shrug because the lane was closed for cleaning, is recorded against the model's call. When the model was wrong, a vest on a hook read as a person, that override is a correction the next version trains on.

LexData takes the lane 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 camera above door 3, 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 moved camera moves the zone, the floor stays put

The failure this camera is most exposed to has nothing to do with the model. A crew cleans the housing, a bracket is re-tensioned after a forklift clips the column, and the camera above door 3 now looks four degrees to the left. The detector still finds every picker, because a picker looks like a picker from any angle. The polygon is still where it was in the image, and the image has moved, so the red zone now covers a strip of racking and misses the near edge of the lane.

Every detection is correct and every alert is wrong, and no accuracy figure moves. The drift catalog describes a camera moved as the cheapest condition to fix and the quietest to suffer, and this use case is the one it ruins fastest. The signal is a change in alert volume on one camera that lines up with a maintenance date rather than with a shift pattern.

The check is physical. Once a week, somebody looks at the live frame with the polygon drawn on it and confirms it still sits on the yellow paint. If it does not, the polygon is redrawn, a short window of frames is re-labeled from the new framing, and the model retrains on footage the site already has. The floor never moved. Only the picture did.