A Fence Nobody Can See

Geofencing is the software layer that decides where an aircraft is allowed to be and stops it going anywhere else. Done well it is invisible, because the aircraft simply behaves. Done badly it is why a drone stops dead in a 20 mph crosswind, gets pushed backward into a tree, or why a public safety crew cannot launch over the incident they were called to.

For a manufacturer it sits in an awkward place. It is not mandated in the US the way Remote ID is, so nobody hands you a specification. But customers ask for it, liability arguments assume it, several export markets require geo-awareness, and any operator flying near airports wants the aircraft to enforce its own limits.

Under the Hood: Polygons, Indexes, and Braking Distance

The core data structure is a set of prisms: a polygon on the ground, a floor and ceiling in altitude, and an optional time window. On every control loop the aircraft asks whether its projected position is inside any of them. Three engineering problems fall out of that.

  • Scale. A national airspace dataset is thousands of polygons, some with hundreds of vertices. Point-in-polygon against all of them at 50 Hz on a microcontroller is not viable. The answer is a spatial index, a coarse tile or geohash lookup that cuts the candidate set to a handful before any exact test runs, with the full dataset compressed in flash and only local tiles in RAM.
  • Geometry. A polygon in latitude and longitude is not a polygon in meters. Working in a local tangent-plane frame is accurate and cheap; naive planar math on raw degrees produces errors that grow with latitude and will fail an audit.
  • Momentum. A quadrotor at 15 m/s with 3 m/s2 of braking needs about 37 m to stop, plus control latency. Checking containment against current position means the aircraft exits the boundary every time. The check must run against a predicted position, projecting velocity forward by the stopping distance and a margin.

That prediction is what makes a soft wall possible, and soft walls separate usable systems from dangerous ones. Instead of a binary stop, compute distance to the nearest boundary and clamp commanded velocity in that direction as a function of it: full speed far away, tapering to zero at the fence. The aircraft decelerates smoothly and leans on the boundary rather than slamming to a stop. In wind the controller must keep authority to push back inward, so clamp the outward component only.

The Restriction Types You Have to Model

Teams build one polygon type and discover the rest in the field. Model these from the start.

Inclusion zones keep the aircraft inside an operator-defined work site or range boundary. Exclusion zones keep it out of airport surfaces, critical infrastructure, and restricted airspace. Altitude ceilings vary by cell, mirroring the gridded limits published for controlled airspace, so a fence is not one number across a metro area. Time-bounded restrictions around stadiums, wildfires, and VIP movements appear with hours of notice and expire. Advisory zones warn without enforcing, the right treatment for any data your source cannot fully vouch for. And ground-only restrictions, since a no-takeoff rule differs from a no-fly rule and needs its own check before arming.

Where the Logic Has to Live

Geofencing enforced by the ground control app is not geofencing. It is a suggestion that disappears when the link drops or the operator switches software.

The authoritative check belongs in flight controller firmware, below the mission layer, where arming checks and failsafes live. A companion computer can hold the full dataset and do the heavy lifting, but the flight controller must keep a minimal independent fence, at least the active local tiles and the mission boundary, enforced even if the companion stops responding. That partitioning is a real criterion when choosing a drone flight controller, since a controller with no flash headroom for airspace data forces the architecture.

Implement enforcement as an explicit mode machine, not conditionals sprinkled through the control loop. Normal, approaching, contained, breached, and returning are distinct states with defined transitions, per state machines in firmware. Systems that fail in the field fail on a transition nobody enumerated.

When Position Goes Away

Every geofence depends on knowing where the aircraft is, and the hardest design question is what to do when it does not.

The naive implementation disables the fence when the fix degrades, which is backward: the aircraft is least trustworthy when the constraint matters most. Use the uncertainty instead. Inflate the fence inward by the current uncertainty estimate, so a degraded fix shrinks the usable area rather than removing the fence, and past a threshold transition to a conservative state.

Spoofing needs separate handling, since a spoofed receiver reports a confident fix that is false. Cross-checking GNSS against inertial dead reckoning, barometric altitude, and optical flow catches the discontinuity when a spoofed position jumps. That work overlaps heavily with GPS-denied drone navigation.

Keeping the Data Current and Trustworthy

Airspace is not static. Temporary restrictions appear daily, and a dataset a month old is misleading. The ground station has to pull current data and push it before flight, with the aircraft logging the dataset version so any later question about what it knew has an answer. Updates must be atomic, since a half-written airspace file is worse than a stale one, and signed, since a dataset an attacker can rewrite is a fence an attacker controls. The mechanisms are those behind OTA firmware updates and secure boot and firmware encryption, and airspace data should ride the same signed channel.

The same infrastructure handles authorized override. Public safety agencies and holders of an airspace authorization need to fly inside blocked zones. Implement that as a signed unlock bound to a specific aircraft, polygon, and time window, logged on use, never as a settings toggle or a debug build. Aircraft publishing identity under FAA Remote ID already carry most of the plumbing an unlock scheme needs.

Testing a Boundary You Hope Never Gets Hit

Geofence bugs surface in situations you cannot easily arrange: high wind, degraded GNSS, dense polygon overlap, a restriction activating mid-flight. Simulation is not optional. A software-in-the-loop rig flies thousands of approach vectors against a real dataset overnight, and a hardware-in-the-loop bench runs the same scenarios against production firmware on the real board, as in hardware-in-the-loop testing. Reserve flight testing for confirming what simulation proved, and always test the ugly cases: maximum speed with a tailwind, boundaries that touch, and a fence activating while the aircraft is inside it.

Design the Fence With the Flight Stack

Projects House builds containment and airspace logic into UAS firmware: polygon indexing on constrained hardware, predictive soft walls, degraded-navigation behavior, signed dataset updates and overrides, and the simulation rig to prove it works. Describe your aircraft through our contact form.