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

This section develops aerial safety, regulation, and simulation as a concrete embodied AI skill rather than a label. 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.

For Safety, regulation, and simulation for aerial agents, check the earlier frame, control, and model chapters against the exact interface used here: state variables, timing budget, action limits, and evaluation panel.

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

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 naturally 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.

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 that minimally adjusts the autonomy command, letting the policy do what it wants whenever it is safe and intervening only at the margin. Above these two layers sit discrete return-to-home (RTH) triggers: low battery, lost data link, GPS or estimator failure, or geofence breach each map to a fallback (hold, land, or return), with priority so the most urgent fault wins.

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.

Practical Recipe

1. Write the skill contract: observable variables, action interface, metric, allowed recovery actions, and stop conditions.
2. Build the smallest baseline that can fail in an interpretable way.
3. Run the maintained library version with the same inputs, scenarios, and metric code.
4. Add one perturbation aimed at the expected failure: a simulator pass ignores the regulatory constraint that defines the real mission.
5. Save one artifact containing config, seeds, logs, summary metrics, and two representative traces.

Safety, regulation, and simulation for aerial agents becomes robust when the chapter separates three claims. The conceptual claim explains why the skill should work. The systems claim explains which interface changes. The evidence claim records which same-panel metric would convince a skeptical builder.

For Safety, regulation, and simulation for aerial agents, 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.