Patrol Robots: Route Design, Rounds and Guard Handover

What a Patrol Robot Actually Replaces

A patrol robot does not replace a guard, and framing the business case that way is the fastest route to a failed deployment. What it replaces is the walking round. A human guard on a night round is a moving pair of eyes and ears covering a fixed path at a fixed speed with a fixed number of breaks. A patrol robot performs the same traverse, at a comparable or slower speed, without breaks, without fatigue and with a sensor payload that is consistent from the first round to the last. The guard then does not disappear, the guard is re-tasked to respond to what the robot finds rather than to walk the route that finds it.

That distinction determines the whole design. If the objective is headcount reduction, the deployment will be measured against a guard's hourly cost and will usually disappoint. If the objective is coverage per shift, incident detection latency and consistent documentation, the deployment has a defensible case because it changes what the operation can see. The wider security fleet context, including fixed cameras and access control, is covered in security and surveillance robots for commercial facilities.

Designing the Route

A patrol route is a sequence of checkpoints with defined dwell, plus the go-no-go zones the robot must avoid. Four parameters determine it.

Parameter	What it controls	Typical setting
Checkpoint density	How many points are inspected per round	1 per 15-25 m of perimeter, 1 per aisle end internally
Dwell time	How long the robot pauses to gather data at a checkpoint	8-20 s per point, longer for thermal or acoustic capture
Exception zones	Areas needing a different capture routine	Plant rooms, loading docks, cash offices, cold rooms
No-go zones	Areas the robot must never enter	Wet floors, active forklift lanes, restricted cages

Checkpoint density is the parameter most often set wrong. Guards walk a route and look continuously; a robot inspects at points and travels between them. A route with too few checkpoints leaves long uninspected spans between them, and those spans are exactly where an incident will eventually be missed. A practical rule is to place checkpoints at every point where the sightline changes, every doorway, every corner, every transition between lit and unlit areas, and at least once per 20 metres of continuous perimeter run. The car park and underground facility variants of this design are covered in parking structure and underground facility robots.

Coverage Arithmetic: Rounds per Shift

The coverage question is simple arithmetic and it is the number that settles a deployment debate. A human guard walks at roughly 1.2 to 1.4 metres per second and, accounting for a 12-hour night shift with breaks, delivers about 10 to 11 hours of actual patrol time. A patrol robot travels at 0.8 to 1.2 metres per second, needs 30 to 60 minutes per shift off-route for docking and charging, and delivers about 9 to 10 hours of patrol time, but it never takes a break, so the loss is in charging, not in rest.

Take a facility with a 2,000-metre perimeter round plus 800 metres of internal route, so 2,800 metres per round. A robot at 1.0 metres per second, with dwell at 20 checkpoints at 15 seconds each adds 300 seconds, giving a round time of about 3,300 seconds, or 55 minutes. In a 10-hour patrol window that is about 10 complete rounds per shift. A walking guard, at 1.3 metres per second with the same dwell and breaks, does about 7 rounds. The robot delivers roughly 40 percent more rounds per shift, and each round is documented identically.

Metric	Human guard	Patrol robot	Note
Travel speed	1.2-1.4 m/s	0.8-1.2 m/s	Robot is slower
Patrol hours per 12 h shift	10-11	9-10	Robot loses charging time
Rounds on a 2,800 m route	~7	~10	Robot round-trips are consistent
Documentation	Manual log	Timed sensor capture	Robot exports event metadata

The honest conclusion is that a patrol robot does not do fewer rounds than a guard, it does more rounds with better documentation, at a lower marginal cost per round. That is the figure to put in the business case, not a headcount comparison. Fleet-level metrics for measuring that performance are set out in service robot KPI benchmarks.

The Guard Handover: Escalation and Response

This is the design element that decides whether a patrol fleet works in practice and it is the one most often left until after purchase. The robot detects and reports; the guard responds. The interface between the two is the escalation rule.

Tier	Event type	Robot action	Human action
1 - Log	Routine anomaly, unmatched but benign	Capture, tag, continue route	Review at shift end
2 - Notify	Open door, loitering, unlit area	Notify control room, dwell longer	Assess remotely, decide dispatch
3 - Alert	Motion in restricted zone after hours	Push live alert, hold position	Respond or dispatch patrol
4 - Escalate	Personal safety, fire or intrusion in progress	Alarm, stream, stand clear	Emergency protocol

The rule that makes this work is a single threshold the control room can trust: what the robot escalates without asking, and what it holds for human judgement. A fleet that escalates everything creates alarm fatigue and the control room stops responding. A fleet that escalates too little misses the event it was bought for. The event handling pattern is the same one used for incident escalation in incident response and escalation, applied to a mobile rather than fixed platform. The integration with existing access control and CCTV follows the same tier logic, and the practical route is to have the robot report into the current control-room platform rather than adding a second screen, as described in fleet management.

Night, Perimeter and Car-Park Duties

Patrol robots earn their keep after hours, and the duty mix changes with the venue. A perimeter round at night is thermal and visual: the payload is looking for heat signatures at fence lines, unlit doors ajar and vehicles in unexpected positions. An internal round after close is access control focused: checking that cages, cash offices and plant rooms are secured. A car park round is the most demanding because the environment is uncontrolled, with moving vehicles, weather and mixed lighting, and this is where the radar and bumper sensor redundancy matters most.

One practical constraint applies to all three: the robot's own lighting and beacons make it obvious, which is an advantage for deterrence and a limitation for covert observation. A patrol robot deters by being seen. If the requirement is concealment, that is a fixed sensor task, not a patrol task.

What a Patrol Robot Cannot Do

Being explicit about limits prevents a deployment from failing on expectations rather than technology. A patrol robot cannot physically intervene, cannot detain, cannot make a judgement about whether a person is a threat, and cannot cover a route faster than it travels. It cannot enter a zone it has been told not to enter, which means a wet floor or a spilled load stops the round rather than being worked around as a guard would. And it cannot substitute for a response capability, if the escalation goes to a control room with no one able to attend, the detection is documented but unresolved.

These limits are the same class of constraint that appears in any single-platform security design. The value of the robot is coverage and documentation, and the value of the guard is judgement and response. A patrol design that keeps those two roles distinct is the one that holds up in operation.

Specifying a Patrol Fleet

A concise specification follows from the design. Specify the route length and checkpoint count; the robot speed and the resulting rounds per shift; the sensor payload by duty, thermal for perimeter, high-resolution visual for access checks; the escalation tiers and the control-room interface; the no-go zone list; and the docking and charging arrangement. Specify the documentation output, since a patrol robot's audit trail is half its value. A fleet sized from round count rather than from headcount comparison is the one whose business case survives contact with finance.

How AOMAN Supports Security Integrations

AOMAN patrol and inspection platforms are deployed as part of an existing guarding and control-room operation, not as a standalone system. We design the route and checkpoint sequence with the security team, map the escalation tiers to the control-room protocol already in use, and integrate the robot's reporting into the platform the operators already watch. The result is a patrol capability measured in rounds per shift and events documented, layered onto the guard's judgement rather than replacing it. If you are scoping a patrol deployment, start with the route and the escalation rule, and we will size the fleet from there.