ardupilot
ardupilot copied to clipboard
ArduPilot
Copter Fence Fixes
Separated out from https://github.com/ArduPilot/ardupilot/pull/25698
- Implements Min Alt fence on copter
- Adds support for auto-enabling fence floors on copter
- Messages correctly about fence breach / enablement
- Auto-disable floor fence on landing on copter
- Always checks breaches regardless of manual recovery state - means the scripting API is up-to-date
- Prevent manual recovery logic from engaging when no fence action has been set - allows better control from scripting
- Implements FENCE_AUTOENABLE for copter
- Implements FENCE_OPTIONS for copter
Here is an attempt at describing what this is supposed to do:
- A fence is a 2D plane in 3D space separating "inside" the fence from "outside" the fence
- A fence can be in one of four incremental states (so e.g. a fence can only be active if it is already configured):
- Unconfigured - the fence is unavailable for use in any way
- Configured - the fence is able to be activated by some activation mechanism
- Active - the fence is active and will be put into the breached state if the vehicle is "outside" the fence
- Breached - the fence is active, the vehicle is "outside" the fence and any breach action will be taken
- The state of each fence is fully independent of all of the others
- A fence is configured by setting the appropriate bit in FENCE_TYPES
- Fences come in two categories - Normal and Auto. By default Max Alt, Circle and Poly fences are considered Normal fences and Min Alt is considered an Auto fence.
- A fence is activated by one of the following mechanisms:
- Setting FENCE_ENABLE to 1 activates all configured normal fences
- Setting FENCE_ENABLE to 1 activates all configured auto fences when their autoconditions become true
- Setting an RC switch, configured with option 11 (FENCE), high activates all configured fences
- Sending the mavlink message MAV_CMD_DO_FENCE_ENABLE actives all fences specified in the message
- If FENCE_AUTOENABLE is set to some value causes all normal fences to become auto fences that are activated when their auto conditions become true
- A fence is de-activated by one of the following mechanisms:
- Setting FENCE_ENABLE to 0 de-activates all configured fences
- Setting an RC switch, configured with option 11 (FENCE), low de-activates all configured fences
- Sending the mavlink message MAV_CMD_DO_FENCE_ENABLE de-actives all fences specified in the message
- An automatic landing (RTL in Copter and in Plane if certain options are set, LAND, land in AUTO) will disable all auto fences and ignore all breach actions
- The following auto-conditions are available:
- Ascending above Min Alt by default
- On arming via FENCE_AUTOENABLE
- On auto takeoff via FENCE_AUTOENABLE
- The execution of a breach action prevents the execution of any further breach action until the breach action is completed or pilot changes mode or disarms
Requires https://github.com/ArduPilot/mavlink/pull/349
Just to try and capture what @rmackay9 would like - he would prefer that we auto-disable the floor fence as we go through it on a land/RTL action rather than leaving the fence enabled and ignoring it
Trying to write down some rules here, as this stuff is convoluted ...
- Fence presence (FENCE_TYPE) means a fence is eligible to be enabled, but nothing more
- Fence enablement (FENCE_ENABLE) means a fence is active and will take action if breached. We currently have no way of selectively enabling but I am beginning to think we should.
- Fence breach (get_breaches()) means a present and enabled fence has been breached. Breaches should always be correct, if you want to suspend a fence (e.g. to land) then it should be disabled.
- Fence auto-enablement (FENCE_AUTOENABLE) allows present fences to be automatically enabled and disabled under certain conditions - on arming, on takeoff, on landing. It's not clear why auto-enablement of anything other than floor fences makes sense. Auto-enablement also suffers from memory loss - if a fence is auto-enabled and then directly enabled via mavlink (as we do in the tests), what happens when you land - should the (non-floor) fence be disabled or enabled?
- Certain modes (RTL descent, Land, Auto) will automatically disable fences for landing so that they can land with a floor fence. It's not clear why this should be anything other than the floor fence.
- Fences can be enabled and disabled via mavlink. Initially this was all fences, but more recent changes allow the floor fence to be switched off only. I am planning to add an option that does the opposite - allows all fences to be enabled except the floor.
The current behaviour is confusing and inconsistent because sometimes all fences are automatically disabled to take an action when only the floor fence needs to be disabled, similarly current behaviour ignores breached floor fences in certain (landing) circumstances. In order to get consistency I think we need individual control over presence (OK), enablement (MISSING) and breaches (OK). This means turning the enabled flag into a bitmask.
"Fence enablement (FENCE_ENABLE) means a fence is active and will take action if breached. We currently have no way of selectively enabling but I am beginning to think we should." is untrue ....if _floor_enable is false the ALT_MIN fence is disabled...currently starts in this state after boot even if FENCE_ENABLE is true at boot...takes a direct action to enable it or AUTOENABLE condition get floor enabled...
Personally, I think:
- We should have the fence enable/disable AUX function have a bit mask variable for what it controls. The same for MAVLink fence command.
- We should have auto enable and disable functions of ALT_MIN that can be called from takeoff and landing code. I am not sure why you would ever NOT want to disable the ALT_MIN fence on an auto landing...its a pilot control protection I think
- We should have a fence option to disable horizontal fences during breach actions (RTLs) Plane just ignores breaches during breach recovery actions, but doesn't clear the breach...we should prevent a breach by allowing a temporary disable with auto-re-enable if breach action abort or when changing mode to re-takeoff
- I can see the need for selectively auto-enabling non ALT_MIN fences on arming (to move out of an exclusion zone like pit area without breaching), but why its needed otherwise I am not sure. If we just enable the ALT_MIN once its reached, disable on auto landings, and re-enable once another climb above it occurs. Maybe we can deprecate the FENCE_AUTOENABLE and replace with a FENCE_OPTION for autoenabling non-ALT_MIN fences on arming. Not sure why you need the enable on takoff if you have the enable on arming. And making ALT_MIN autoenable removes the need for the normal enable on takoff.
"Fence enablement (FENCE_ENABLE) means a fence is active and will take action if breached. We currently have no way of selectively enabling but I am beginning to think we should." is untrue ....if _floor_enable is false the ALT_MIN fence is disabled...currently starts in this state after boot even if FENCE_ENABLE is true at boot...takes a direct action to enable it or AUTOENABLE condition get floor enabled...
_floor_enabled is not a parameter, so there is some indirect stuff going on, but nothing that allows you to directly enable or disable individual fences
Personally, I think:
* We should have the fence enable/disable AUX function have a bit mask variable for what it controls. The same for MAVLink fence command.
Yes, 100% agree
* We should have auto enable and disable functions of ALT_MIN that can be called from takeoff and landing code. I am not sure why you would ever NOT want to disable the ALT_MIN fence on an auto landing...its a pilot control protection I think
Yes agree, auto enable of anything else seems a bit suspect to me
* We should have a fence option to disable horizontal fences during breach actions (RTLs) Plane just ignores breaches during breach recovery actions, but doesn't clear the breach...we should prevent a breach by allowing a temporary disable with auto-re-enable if breach action abort or when changing mode to re-takeoff
Yes, so this is not possible without finer grained control of enablement - bu I agree this is a good way forward
* I can see the need for selectively auto-enabling non ALT_MIN fences on arming (to move out of an exclusion zone like pit area without breaching), but why its needed otherwise I am not sure. If we just enable the ALT_MIN once its reached, disable on auto landings, and re-enable once another climb above it occurs. Maybe we can deprecate the FENCE_AUTOENABLE and replace with a FENCE_OPTION for autoenabling non-ALT_MIN fences on arming. Not sure why you need the enable on takoff if you have the enable on arming. And making ALT_MIN autoenable removes the need for the normal enable on takoff.
Agree about simplifying, still not quite sure what the correct mix is
I have turned FENCE_ENABLE into a bitmask and it makes everything much easier.
I think this is good, not recording an ALTMIN breach if not enabled....and having a configured ALT_MIN fence always autoenable (if not enabled by FENCE_ENABLE but configured in FENCE_TYPE) upon reaching the alt, and reenabling after a landing module disables it for landing if below the alt and a mode change occurs.....but we should also deprecate AutoEnable and convert "3" to setting a new FENCE_OPTIONS bit to enable all non MIN_ALT configured fences on arming, which would not be the default for the option bit This will fix many problems in Plane and still function as desired (but better really)
@andyp1per here are my comments(in bold) on your revised version of my behavior spec sheet:
-
A fence is a 2D plane in 3D space separating "inside" the fence from "outside" the fence (fences can be inclusion or exclusion)
-
A fence can be in one of four incremental states (so e.g. a fence can only be active if it is already configured): A. Unconfigured - the fence is unavailable for use in any way B. Configured - the fence is able to be activated by some activation mechanism C. Active - the fence is active and will be put into the breached state if the vehicle is "outside" the fence outside only applies to inclusion polygon or tincan D. Breached - the fence is active, the vehicle is "outside" the fence and any breach action will be taken
-
The state of each fence is fully independent of all of the others
-
A fence is configured by setting the appropriate bit in FENCE_TYPES
-
Fences come in two categories - Normal and Auto. By default Max Alt, Circle and Poly fences are considered Normal fences and Min Alt is considered an Auto fence.
-
A fence is activated by one of the following mechanisms: A. Setting FENCE_ENABLE to 1 activates all configured normal fences B. Setting FENCE_ENABLE to 1 activates all configured auto fences when their autoconditions become true C. Setting an RC switch, configured with option 11 (FENCE), high activates all configured fences D. Sending the mavlink message MAV_CMD_DO_FENCE_ENABLE actives all fences specified in the message E. If FENCE_AUTOENABLE is set to some value causes all normal fences to become auto fences that are activated when their auto conditions become true
-
A fence is de-activated by one of the following mechanisms: A. Setting FENCE_ENABLE to 0 de-activates all configured fences B. Setting an RC switch, configured with option 11 (FENCE), low de-activates all configured fences C. Sending the mavlink message MAV_CMD_DO_FENCE_ENABLE de-actives all fences specified in the message D. An auto-landing (RTL, LAND, land in AUTO) (RTL is not an autoland and does not call the method) will disable (deactivate) all auto fences and ignore all breach actions ignore a breach is currently plane behavior but the breach should never occur if a fence is inactive this is a behavior change for plane which can selectively only disable MINALT MINALT deactivation due to method call for fence de-activations should not prevent reactivating automatically after autoland completes on the next takeof ifFENCE_AUTOENABLE is 0 and was activated by switch or MAVLink
-
The following auto-conditions are available: A. Ascending above Min Alt (for MINALT fence only) B. On arming (all fences) C. On auto takeoff completion this is a method call from vehicle code (All fences)
-
The execution of a breach action prevents the execution of any further breach action by de-activating fences until the breach action is completed or pilot changes mode or disarms
So what happens if FENCE_ENABLE = 1 and an RC option 11 is set and then the switch is flipped (either on or off)? I'm not being flippant here - this is currently very confusing, and this doesn't seem clarify or deal with it. A similar question applies if FENCE_AUTOENABLE = 1 and the RC switch is flipped a) before the autoenable is triggered, or b) after the autoenable is triggered.
What is the expected behavior in these cases?
Also regarding
- A fence is a 2D plane in 3D space separating "inside" the fence from "outside" the fence
"a plane is a two-dimensional space or flat surface that extends indefinitely" An ArduPilot polygon fence or cylindrical fence is definitely not that.
Isn't it more like this (from the wikipedia definition of Geo-Fence):
A fence is
- a closed path that encompasses, surrounds, or outlines a two dimensiona shape for a real-world geographic area. Such a closed path extends infinitely up and down creating a barrier which allows a vehicle to be either inside (inclusion fence) or outside (exclusion fence) or
- a 2D plane that defines an altitude that the vehicle allowed to be either above (FENCE_ALT_MIN) or below (FENCE_ALT_MAX).
So what happens if FENCE_ENABLE = 1 and an RC option 11 is set and then the switch is flipped (either on or off)? I'm not being flippant here - this is currently very confusing, and this doesn't seem clarify or deal with it. A similar question applies if FENCE_AUTOENABLE = 1 and the RC switch is flipped a) before the autoenable is triggered, or b) after the autoenable is triggered.
What is the expected behavior in these cases?
fence sw moved to high should activate all configured fences ..sw moved low should deactivate all fences....period, anytime, everytime...after the switch action other mechanisms can activate or de-activate fences (NOT the MINALT height activation though...that should occur if MINALT is active but pending the height gain...ie would have to switch the switch back high and then MINALT could be activated with alt gain above MNALT)
So what happens if FENCE_ENABLE = 1 and an RC option 11 is set and then the switch is flipped (either on or off)? I'm not being flippant here - this is currently very confusing, and this doesn't seem clarify or deal with it. A similar question applies if FENCE_AUTOENABLE = 1 and the RC switch is flipped a) before the autoenable is triggered, or b) after the autoenable is triggered. What is the expected behavior in these cases?
fence sw moved to high should activate all configured fences ..sw moved low should deactivate all fences....period, anytime, everytime...after the switch action other mechanisms can activate or de-activate fences (NOT the MINALT height activation though...that should occur if MINALT is active but pending the height gain...ie would have to switch the switch back high and then MINALT could be activated with alt gain above MNALT)
So I guess you are saying a fence switch (option 11) is edge triggered? This makes sense if it's clear, but it never really was and definitely needs to be made very, very clear in the wiki.
Except for the ALT_MIN stuff that makes sense I guess, but it's not not really clear that's what Andy's behavior spec sheet says, even after your suggested changes. I see it can be read that way, but as written, I don't think it's a black and white as you seem to think.
HW comments in bold IMO the biggest problem with fence has always been that you can have a fence breach triggering an RTL while setting up your vehicle in the pits 10 minutes before you are ready to arm, or sitting on the bench at home setting up the vehicle. this is easily avoided if you use AUTOENABLE This is caused by FENCE_ENABLE actually activating the fences. It should not do that. To be consistent with other use of _ENABLE, FENCE_ENABLE should only enable fence functionality it should never actually activate any fence. this is how plane fence originally worked and was changed. I dont think it matters as long as its documented, which it is in the current wiki This is so close and I think if this important thing changed, this big problem goes away, and a lot of other things start to work in a way that is easier to understand, explain (in the wiki) and test. I'm pretty sure they satisfy Tridge's concerns about regulatory requirements, but these should be documented clearly in the wiki and checked off carefully one by one. Tridge is also concerned about changing current behavior that might impact how fences currently setup by users are activated....but its hard to make any improvements without this FENCE_ENABLE should not activate any fence. Activating fences should happen on any of these events:
- On arming (disallowed if any non-Auto fence is also breached)
- On triggering by MavLink/DDS
- On triggering by the RCx_OPTION = 11 - switch going high
And the reverse for deactivating the fences, with the addition of AUTO landing modes deactivating any "Auto" fences.
Note that for this to work all fences must be processed for breaches when armed or disarmed, the breached status should be set true or false as appropriate for each fence whether or not that fence is currently active.this is very wrong...any fence not active should never be in breach
Ideally any fence should be able to be defined as an "Auto" fence, not just MIN_ALT. In any case any fence that is an Auto fence
- will not be activated on arming if currently breached (e.g. below MIN_ALT) prearms prevent arming while in breach so this does not happen
- will be activated if the vehicle is already armed and the fence crosses a boundary from breached to not breached. by definition a fence is already active if "in breach" no need to activate anything
- will be deactivated if the vehicle is landing deactivation by AUTOLANDING may need to be applied only to ALTMIN and not other fences, or all fences, or none, depending on pilot situation, so needs to be specified (currently is...almost
FENCE_AUTOENABLE goes away.having AUTOACTIVATE(/DEACTIVATE) options are needed(what AUTOENABLE(/DISABLE) currently does..this determines what the autoenable_on_takeoff and auto_disable_on_landing methods calls from flight code actually activates or de-activates
This would allow a pilot to land in FBWA model with a FENCE_MIN_ALT by flipping the RCx_OPTION = 11 switch to low.you can do this now HW additional comments: I sim'd for two solid days in order to correct and update the wiki last month on fence operation for Plane. I discovered many behaviors that I would call incorrect as noted above:
1.AutoEnable on arming, or not using AutoEnabled, never disables a floor for landing. So all the Plane situations which think they disable floor, wont. 2.MIN_ALT floor always disabled on boot irrespective FENCE_ENABLE, never gets enabled unless: autoenabled, or overt enable(GCS or switch). 3.MIN_ALT fence records breach even if floor is not enabled. MIN_ALT breach is recorded but not cleared after landing, preventing mode changes if mode change prevention is enabled (Copter allows mode changes always). This prevents mode changes after landing. 4.MIN_ALT floor stays disabled after disable floor for landing, used by NAV_LAND, QLAND and other VTOL landings in Plane, LAND, Copter RTL 5.Plane automatically ignores ANY breach while performing a breach action. Again prevents mode changes in Plane while landed. Should deactivate fences instead of ignoring so a breach is not declared 6. Mode takeoff call the autoenable method before reaching takeoff alt. NAV_TAKEOFF waits until takeoff completed, whichis correct
HW additional comments: I sim'd for two solid days in order to correct and update the wiki last month on fence operation for Plane. I discovered many behaviors that I would call incorrect.
Yes that's exactly what I'm trying to say. The current implementation has so many exceptions and special cases it's almost impossible to know exactly what it should be doing in any specific situation.
My suggestions are specifically intended to address this fundamental problem. Think it through Henry - instead of looking at what I've said in terms of how it works now, re-read it in the context of: is this new approach logical, does it make sense, will it work.
@timtuxworth I was commenting directly on your suggestions and some of them I disagree with fairly strongly....as noted
@timtuxworth I was commenting directly on your suggestions and some of them I disagree with fairly strongly....as noted
Ok then I'll respond to your objections one by one.
- this is easily avoided if you use AUTOENABLE - my proposal doesn't require AUTOENABLE at all
- this is how plane fence originally worked and was changed. I dont think it matters as long as it's documented, which it is in the current wiki - this is fundamental to my proposal. If you don't think it matters, then I assume it's ok to change it back then?
- Tridge's concerns - as you pointed out, its pretty much impossible to understand what's happening now, so maybe users will be happier with a more logically consistent system that they can understand?
- this is very wrong...any fence not active should never be in breach - this needs to change for this to work. Why is that a problem? each fence would have a separate "active" and "breach" state which can both be queried if necessary
- prearms prevent arming while in breach so this does not happen - correct, that stays the same
- by definition a fence is already active if "in breach" no need to activate anything - EXCEPT for MIN_ALT - what I am doing here is generalizing the MIN_ALT behavior so we can have other "Auto" fences not just MIN_ALT.
- deactivation by AUTOLANDING may need to be applied only to ALTMIN and not other fences, or all fences, or none, depending on pilot situation, so needs to be specified (currently is...almost) - MIN_ALT is no longer an exception/special case - it's part of a logically consistent framwork now
- AUTOACTIVATE(/DEACTIVATE) options are needed(what AUTOENABLE(/DISABLE) currently does..this determines what the autoenable_on_takeoff and auto_disable_on_landing methods calls from flight code actually activates or de-activates - My "Auto" behavior generalization replaces this, so it's not needed any more but you can still do exactly the same thing as now.
- you can do this now - yes I added it for completeness
fence sw moved to high should activate all configured fences ..sw moved low should deactivate all fences....period, anytime, everytime...after the switch action other mechanisms can activate or de-activate fences (NOT the MINALT height activation though...that should occur if MINALT is active but pending the height gain...ie would have to switch the switch back high and then MINALT could be activated with alt gain above MNALT)
Yes this, basically RC switch and mavlink override everything else.
My new breach behavior is specifically to address this issue raise by Henry:
5.Plane automatically ignores ANY breach while performing a breach action. Again prevents mode changes in Plane while landed. Should deactivate fences instead of ignoring so a breach is not declared
My proposal of having having independent "active" and "breach" flags on each fence, means that plane can deactivate a fence when it is breached. This will allow mode changes when landed. It will still be breached unless/until the plane flies back inside that fence, so the user or someone reading logs will know what happened.
It's very hard to follow what you are advocating for @timtuxworth - what I don't want to do is blow up everything that is already there - it's been incredibly hard to even get this far and wholesale changes are not going to fly. What I have currently document is what I have implemented and I do not believe are far off what @Hwurzburg expects for plane. Copter doesn't have a lot of this stuff but I don't want Copter to be different and I don't want plane to be weird. What I have written was chosen carefully to try and be logically consistent, but you need to recognize that MIN_ALT can never be a Normal fence. Trying to make it fit in the same way everything else does will not fly.
My long (and carefully considered) treatise explains the rationale. Changes required are simple:
- FENCE_ENABLE no longer activates fences at boot - they activate on arming.
- Fence "active" and "breach" properties become independent - i.e. - good coding practice
- Every Fence gets a new "auto" property - this replaces all the hard coded exceptions for MIN_ALT
- FENCE_AUTOENABLE is no longer required
That's it.
My long (and carefully considered) treatise explains the rationale. Changes required are simple:
1. FENCE_ENABLE no longer activates fences at boot - they activate on arming.
So you want FENCE_ENABLE = 1 to be the equivalent of what is currently FENCE_ENABLE = 0 + FENCE_AUTOENABLE = 3. I don't have a view on whether this is better or worse, but you need to define what happens if FENCE_ENABLE is set to 0 or 1 in the air.
2. Fence "active" and "breach" properties become independent - i.e. - good coding practice
Not sure in what way you think they are not independent currently. You can't breach a fence that isn't active.
3. Every Fence gets a new "auto" property - this replaces all the hard coded exceptions for MIN_ALT
Which needs to be on by default for MIN_ALT so MIN_ALT is still special. You also need to cope with disabling MIN_ALT but not disabling the other fences on landing. Its worth having the discussion, but I don't think it moves this PR forward. You could also have an auto disable property, but this is just making more generic behavior that is currently encoded in FENCE_AUTOENABLE and requires an extra parameter. So its an interesting discussion and I'm certainly willing for you and @Hwurzburg to duke out how you specify auto behaviour, but it does not help that much here.
4. FENCE_AUTOENABLE is no longer required
Except that you now need two parameters to replace it, so not clear how much of an improvement that is.s
I think the nice thing for me is that I have got you thinking about fence types in a structured way and fence states in a structured way. If we can at least agree on those then I have little opinion on what the configuration options should look like and have deliberately steered clear of changing the configuration options in this PR.
If FENCE_ENABLE is set to 0 any time it disables all fence processing I think this would be simple and can't see why it would be a problem. If FENCE_ENABLE is set to 1 anytime when armed all valid (configured) fences become active.
I am proposing that you can breach a fence that is not active, but that won't do anything if that fence is inactive. I believe this sets us up for more improvements in the future, I'm in particular thinking about how object avoidance should interact with fences in the future.
I can see/agree that MIN_ALT / Auto could be handled in a separate PR. I don't think I'm explaining my idea about this clearly, better to let it drop for this one.
I think the nice thing for me is that I have got you thinking about fence types in a structured way and fence states in a structured way. If we can at least agree on those then I have little opinion on what the configuration options should look like and have deliberately steered clear of changing the configuration options in this PR.
I've been waiting for this conversation for a long time. I have always found plane fences to be illogical and confusing, and I am so happy that you and Henry are doing this work to help clean it up. But having thought about it for a while, I have lots of ideas for improvement, so I've deliberately tried not to push too many new ideas for now.
@Hwurzburg I think all that you have written is covered (and I have updated my description at the top to make the language a bit clearer) apart from "de-activating fences until the breach action is completed". This is not what currently happens nor should it I believe. The breach action should be fully independent of the breach - this is what I want for scripting, I want a breach to always be a breach and for fences to always be active. If a particular breach action chooses to mess with fences it can do so, but it should not be the job of the fencing library magically de-activate fences. Note that disabling min alt fence for landing is not a breach action, its is a property of min alt itself - if you are landing you have to disable min alt. Last question - does plane have the equivalent of avoid? In copter with this PR you can define a tin can in space and if you are in loiter you can never leave - there are no breach actions because the fence is never breached because you are always prevented from getting close to the fence. Again the only way out is to switch to a manual mode or an auto land which is not a breach action.
If FENCE_ENABLE is set to 0 any time it disables all fence processing I think this would be simple and can't see why it would be a problem. If FENCE_ENABLE is set to 1 anytime when armed all valid (configured) fences become active.
Now you have to think about what happens to auto fences. If you set an auto fence does FENCE_ENABLE have to be 0 to prevent them getting enabled on arming (because you still need to support enabled on takeoff)? I think you do - so then what happens if you set back to 0 the auto fences. This is a great example of the issues I have encountered - its very easy to construct an interaction between parameters and commands that requires thought and testing - and in many cases the testing does not exist. Although I have some sympathy for the generic mechanism you are shooting for I think it means you have to add extra configuration complexity to recreate the features that people currently use and it does not change the fact that you have to think carefully about what happens in each scenario.
I am proposing that you can breach a fence that is not active, but that won't do anything if that fence is inactive. I believe this sets us up for more improvements in the future, I'm in particular thinking about how object avoidance should interact with fences in the future.
So now you have to introduce the notion of breaches that you care about and breaches you do not together with the requisite functions. There is also some cost in determining breaches (particularly poly fence). I don't believe you have reduced complexity here you have just pushed it somewhere else. I think my current definitions capture the scenarios we care about well but are sufficiently close to what we currently have that its not too painful to move.
Object avoidance is here already in copter, this PR just makes it work for min alt fences as well. It does not use breaches at all because there is this notion of "margin" that also has to be accounted for. i.e. an avoidance scheme that relied on breaches would not be very good. What copter does is slow down as it approaches the fence - breaches do not give you that nuance.
If FENCE_ENABLE is set to 0 any time it disables all fence processing I think this would be simple and can't see why it would be a problem. If FENCE_ENABLE is set to 1 anytime when armed all valid (configured) fences become active.
Now you have to think about what happens to auto fences. If you set an auto fence does FENCE_ENABLE have to be 0 to prevent them getting enabled on arming (because you still need to support enabled on takeoff)? I think you do - so then what happens if you set back to 0 the auto fences. This is a great example of the issues I have encountered - its very easy to construct an interaction between parameters and commands that requires thought and testing - and in many cases the testing does not exist. Although I have some sympathy for the generic mechanism you are shooting for I think it means you have to add extra configuration complexity to recreate the features that people currently use and it does not change the fact that you have to think carefully about what happens in each scenario.
Not at all. I'm suggesting FENCE_ENABLE only enables/disables the fence framework. If it's 1 auto fences do what they are supposed to do, if it's 0 they do nothing. In normal usage I'd be proposing that FENCE_ENABLE always be left on/1 or off/0.
One of the biggest problems with the current approach is continually having to juggle FENCE_ENABLE and FENCE_AUTOENABLE and/or the RC switch depending on whether or not you are flying an auto mission. I often fly some manual flights and some auto missions in the same trip to the field, and I often forget to set/reset something and end up with no fences active when I really wanted them on. I want to be able to set FENCE_ENABLE = 1 and leave it on. The way this works right now is broken.
I am proposing that you can breach a fence that is not active, but that won't do anything if that fence is inactive. I believe this sets us up for more improvements in the future, I'm in particular thinking about how object avoidance should interact with fences in the future.
So now you have to introduce the notion of breaches that you care about and breaches you do not together with the requisite functions. There is also some cost in determining breaches (particularly poly fence). I don't believe you have reduced complexity here you have just pushed it somewhere else. I think my current definitions capture the scenarios we care about well but are sufficiently close to what we currently have that its not too painful to move.
No you have fences you care about (active) or you don't care about (inactive). I think this simplifies things. Perhaps that's an opinion, but if you think about it you might find it does. Of course I could be wrong. We won't know for sure without trying/testing it.
Object avoidance is here already in copter, this PR just makes it works for min alt fences as well. It does not use breaches at all because there is this notion of "margin" that also has to be accounted for. i.e. an avoidance scheme that relied on breaches would not be very good. What copter does is slow down as it approaches the fence - beaches do not give you that nuance.
Object avoidance doesn't work for plane. Right now plane flying AUTO or CRUISE will fly right into an an active fence, causing a breach, trigger an RTL, and the plane will fly right through another active fence to get home. I know this won't satisfy Canadian regulators, I can't imagine there would be many who would think that is ok.
I have a lua script for arming checks that breaks with this code. This method incorrectly returns false, when I have a simple circular exclusion fence (Henry's example) loaded.
local function fence_present()
local enabled_fences = FENCE_TYPE:get()
local basic_fence = (enabled_fences & 0xB) ~= 0
local polygon_fence = ((enabled_fences & 4) ~= 0) and FENCE_TOTAL:get() > 0
return basic_fence or polygon_fence
end
@andyp1per testing on dev call:
- [x] with FENCE_AUTOENABLE=3 and FENCE_ALT_MIN=20 on a quadplane if you abort a landing and go back above the FENCE_ALT_MIN, fence doesn't re-enable
- [x] displaying disabled alt-min fence when not enabled in FENCE_TYPE?
- [x] got a MIN_ALT fence breach on quadplane auto-land with FENCE_TYPE=12, FENCE_ENABLE=1, FENCE_ALT_MIN=20, the switch auto_enabled() in auto_disable_fence_for_landing() needs to cope with min alt fence having been enabled on takeoff
- [x] aux function 11 to disable fence did not work in SITL tests, should be able to enable/disable fence with a switch -- FENCE_ENABLE=1 -- FENCE_TYPE=12 -- FENCE_ALT_MIN=20 -- "aux 11 0" to disable fence, "aux 11 2" to enable fence -- in AUTO, quadplane
- [x] need to be able to enable or disable fence while in flight with aux 11 option no matter if inside or outside fence
@tridge I believe I have fixed all the issues you found - would be grateful if you could take another look
I flew this at the weekend. Generally worked well but was able to breach the fence in loiter relatively easy. @lthall thinks this might be a "loophole in loiter than your high lean angle is exploiting". Log here:
I also found a bug which is if you switch to loiter from RTL once you have descended below the MinAlt height the copter just sits there and cannot be landed.