Skip to content
ARGUS User Manual

Geofence safety envelope

Geofences keep aircraft inside the area you authorised them to operate in and out of areas you did not. ARGUS enforces them at three independent layers, on the principle that a single defence can fail but three rarely do at once.

The three layers

1. App layer — client-side clipping

The ARGUS web app is the first line of defence. Every DRC stick input, every keyboard nudge and every waypoint insertion is checked against the loaded geofence polygons before it leaves your browser:

  • No-fly zones (nofly) — the drone must not enter the polygon.
  • No-landing zones (nolanding) — the drone may overfly but must not descend below landing-commit altitude inside.
  • Stay-inside boundaries (geofence) — the drone must remain inside the polygon.

When a stick input would push the aircraft across a boundary, the client clips the violating component and the HUD’s velocity bar flashes red on the clipped axis. A breach also emits a master caution alert — critical for no-fly, warning for no-landing and boundary exits — with a 10-second cooldown per zone to avoid alert storms.

Waypoint plans run through the same check in the mission wizard and offending waypoints are flagged before the plan can be saved.

2. Gateway layer — argus-android tablet

Every flight-control packet passes through the argus-android tablet bound to the remote controller. The tablet re-runs the polygon test against its own copy of the zones, pulled live from the ops doc. If the web client’s check was bypassed — tampered JS, stale polygons, network race — the tablet rejects the packet before it reaches the remote controller’s command loop.

3. Flight controller — DJI FlySafe

For DJI docks and compatible aircraft, zones are also pushed down as custom flight areas through FlySafe geofence sync. FlySafe runs inside the aircraft’s flight controller itself. Even if the tablet loses signal and the web app is offline, the aircraft refuses to cross a no-fly boundary and will hover at a stay-inside boundary until operator input brings it back.

Why three layers

App-layer alone assumes a trustworthy client. Gateway-layer alone assumes the tablet is online and up to date. Aircraft-layer alone assumes the zone was synced before the flight. Any single layer can fail silently — stacked, they cover each other’s gaps.

Monitoring in flight

The map panel renders active zones with their fill colour and the ops toolbar exposes a breach counter. If any aircraft is currently inside a no-fly zone or outside its boundary, the counter turns red and the zone highlights pulse until the breach clears. Every breach and clear is written to the blackbox as geofence_breach / geofence_exit events.

Emergency suspend

In rare SAR scenarios you may need to fly into an otherwise no-fly zone (for example a TFR around an active incident that you are authorised to enter). Suspend is not a one-click action. It requires:

  1. A commander on the operation to request the suspend, naming the zone and a reason.
  2. An organisation admin to co-sign within a short time window.
  3. A reason string that is written to the audit log.

While suspend is active, only the specified zone is relaxed at the app and gateway layers. The aircraft-layer unlock requires a FlySafe unlock licence and is tracked separately. The suspend expires automatically at the end of the operation; it cannot outlive the op.

Clearing breaches

If the drone re-enters a stay-inside boundary or exits a no-fly zone the monitor emits a clear event, drops the breach from the active set and writes a geofence_exit or geofence_boundary_enter entry to the blackbox. You do not need to acknowledge clears — they are purely informational.