Perimeter security with fixed cameras, object detection and a drone sent to look

A pumping station at the end of a gravel road has four cameras on its fence, a recorder in a cabinet, and a guard who is half an hour away at the nearest staffed site. At 3 am on a Tuesday somebody climbs the fence on the north side. The recorder writes it to disk, the guard finds it on Wednesday morning when the copper is already gone, and the insurer asks why nobody looked.

Nobody looked because there was nothing to tell them to. The cameras were recording, and recording is not watching.

Object detection on a frame every two seconds is enough

The instinct is that catching an intruder needs every frame, and that every frame needs a GPU. Neither is true for a fence. A person crossing a perimeter is in view for many seconds, a vehicle for longer, and a model that samples the feed about every two seconds sees each of them several times before they are gone. Object detection on that sample rate is a job a CPU beside the recorder can do for four cameras.

That matters at a site with no rack and no budget for one. The runner sits in the cabinet next to the recorder, pulls each RTSP feed, runs the model on the sampled frames, and the footage never leaves the site. The deployment doc sets out what leaves and what stays: the model runs where the cameras are, and only the frames it doubts go anywhere else.

My own view is that a site should run the model on the hardware it already owns before anyone opens a ticket for a GPU. A CPU sampling four fence cameras every two seconds has caught more intruders than a GPU that was never purchased.

The zone is drawn on the image and the rule is a person inside it

Camera 3 on the north fence sees the fence, the strip of gravel inside it, the road outside, and a field beyond. A person on the road is a walker. A person on the gravel is an intruder. The model finds people and vehicles; it does not know which side of the fence they are on. The zone does.

The zone is a polygon drawn on the camera's image, the gravel strip inside the fence. The rule is written as a sentence: a person or vehicle inside the north zone between dusk and dawn, high severity, with a cooldown so one intruder does not fire twenty alerts. It is approved before it goes live.

The hazard zone intrusion use case says why this is fragile: the zone lives in image space rather than in the world, and everything depends on the camera meaning today what it meant the day the zone was drawn. A wind-loosened bracket that tilts the north camera by a few degrees moves the gravel strip out of the polygon and puts the road inside it, and from then on every walker is an alarm.

One frame is a fox and three frames are a person

A single detection at 3 am is often nothing. A fox crosses the gravel in one sample and is gone by the next. A plastic sheet lifts in the wind and reads as a person for one frame. If every one of those pages the guard, the guard stops answering by the end of the first week.

The rule confirms before it fires. A person has to be inside the zone on several consecutive samples, which at two seconds each is a handful of seconds, and a person climbing a fence is there for longer than that. The fox is not. The cooldown then holds the alert down while the same intruder walks the length of the fence, so the guard gets one message with the first frame, not a message per stride.

The fox at the pumping station crosses the north gravel at about the same time every night. The guard knows it by sight and calls it the shift change.

The alert carries the frame and the drone goes to look

What lands on the guard's phone is the frame with the person boxed and the zone drawn, the camera name, and the time. The guard looks at it and decides in seconds whether it is a person or a sheet of plastic, which is a decision the model does not need to make on its own.

Then the drone goes. The site's drone lifts from its dock, flies to the north fence, and streams what it sees back to the guard, who now has two views of the same intruder from two angles and can decide whether to call the police or the site manager. The drone is the second look. It is not the detector, and it should not be, because the fence model was trained on fixed frames at fence height and a drone at 20 metres over the same gravel sees a scene the model has never been shown.

If the site wants detection on the drone's footage as well, that is a separate model on separate frames, labeled from the drone's own camera. The fence model and the drone model share the classes and nothing else.

Fog and rain are the nights the model doubts

A model trained on a dry summer of fence frames meets its first wet November and starts sending frames back. Rain on the lens makes a person a smear. Fog at 4 am makes the gravel strip and the road the same grey. Headlights on the wet road throw a glare across the north camera that the model has never seen without a vehicle attached to it.

The drift catalog files this as rain, fog and dust: conditions the model rarely saw in training arrive for a week, detection falls off, then the weather clears and it recovers. On a fence the falling off shows up as doubted frames rather than as silence, and doubted frames are the useful kind.

LexData takes the fence model through its whole life. You type what to look for, Lexi puts a box on every person and vehicle in every frame, and a person checks each label before anything trains on it. The model then watches the four cameras on the fence, 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 foggy frames from November are in the version that watches the fence in December.

The guard's override rate says when to retrain

The signal that the model needs work is the guard. Every alert the guard dismisses as plastic or fox or headlight is a correction, and the rate at which the guard overrides the model, week against week for the same camera, is what says whether the fence model still describes the fence.

A rising override rate on camera 3 in a dry week is a moved bracket. A rising rate across all four cameras in a wet week is weather. Neither needs a metric from the model to see, because the guard is already counting.