Section 47.5: Safety, regulation, and simulation for aerial agents

"A failsafe you have never triggered is a hypothesis, not a guarantee."

A Careful Control Loop

A policy that passes every simulation check but has never faced a real geofence, a real wind gust, or a real battery sag is a candidate, not a system. This section develops aerial safety, regulation, and simulation as a concrete embodied AI skill rather than a label. Figure 47.5A sketches the three layers this requires: a geofence constraint layer that overrides the learned policy near a no-fly zone, a regulatory compliance checker that validates the planned path against airspace rules, and a safe-landing trigger that activates at a critical battery threshold. The core contract is: observe geofence, altitude, failsafe, airspace constraints, and weather, test autonomy inside operational limits before hardware flight, and judge the result with violation count and emergency recovery success.

Aerial safety reuses the same interface the earlier frame, control, and model chapters define: state variables, timing budget, action limits, and evaluation panel. The constraint layers here plug into that interface rather than replacing it.

Figure 47.5.1 makes the safety contract explicit by separating regulatory envelope, geofence monitor, detect-and-avoid logic, simulator evidence, operator override, and post-intervention state.

Theory

Before any autonomy policy runs, it must operate inside a hard spatial envelope that reflects both physical limits and legal requirements. In the United States, FAA Part 107 restricts recreational and commercial small Unmanned Aircraft Systems (UAS) to below 400 ft Above Ground Level (AGL), roughly 120 m. The rules also require visual line of sight and keep the aircraft out of controlled airspace unless the operator obtains a Low Altitude Authorization and Notification Capability (LAANC) authorization. DJI encodes similar boundaries into its GEO 2.0 system. The firmware refuses takeoff inside a No-Fly Zone and cuts maximum altitude automatically near airports, independent of whatever the flight app requests. The lesson: regulatory compliance is not a software feature you toggle on before release. It is a constraint you bake into every layer of the autonomy stack from the first prototype flight. Teams that catch a geofence violation in simulation typically fix it in minutes. The same violation on a real aircraft over a populated area can ground the entire program for months. This is why we call it the validate-in-sim-or-pay-in-hardware rule. Simulation typically surfaces the large majority of constraint violations before a single outdoor flight (practitioner reports from commercial UAV programs as of 2023-2024 commonly cite figures above 90%, though these figures are self-reported and vary with how aggressively a team simulates edge cases). To feel the scale difference concretely: a constraint bug that takes 3 simulation episodes to reproduce and 20 minutes to fix takes roughly 50 outdoor test flights, FAA coordination, site permits, and weeks of scheduling to encounter in the field.

Those regulatory limits only bite once they are expressed as something the flight software can check every tick, which is exactly what the constraint formalism below provides. Safety for an autonomous drone is enforced by hard constraints that sit underneath the autonomy stack and cannot be overridden by a confident policy. The most common is the geofence, a permitted region of space. A convex geofence is written as a polytope, an intersection of half-spaces:

$$\mathcal F = \{\, \mathbf x \in \mathbb R^3 : A\mathbf x \le \mathbf b \,\}.$$

Each row of \(A\mathbf x \le \mathbf b\) is one boundary plane (north, south, floor, ceiling, and so on), so a candidate position is legal exactly when every row holds. Checking membership is a single matrix-vector compare, which is cheap enough to run every control tick.

From static fence to dynamic barrier

A geofence only tells you whether you are inside; it does not stop you from flying out at speed. A control barrier function (CBF) makes safety dynamic. Define a scalar \(h(\mathbf x)\) that is positive inside the safe set and zero on its boundary. Safety is forward-invariant if the control keeps

$$\dot h(\mathbf x) + \alpha\,h(\mathbf x) \ge 0,$$

for some \(\alpha > 0\). As \(h \to 0\) (approaching the boundary) the inequality forces \(\dot h \ge 0\), so the system is pushed back before it crosses. In practice this becomes a constraint in a small quadratic program (QP, an optimization that finds the command closest to the one requested while satisfying a set of linear and quadratic constraints) that minimally adjusts the autonomy command, letting the policy do what it wants whenever it is safe and intervening only at the margin.

RTH triggers matter because aerial robots cannot pause indefinitely. A hovering quadrotor drains roughly 100 W continuously, so every fault must resolve within the remaining energy budget. The choice of fallback is a real-time physical commitment. A missed or delayed trigger turns a recoverable fault into a crash. The flight controller must therefore make the decision autonomously, without waiting for operator input.

