02 / Site & perimeter surveillance

Autonomous surveillance vehicle

More ground. More context.

A configurable ground platform for larger private sites. Bring route planning, mobile sensing and remote supervision together for perimeter rounds and repeatable area checks.

See how it works Download white paper

Technical reference · Version 1.0 · 1 November 2026

Illustrative surveillance vehicle observing an unattended bag on a campus walkway — Illustrative application · Configuration is project-specific

01 / PurposeSite & perimeter surveillance

02 / ApproachObserve → review → respond

03 / Design statusConfigurable reference architecture

01 / THE PURPOSE

A useful view.
A reviewable record.

Larger sites create a coverage problem: the same team must inspect gates, walkways and remote corners while maintaining a consistent record. A mobile ground platform can carry sensors along agreed routes and provide a second viewpoint. This reference design concerns controlled private-site operation; public-road autonomy is outside its scope.

Consistent coverage

Plan rounds around site zones and expose checkpoints that could not be visited.

Mobile evidence

Connect an observation to a location, route and timestamp instead of sending an isolated image.

Configurable payloads

Choose the sensor mast, body, onboard processing and connectivity around the terrain and task.

Where to explore the platform

Campus perimeters

Repeat controlled patrols along designated private lanes and boundaries.

Industrial yards

Observe selected access points and storage areas without assuming every surface is traversable.

Large facilities

Provide a mobile viewpoint for operators investigating a site event.

02 / FROM PLAN TO ACTION

A site patrol, explained.

Select a step or play the sequence. Change the scenario to explore a different outcome. This is an explanatory simulation, not a connected device.

Private campus / schematicIllustrative

Normal mission · Readiness checks assumed satisfied.

Planned routeRoute travelledReview point

STEP 01 / 06

Define the route

An operator selects a permitted private-site route, inspection zones and the response policy. Boundaries and no-go areas belong to the mission configuration.

System stateRoute selected

A candidate event requires operator review. Mission success and alert acknowledgement are separate outcomes.

The complete mission sequence

Define the route. An operator selects a permitted private-site route, inspection zones and the response policy. Boundaries and no-go areas belong to the mission configuration.
Check the vehicle. Check sensing, position confidence, drive health, energy and the local stop path. Starting requires the selected route and ground conditions to be within the validated envelope.
Follow the patrol lane. Fuse available localization inputs, plan a feasible path and follow it with terrain-aware operating limits. Avoid assuming that a path on the map is physically traversable.
Inspect the zone. Collect observations at the checkpoint. A persistent object in a configured review zone can become a candidate event; it is not automatically classified as a threat.
Notify the operator. Send location, capture time and selected evidence. The operator assesses the context, acknowledges the event and decides whether to dispatch a response.
Close the round. Return to the assigned base when feasible. Reconcile completed zones, interruptions and event delivery so the next shift sees an accurate mission record.

Enable JavaScript to explore the interactive scenarios.

03 / SYSTEM ARCHITECTURE

Different layers.
Clear responsibilities.

Separate sensing, mission logic, local control and operator review. The diagram is a proposed allocation of responsibilities; component selection and interfaces are agreed during engineering.

Sense the site

Range, camera and motion sensors

Gather nearby geometry, imagery and vehicle motion. Outdoor sensing needs evaluation under glare, darkness, dust and occlusion.

Locate & route

Onboard fusion / route planning

Combine the selected localization sources and compare the route with allowed areas. GNSS may be one input where usable; it is not a complete autonomy system.

Control the base

Drive control + independent stop path

Translate bounded movement requests into steering or wheel commands. Braking and stability depend on the actual chassis and payload.

Supervise remotely

Telemetry gateway + operator panel

Expose mission progress, network freshness and events. Remote commands require authority, acknowledgement and a tested timeout policy.

Local control boundary

Motion or flight responses must have a defined local policy. A web dashboard, cloud connection or language model is not a substitute for the platform's assessed control and stop / recovery systems.

Localization across a changing site

