UNITREE ROBOT APPLICATION · CAMPUS SECURITY · 2026
The future of campus security?
A hybrid patrol model — prototype, constraints and safety research.
This is a research dossier, not a deployment: it evaluates the effectiveness of quadrupedal robotics in university security systems, states the limits of the approach, and writes every constraint as a rule, a control that enforces it, and a way to verify it.
SIMULATED No robot is owned or operated by this project. The simulator is the interactive artifact already built for this presentation (deck slides 39–42) and is hosted with the deck.
Efficiency against limitations
Existing security mechanisms are limited by their lack of mobility and restricted to their installation points; human guards spend considerable time on routine patrols. The Go2 introduces mobility, automation, real-time data collection and potential for intelligent monitoring. Technology alone does not make the result better — the limits below are part of the evaluation, not a footnote. FROM-DECK
Battery life
Standard configurations offer approximately 1–2 hours; the EDU long-endurance configuration is listed at approximately 2–4 hours. A patrol that dies mid-route is a coverage failure, not a technical detail.
Human judgement
Robots cannot fully replicate human reasoning, social awareness and decision-making — and Go2 cannot replace human intervention or emergency response.
Environment & cost
Weather, crowded walkways and unpredictable environments affect operation. Acquisition, maintenance, replacement parts and technical expertise drive the total cost.
Privacy & technical dependency
Mobile surveillance raises consent, recording-policy and personal-data questions. Software failures, connectivity interruptions and mechanical problems disrupt operations.
Coverage, automation and incident reporting — six findings
Conditional language is deliberate: each item says what the Go2 could contribute, and each is testable by the pilot. FROM-DECK
A · Increased surveillance coverage
Unlike stationary CCTV, Go2 can physically move between designated locations, inspect areas outside fixed-camera range and provide different viewing angles.
B · Automation of repetitive tasks
Follows designated patrol routes, conducts scheduled inspections and collects visual information without a guard on every routine round.
C · Improved detection & reporting
Cameras and LiDAR provide environmental information; with appropriate software integration it could flag predefined events to a central security team.
D · Consistency & predictability
Programmed routes allow repeatable inspection schedules; patrol records provide information about surveillance coverage.
E · Reduced exposure to certain risks
Could inspect selected isolated or potentially hazardous environments before human personnel enter, with remote visual assessment.
F · Data collection & security intelligence
Visual and location records could help identify areas requiring additional surveillance and allocate resources more effectively.
A hybrid security model — the strongest application
The value is integration into existing infrastructure, not replacement: the mobility and automation of robotics combined with the judgement and intervention capabilities of human security personnel. FROM-DECK
1 · Existing infrastructure
CCTV cameras, access-control systems and alarms provide established security coverage.
2 · Robotic patrols
Go2 supplements existing surveillance by inspecting designated locations.
3 · Central monitoring
Information from robotic patrols and existing systems is reviewed by security personnel.
4 · Human response
Trained security personnel verify incidents, make decisions and coordinate appropriate responses.
One Go2 patrols a fixed route on a schedule
The prototype patrols a fixed campus route, stopping at named checkpoints — a library exit, a service gate, a corridor. It sends a live front-camera feed to a campus computer, where computer vision flags possible obstructions and changes for security staff to review. FROM-DECK
Legs + SportClient
High-level locomotion: StandUp(), Move(vx, vy, vyaw), StopMove() — follow the route at a controlled speed and stop at checkpoints. A local route controller turns waypoint targets into motion commands.
Motion sensors & telemetry
Subscriptions to SportModeState and LowState give estimated motion, orientation and battery state.
Front camera
Frames requested continuously and relayed to the campus computer for live viewing and analysis; achievable frame rate and latency measured on the intended unit.
Local network interface
The SDK2 DDS connection carries motion commands and telemetry; scheduling, video analysis and the guard dashboard run on the campus application.
What makes the patrol useful
Known viewing position
Each checkpoint has a known viewing position, a marked area to inspect, and a reference image from a normal patrol.
Object detection
A deep-learning detector looks for objects inside marked exit or walkway zones.
Visual comparison
At checkpoints, a separate visual comparison flags changes — a gate left open, an object absent from the reference view.
Evidence before alert
Evidence across several frames is required before opening an alert; repeat sightings of the same issue group into one case.
What security sees — the guard dashboard
Live feed & last checkpoint
The dashboard shows the live feed from the robot's front camera and the last completed checkpoint.
Alert queue
Each alert includes the checkpoint, time, reason, and a snapshot or short clip. Staff can confirm or dismiss it.
Honest coverage
If the feed drops or a checkpoint cannot be verified, the dashboard marks that checkpoint as uninspected — it never shows a checkpoint as covered when it was not.
Control flow — one patrol loop, from schedule to coverage log
Eight constraint areas — each a rule, a control, a verification
Every constraint is written so it can be checked before the pilot starts and audited while it runs. FROM-DECK
| Area | Rule | Control that enforces it | How it is verified |
|---|---|---|---|
| 1 · Physical safety | No contact with any person or animal; walking pace only (≈1.0–1.2 m/s); stop on perception or command-link loss; never leaves the geofenced route. | LiDAR and depth slow at 2 m, full stop at 1.5 m — the robot yields, it never pushes through a crowd. Mass ≈15 kg: leg guards mandatory; never driven at feet, pets or guide dogs. Physical e-stop plus watchdog. | Every stop, bump and near-miss logged with a timestamp and the frame that caused it, reviewed weekly. A near-miss counts as a defect, not as bad luck. |
| 2 · Privacy & surveillance boundaries | Footage used only to detect obstructions and changes at predefined checkpoints. Smallest field of view; faces and dormitory windows blurred at the edge. No face recognition, no gait recognition, no plate reading, no audio recording. | Raw clips deleted after 30 days unless attached to a confirmed case — deletion automated, because a retention policy that depends on goodwill is not a control. Signposted checkpoints; named-staff access, logged views, watermarked exports with second approval. Vendor cloud disabled: local or edge processing only. | Data-protection impact assessment signed before the first patrol. A student can ask whether a clip exists and request deletion inside the retention window. If a checkpoint cannot be filmed without capturing a private area, the checkpoint is redesigned. |
| 3 · AI reliability | An alert is a claim the system must defend: high confidence threshold, evidence across consecutive frames, repeat sightings grouped into one case. Three states, not two: clear / obstruction / inconclusive — and inconclusive goes to a human, never silently treated as clear. | Reference images re-approved on a schedule; a persistent mismatch reported as a maintenance signal. Alert volume, confidence distribution and dismissal rate tracked for drift. | Each checkpoint has its own labelled test set (day and night); recall, false-positive rate and latency published per checkpoint before deployment. A checkpoint that fails its threshold is not deployed. |
| 4 · Human oversight & accountability | Every alert is confirmed or dismissed by a security officer. No alert alone triggers a sanction, a police call or an entry in a student file. The robot observes, alerts and withdraws — it has no authority to stop, follow or confront anyone. | Named security lead, technical owner and data-protection contact — anonymous operation is not permitted. Dismissals recorded with a reason; a right-to-contest channel with a human answer. | A monthly sample of dismissed alerts is re-reviewed, so the human layer is audited rather than assumed. The log makes each decision traceable end to end. |
| 5 · Cybersecurity & remote hijacking | A hijacked robot is a 15 kg machine with a camera moving inside a campus — treated as a likely event, not a remote possibility. No default credentials, no port exposed to the internet, no mandatory vendor cloud. | TLS for video and command streams; mutual authentication between console and robot; signed, versioned firmware; a distinct credential per robot; dedicated VLAN with no route to student or HR systems. Limits enforced on the robot, not on the laptop. Stored locked, USB ports disabled. | Heartbeat and full command log; automatic safe stop if an unrecognised controller appears; a compromised-robot playbook with campus IT and the vendor; any vendor update treated as untrusted until reviewed. |
| 6 · Operational limits & failure management | Return to dock at 20% state of charge; missions planned on the shortest endurance configuration, not the best-case one. Link loss, low battery, blocked path or a stuck sensor all lead to the same sequence: stop, return to dock, mark the checkpoint uninspected. | Rain, wind, snow, stairs, lifts, crowds, reflective floors, low light and GPS denial explicitly out of scope — each tested or listed as a limitation, never ignored. Failure log, maintenance calendar, spare-parts budget, named reviewer. | The robot is never the only sensor on a route: existing CCTV and human patrol remain the fallback. Any claim of reduced guard headcount is rejected until a measured pilot proves the opposite. |
| 7 · Accessibility, social acceptance & psychological impact | Must not obstruct a wheelchair, a pram, a guide dog or a person who is blind. Yields, stops at distance, never occupies the space a person needs. Quiet mode near residences. Consistent, predictable behaviour at walking pace. | Visible marker; no sudden appearances or route changes. The robot is never presented as a toy, a mascot or a deterrent. A feedback channel that actually answers. | An anonymous survey before and after the pilot measures whether people stop using a space because the robot patrols it — a negative result is a reason to stop, not a metric to explain away. |
| 8 · Legal compliance & responsible deployment | Processing follows applicable data-protection law and its standard principles, plus a documented legal basis. Surveillance of public space and biometric identification remain out of scope. An alert cannot feed a disciplinary process without a human investigation and a right of reply. | DPIA written before the first patrol — if it cannot be completed, the pilot does not start. Student and staff representatives consulted before, not after; safety committee, IT security and the data-protection officer sign off. Vendor contract states liability, data ownership and remote access. | The deployment checked against the applicable AI regulation and campus rules. The pilot has a defined end date, a published result and a documented stop / continue / expand decision — continuing by default is not allowed. |
The pilot starts only when every line is true
Deployment gate — eight conditions
- Route, geofence and stop zones mapped and measured.
- Each checkpoint has a labelled test set and published recall / false-positive rates.
- The DPIA and the student and staff consultation are signed.
- The cybersecurity review and the vendor data-flow review are complete.
- Emergency stop, link-loss stop and return-to-dock tested and logged.
- A security lead, a technical owner and a data-protection contact are named.
- Retention, deletion and access control enforced by the system, not only by policy.
- Existing CCTV and human patrol remain the fallback on every route.
Even with all of the above
The robot can miss an obstruction, be fooled by a change in lighting and make a person feel watched. It lowers the cost of a patrol and the delay in reporting. It does not remove the risk, and it does not replace a human being in the response.
Research questions the pilot should answer
- Can quadrupedal robots improve campus surveillance coverage compared with stationary CCTV systems?
- Can robotic patrols reduce the time security personnel spend conducting routine inspections?
- Does integrating mobile robotics improve incident reporting and response times?
- Is the long-term cost of robotic patrols justified by their operational benefits?
- How can universities introduce robotic surveillance without compromising student privacy?
The patrol simulator from the presentation
The simulator is the artifact already built for this presentation (slides 39–42) and is hosted with it — this site deliberately does not re-host, rebuild or re-label it. It opens in a new tab: the artifact's own security policy prevents embedding on other origins.