Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions text/0017-fence-altitude.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
Start date: 2025-10-08
Contributors: Tim Tuxworth
RFC PR: mavlink/rfcs#17

# Summary

Allow polygon and circle fences to include minimum and maximum altitude in a specified frame

# Motivation

With new (as at 2025) regulations coming into force for BVLOS flying in Canada, requiring Detect and Avoid capabilities, drones must be capable of flying within regulated airspaces which are typically specified as horizontal limits with altitude boundaries, and avoiding known fixed obstacles such as cell towers, buildings or electrical power lines, which have a limited specific height.

The regulations refer to [Transport Canada Standard 922](https://tc.canada.ca/en/corporate-services/acts-regulations/list-regulations/canadian-aviation-regulations-sor-96-433/standards/standard-922-rpas-safety-assurance), and in particular 922-008 Containment.

# Detailed Design

Existing messages for fence items will use existing unused parameters for minimum and maximum altitude and a single parameter for the frame.
For example:

MAV_CMD_NAV_FENCE_POLYGON_VERTEX_INCLUSION (5001)

Param (Label) | Description | Values
--- | --- | ---
1 (Vertex Count) | Polygon vertex count. Number of vertices in the current polygon (all vertices will have the same number). | min: 3 inc: 1
2 (Inclusion Group) | Vehicle must be inside ALL inclusion zones in a single group, vehicle must be inside at least one group, must be the same for all points in each polygon | min: 0 inc: 1
3 (Min Altitude) | Minimum altitude for the fence. | NaN for "does not apply" (all the way to the ground). Frame according to MISSION_ITEM_INT.frame by default and param4 if defined. |
4 (Frame) | The MAV_FRAME to use for Min Altitude (param3) if the default is not used | MAV_FRAME_GLOBAL is default frame. |
5 (Latitude) | Latitude |
6 (Longitude) | Longitude |
7 (Max Altitude) | Maximum altitude for the fence. Frame defined by MISSION_ITEM_INT.frame | NaN for "infinite" (or max=min=0)

For consistency, in all MAV*CMD_NAV_FENCE* messages: param 3 will be minimum altitude, param 7 will be maximum altitude. The default frame for both with be defined in MISSION_ITEM_INT.frame. If param3 and param4 have different frames then param 4 will define the frame for the minimum altitude (param 3).

# Alternatives

Create a new fence item type that records minimum altitude and maximum altitude with a different frame allowed for minimum and maximum (a real world use case). This would require each horizontal limited
fence to be matched with "altitude limit" fence items. This would be challenging for GCS to implement.

Add new values to fence items to allow for another frame type value to be added, to allow for a minimum fence to have a different frame (e.g. AGL) from the maximum altitude frame which might be AMSL.

## Separate altitude setting command

Use another command that allows the altitudes for the previous fence point to be set each fence, which might look like this: `MAV_CMD_NAV_FENCE_ALTITUDE`:

Param (Label) | Description | Values
--- | --- | ---
1 (Max Altitude) | Maximum altitude for the fence. Frame defined by MISSION_ITEM_INT.frame | NaN for "infinite" (or max=min=0)
2 (Min Altitude) | Minimum altitude for the fence. | NaN for "does not apply" (all the way to the ground). Frame according to MISSION_ITEM_INT.frame by default and param3 if defined. |
3 (Frame) | The MAV_FRAME to use for Min Altitude (param3) if the default is not used | MAV_FRAME_GLOBAL is default frame. |

The main advantage of such an approach is that it more safe.
- If altitudes are not understood on a fence definition a flight stack **should** reject the fence plan.
- With the current proposal an older flight stack will likely accept the command with altitude, but not act on it. This will be non-compliant, and potentially dangerous.

The main disadvantage is that the the altitudes are separated from the point definition, and hence the FC must process multiple points to know how the fence behaves, and as a reader it is not so easy to work out what each point does.
Comment on lines +41 to +55
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@timtuxworth (and @Ryanf55 ). We discussed this RFC in the MAV call 20251105

This alternative was suggested by @julianoes - note that this has a clear advantage over what is proposed, which is that it is safer given the new command would force the fence plan to be rejected if not supported by flight stack.
IMO this is a real and significant safety issue.

We could add the same guarantee to the current approach with new fence item names (otherwise defined as above but we could actually insist on NAN).
I tend to think this is actually the right way forward.

Thoughts?

Other than that we can only be sure that this makes sense by prototyping, so once we've agreed the path forward next step is to create a PR for the updates.