A project may combine wheel feedback, inertial sensing, LiDAR localization and GNSS where available. Buildings and foliage can affect satellite reception; slip changes wheel-based estimates. The system should evaluate confidence rather than treating every coordinate as ground truth.

Plan for the real chassis

The navigation model must reflect width, turning radius, stopping behavior and payload overhang. Candidate Nav2 components can separate path generation and tracking, but controller selection and validation depend on the drive geometry and site conditions.

From an object to a reviewable event

A camera can provide a candidate object observation. Escalation should incorporate persistence, zone rules and operator review. A bag-like shape does not establish intent, ownership or danger; the event should describe what was observed.

Technology background: Nav2: navigation servers · ROS 2: quality of service. These sources explain components, not Xcugas product certification or integration status.

04 / HARDWARE & CONFIGURATION

Specify the system
around the site.

Each layer has a job and an acceptance question. The final bill of materials, operating envelope and test evidence belong to the agreed project configuration.

Subsystem	Candidate configuration	What to verify
Ground chassis	Drive system, wheels and payload mounts	Turning radius, surface compatibility, braking and center of gravity.
Localization	Encoders, IMU; GNSS / LiDAR by scope	Source quality, calibration, frame alignment and behavior during degraded positioning.
Observation payload	RGB camera; optional thermal / other sensors	Viewing angle, vibration, illumination and task-specific evidence quality.
Onboard compute	Mission computer and drive interface	Power demand, thermal design, diagnostics and control deadlines.
Energy system	Battery management and service / charging arrangement	Mission load, reserve, return distance and recovery procedure.
Site communications	Wi-Fi / cellular options subject to coverage	Dead zones, uplink demand, authentication and command timeout behavior.

No fixed speed, runtime, range, payload, ingress rating or accuracy figure is asserted in this reference design. Request a configuration-specific specification and supporting test results.

05 / SOFTWARE & DATA

Connect observations
to decisions.

A useful integration preserves data meaning: where the observation happened, when it was captured, which mission it belongs to and whether an operator has reviewed it.

Interface	Information exchanged	Integration requirement
Vehicle → localization	Wheel feedback, inertial data and selected position inputs	Define coordinate frames and quantify uncertainty and data age.
Mission → drive control	Route segments and bounded movement requests	Constrain to approved lanes and require local authority checks.
Payload → event service	Observation metadata and evidence references	Separate candidate detections from reviewed incidents.
Operations → vehicle	Mission requests, pause / resume and diagnostics	Expose command acknowledgement and reject stale or unauthorized requests.

One event, an explicit lifecycle.

Captured locally
Queued for transfer
Received by the service
Acknowledged by an operator
Resolved with a recorded outcome

Retries should preserve the event identifier to avoid duplicate cases. A server receipt does not mean a human has acknowledged the event. Offline observations retain their original capture time.

ILLUSTRATIVE EVENT CONTRACT

{
  "event_id": "vehicle-example-001",
  "mission_id": "patrol-example",
  "platform": "vehicle",
  "captured_at": "2026-11-01T10:00:00Z",
  "location": {
    "frame": "site_map",
    "checkpoint": "review-zone"
  },
  "type": "observation_for_review",
  "evidence_ref": "access-controlled-reference",
  "delivery_state": "queued",
  "review_state": "unreviewed"
}

Example fields only. This is not a published API or live event.

Data handling is part of the design.

Access & authorization

Define operator roles, device identity and authenticated connections. Privileged commands need an audit trail and a clear authority model.

Retention & visibility

Agree which evidence is collected, who can see it and how long it is retained. Use restricted capture zones and masking where the site requires them.

Freshness & recovery

Mark stale telemetry visibly. Test reconnection, event de-duplication and expired-command rejection. Do not expose robot control interfaces directly to the public internet.

06 / OPERATING BOUNDARIES

Explain the exceptions.
Before they happen.

Normal operation is only part of the design. Agree what happens when the environment, position estimate, energy or communications no longer support the mission.

