Create 0017-fence-altitude.ms #29
Conversation
Proposal for adding minimum and maximum altitude to fences.
text/0017-fence-altitude.md
Outdated
| Create a new fence item type that records minimum altitude and maximum altitde 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 differnt frame (e.g. AGL) from the maximum altitude frame which might be AMSL. |
There was a problem hiding this comment.
Can you add a reason why you wouldn't want to go with this approach?
There was a problem hiding this comment.
I would, but someone (@hamishwillee ?) seemed to think it would be a big deal since it would involve adding another parameter.
There was a problem hiding this comment.
I don't remember saying that, but it is a "tradeoff". See above https://github.com/mavlink/rfcs/pull/29/files#r2434231438
Note, I don't "decide" what is an acceptable tradeoff - I'm just throwing options at you. When we all agree what we think is best we present these options (as you have have done) and negotiate with key stakeholders in PX4/ArduPilot to see if we can get agreement. For ArduPilot PeterB is a good litmus test.
Add a reference to TC regulations for containment
Fixed the link to the TC standard 922
I guess I should mention it's Canadian regulations
Improve clarity. Co-authored-by: Hamish Willee <[email protected]>
| ## 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. |
There was a problem hiding this comment.
@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.
4 participants
Proposal for adding minimum and maximum altitude to fences.
For discussion