Containment

Andi Lamprecht ·2026-05-11· 4 min read· Accepted

Flight Containment

Jira ticket - UNCREW-2893

Context

When preparing for a flight, Uncrew shall encapsulate both the planned and contingency flight volumes within a single geofence in order to meet DU-SYS_44807-72 44807 verification.

In the context of this ADR and requirements, the Planned Volume (aka Operational Volume) is a 3D area where the UAV is expected to stay during normal, as-planned mission execution. Planned Volumes can be though of a 4D areas too, but this is out of scope in this ADR.

The Contingency Volume is the 3D area where UAV should (must) stay during normal operation or when in a contingency. A contingent UAV may seek to land in one of the designated contingency landing zones, de-tour to its destination, return home, crouch and many other.

We define a contingency landing zone (CLZ) as a pre-assigned 2D point where it will be safe to land.

A geofence is a geometry that constrains the position of the UAV. It can be a 3D structure conceivably, but in PX4 it is - much like a human fence - 2D.

Contingency planning aims to prevent emergencies. An emergency is a catastrophic loss of control over the UAV where options tend to be limited to landing in place or popping the parachute.

Decision

Onboard

Before the mission starts, Uncrew onboard components shall:

• Calculate the operational volume by buffering the flight path with the radius packaged with definition of the upcoming mission.
• Calculate the contingency volume by finding the convex hull of the operational volume together with the contingency landing zones (CLZs) that can optionally be packaged within the same mission definition.

Submit the resulting contingency volume as a PX4 geofence.

To faithfully implement DU-FRQ-309 the pathfinder would need to be given the contingency volume as a constraint (when planning contingent paths, e.g.: to a CLZ). Yet, safer paths may exists outside of this volume, so DU-FRQ-309 may need rethinking/qualifying or we may need to calculate the contingency volumes more generously.

We may pass the CLZs as Rally Points to PX4, but we shouldn’t ask PX4 to act on them before we exhaust our options seeking safe paths with the pathfinder.

Offboard

We put Missions Service in charge of selecting CLZs. Initially in may just put all the available CLZs (the resulting contingency volume will be very generous, but it will technically contain the operation and fulfil DU-FRQ-309). With time we can have Missions Service only select the nearest (and 2nd nearest) CLZs. Those can be spatially nearest or pathfinder nearest (i.e.: safest among the near ones). Pathfinder can run in a flood mode, i.e.: it can be asked to flood an area and produce a cost raster. CLZs can be selected within that raster and can inform the CLZ selection.

Alternatives Considered

Calculate Contingency Volume Offboard

We thought about having the Missions Service calculate the contingency volume. It does after all package missions for execution and it communicates the operational volume with the UTM. However:

• Missions Service sends the UTM the operational volume expressed in terms of waypoints and buffer radius. This is also what this ADR proposes that Missions Service sends to the UAV.
• Missions Service is written in golang and it lacks robust geospatial library. Meanwhile we have a very good (Boost-based) C++ geospatial library.
• Had Missions Service calculate the contingency volume, it still has to pass the CLZs to the UAV. That’s redundant info as CLZs are inputs to contingency volume calculation.

Restricted Airspace

We considered adding restricted airspace to the contingency volume. That way the resulting geofence would prevent the UAV from entering such airspace. We’ve abandoned this idea firmly putting the pathfinder in charge in of calculating contingent paths and thus obeying up-to-date restrictions.