Condition	Proposed response	Acceptance evidence
Lane becomes obstructed	Stop and evaluate only approved alternate paths; otherwise request assistance.	Maintain clearance without entering an unvalidated surface or route.
Position sources disagree	Reduce operation or stop under the agreed confidence policy.	Log uncertainty and prevent unbounded continuation on an unreliable pose.
Remote communication fails	Apply the local controlled-stop policy and retain events for later transfer.	The dashboard indicates stale telemetry and prevents misleading live-state claims.
Energy reserve is reached	Abort the patrol and use the approved return or recovery procedure.	Return energy includes surface, payload and route effects; no range guarantee is inferred.

Private-site operating envelope

Public-road use, unrestricted mixed traffic and all-terrain operation are not established by this design.

Weather and ground variation

Ingress rating, temperature range, slope, traction and rain tolerance need configuration-specific evidence.

Localization quality

GNSS availability is not continuous everywhere. Define recovery for degraded or conflicting position sources.

Unspecified capacity

Range, speed, gradeability, runtime, payload and communication distance are not asserted here.

07 / COMMISSIONING & VALIDATION

From a reference design
to a tested installation.

Set acceptance thresholds before the pilot. Measure the agreed configuration under representative conditions and document the cases where it needs help.

01
Scope the site
Document the task, operating area, environment, users and intervention responsibilities.
02
Configure & integrate
Select the hardware and software, calibrate sensors and define interfaces and exception policies.
03
Run a controlled pilot
Test normal missions, false events, interruptions and recovery. Retain logs and operator observations.
04
Accept & maintain
Sign off measured results, train operators and schedule checks. Revalidate after material changes.

Measure	How to evaluate it	Test conditions
Coverage per mission	Completed zones / scheduled zones	Record missed zones and their causes.
Ground mobility	Successful runs across the agreed surface matrix	Separate dry, wet, sloped and obstacle cases where in scope.
Position confidence	Measured route error and recovery events	Test poor reception and wheel-slip scenarios.
Event quality	Reviewed true events, false alerts and missed test events	Use representative site footage and a documented labelling protocol.
Network resilience	Outage detection, stop behavior and eventual event delivery	Test dead zones and reconnection with duplicate-event handling.

Define pass / fail before testing.

For each measure, record the target, sample size, conditions, software version, hardware configuration and result. Targets are agreed with the customer; this document contains no benchmark results or promised performance levels.

What to bring to a scoping discussion

Provide a private-site map, surface and slope information, traffic rules, permitted lanes, payload expectations, network coverage and a recovery plan. Identify the operator responsible for interventions and incident review.

08 / TECHNICAL WHITE PAPER

Take the design
into your next discussion.

Download the complete reference: purpose, mission flow, architecture, interfaces, operating boundaries, test plan and sources.

Version 1.0 · 1 November 2026 · PDF

Download white paper ↓Read PDF in a new tab ↗

Technical sources & document scope

The architecture is a proposed engineering design, informed by the existing Xcugas platform descriptions and the technical sources below. External documentation describes component behavior; it does not establish a deployed integration or a performance guarantee.

Nav2: navigation servers ↗
Explains the separation of planning, control and recovery in a ROS-based navigation system.
ROS 2: quality of service ↗
Describes message delivery policies and publisher/subscriber compatibility.

Source review: 1 November 2026. Links may describe evolving software; pin and validate versions during implementation.

A LITTLE MORE CLARITY

Questions worth asking.

Can it operate on public roads?

This reference design is for controlled private sites. Public-road deployment requires a separately defined and assessed scope.

Does an unattended-object alert mean a threat was detected?

No. It is a candidate observation for an operator to review in context. The design does not infer intent or confirm danger from appearance.

Will it work on any terrain?

Surface, slope, traction, weather and payload conditions must be tested for the chosen chassis. The page does not claim unrestricted terrain capability.

Start something extraordinary

Your challenge.
Our next build.

Tell us what you want to make possible. Let's find the right hardware, connectivity and path forward.

hello@xcugas.com

OTHER SURVEILLANCE PLATFORMS