The mechanism is a ranked priority table: each fault condition maps to a severity level and a fallback action. When multiple faults fire simultaneously, the table resolves to the highest-severity response. Low battery triggers a timed RTH; lost data link escalates to immediate RTH; GPS failure drops to hold-and-descend because flying home without position fix risks collision. The flight controller polls each condition every control tick and latches the winning action until the fault clears or the vehicle lands.

Worked Example

Encode a rectangular geofence as a polytope \(A\mathbf x \le \mathbf b\) and test candidate waypoints against it. The box allows 0 to 50 m in \(x\) and \(y\) and 0 to 30 m in altitude. Beyond a simple inside/outside flag, we also report the signed margin, the distance to the nearest boundary, which is the quantity a CBF would drive to stay non-negative.

# Rectangular geofence membership test via a convex polytope A x <= b.
import numpy as np

# Box: 0 <= x <= 50, 0 <= y <= 50, 0 <= z <= 30  (meters).
A = np.array([[ 1, 0, 0], [-1, 0, 0],
              [ 0, 1, 0], [ 0,-1, 0],
              [ 0, 0, 1], [ 0, 0,-1]], dtype=float)
b = np.array([50, 0, 50, 0, 30, 0], dtype=float)

def check(x):
    slack = b - A @ np.asarray(x, dtype=float)   # >= 0 on every row means inside
    return bool(np.all(slack >= 0)), float(slack.min())  # (inside?, margin to nearest wall)

for wp in [(25, 25, 15), (55, 25, 15), (25, 25, 32), (2, 2, 1)]:
    ok, margin = check(wp)
    flag = "OK" if ok else "VIOLATION"
    print(f"waypoint {wp!s:>14} -> {flag:9s} margin = {margin:+.1f} m")

Expected output: a pass or fail per waypoint plus a signed margin. The margin is the evidence field that matters: a binary inside/outside test fires too late, while the continuous margin lets the safety layer slow the vehicle as it approaches a wall instead of slamming a hard stop at the boundary.

The signed margin the worked example just computed is the raw signal the following validation loop consumes, so the recipe below turns that per-waypoint number into a repeatable simulation campaign before any hardware flight.

Practical Recipe

1. Instantiate the geofence polytope \((A, \mathbf{b})\) from the actual LAANC authorization bounding box or the DJI GEO 2.0 No-Fly Zone boundary for your test site, not a hand-drawn box. Import it into gym-pybullet-drones via the geofence_vertices parameter of CtrlAviary, or into safe-control-gym's task_config YAML as the constraints list with type: geofence.
2. Run 200 episodes in simulation at 240 Hz physics timestep (the default in gym-pybullet-drones) with a random wind disturbance sampled from a Dryden model (a standard stochastic turbulence model that generates gust velocities with realistic frequency content for flight simulation) at turbulence intensity light (sigma_w = 1.5 m/s, the standard deviation of the vertical gust velocity component). Record the geofence violation rate and the fraction of RTH triggers that successfully landed within 2 m of the home position without secondary fence breaches.
3. Inject the three most common real-world failure triggers: (a) GPS denial causing a 0.5 m/s position drift in the state estimator, simulated by adding Gaussian noise to the Extended Kalman Filter (EKF) position output; (b) battery voltage sag that compresses the RTH decision window from 90 s to 40 s; (c) a conflicting failsafe in which the RTH climb altitude of 30 m AGL exceeds the regulatory ceiling of 25 m AGL. Verify the priority table resolves conflict (c) by refusing RTH and holding in place rather than climbing through the ceiling.
4. Transfer the validated policy to hardware only after the geofence violation rate across the 200-episode simulation panel is zero and RTH success exceeds 95%. Log the PX4 ULog file from the first five outdoor flights and compare the in-flight CBF margin trajectory against the simulation margin trajectory to detect sim-to-real gap in wind response.
5. Save one artifact per campaign: the task_config YAML, episode seeds, the ULog or DataFlash file for each hardware flight, the margin vector \(\mathbf{m}\) across all simulation episodes, and the two worst-margin simulation traces for post-hoc CBF tuning.

Aerial safety becomes robust once you separate three claims: the conceptual claim (why the skill should work), the systems claim (which interface it changes), and the evidence claim (which same-panel metric would convince a skeptical builder). Conflate them and a passing demo hides which one you have not actually earned.

Keep flight physics, airspace constraint, battery state, timing, wind, and safety monitor inside the evidence artifact rather than in a post-run explanation.

When Safety, regulation, and simulation for aerial agents fails, do not collapse the whole method into one score. Assign the failure to a subsystem, rerun one perturbation that isolates the suspected cause, and keep the trace as a reusable diagnostic case.