Since FS_THR_ENABLED=2 was removed in 4.0+ and that function is now performed by the parameter FS_OPTIONS, how should FS_THR_ENABLED be set when using FS_OPTIONS?
You set the action you want if the FS is triggered with FS_THR_ENABLED (RTH, Land, SmartRTL, etc) then you set the conditions for not triggering/continuing with the options.
Yeah Dave has this.
I read it like
Do FS_THR_ENABLED action
Except if FS_OPTIONS
I must be having a moron moment here… Let me see if I can get my head around it.
Maybe this is what’s meant to happen:
There are two basic cases:
Case #1: You are not in AUTO flight. (LOITER, ALT-HOLD, STABILIZE, etc.)
Case #2: You are in AUTO flight.
In Case #1 you are not in AUTO flight - and a battery, Radio (R/C) or GCS failsafe occurs. In this case, the copter does what is set in the associated parameters:
These options (Except BATT_FS_CRT_ACT) are set in Mission Planner here:
In Case #2 - you are in AUTO flight - and failsafe of battery, R/C or GCS communications occurs - the option set on FS_OPTIONS take place.
This would make sense to me EXCEPT if a battery fail safe occurs. In AUTO, you might want the mission to continue on all fail safes except a battery fail safe - where you’d probably want to LAND or RTL.
So I guess it boils down to how to you set a battery fail safe for AUTO flight - that’s different than for manual (LOITER, ALT-HOLD, STABILIZE, etc.).
The wiki for FS_OPTIONS includes BATTERY as a fail safe condition. Could that be a mistake in the wiki?
I’m terribly sorry for beating this to death - but I really want to understand this correctly - and get it right.
Battery failsafes take precedence over everything, as they should - I’ll verify this in the code if I can.
The FS_OPTIONS just modify the handling of FS_THR_ENABLE which is essentially RC loss.
FS_GCS_ENABLE only works if Arducopter has detected the use of a GCS - so you can set the options and then NOT use a GCS all the time, and the fallback is FS_THR_ENABLE and other FS_OPTIONS
Just to put it out there, this is a GREAT option too:
FS_OPTIONS,8 - Continue if landing on any failsafe
Essentially, if already landing, dont start an RTL or other action if a failsafe occurs
Before this came along, we would see the quad landing as planned, then there would be a battery failsafe and it would rise to the RTL Alt or RTL_CLIMB_MIN and start over… Not good for battery usage.
In Case#1 using RC control, you would normally want RC loss to initiate RTL or similar
FS_OPTIONS,0 (or 8, as I mentioned)
FS_GCS_ENABLE,0 or something specific if you expect to be using a GCS all the time
In case#2, running an Auto mission, you may be expecting to run out of RC control, but probably want the mission aborted if you run out of GCS comms (eg: long range telem radio)
FS_OPTIONS,1 (add 8 for the continue if landing option = 9)
It definitely looks to me like the code handles the battery failsafes first and sets the action, and the only exception is for the option “Continue if landing on any failsafe”.
Then the radio failsafe and GCS failsafes are handled.
Excellent - thank you for taking the trouble to look this up.
I don’t want to mis-interpret the code. (my coding skills are decades old…)
I was trying to think if it might be possible for the FS_OPTIONS routines to fire on a battery fail safe if no battery failsafe routine were called by BATT_FS_LOW_ACT or BATT_FS_CRT_ACT. But it seems the only way that could happen is if the battery failsafe parameters weren’t set - so if that’s true, they wouldn’t be there to trigger a FS_OPTIONS failsafe either.
If that’s true - then the wiki text ought to be corrected to eliminate the work “battery” here:
Would you agree?
If so - I’ll do what I can to ask that the wiki be updated.
I don’t know how many other folks are mystified by this. From the conversations about it I’ve had in the past, I get the feeling it’s often just glossed over. And it’s surely not an easy thing to test in a test flight.
Once again Shawn, you’ve provided a great service. I hope others benefit from it when this thread comes up in their searches.
BTW - you’re 100% right about the FS_OPTIONS setting for continuing when landing.
I had a copter that had just finished a photo survey mission trigger a battery failsafe on touchdown but before it disarmed. It was quite a surprise to see it launch back into the air.
Now that I think about it - the option that prevents this:
… includes a battery failsafe among the “any”. So that being the case (and perhaps the only case) that a battery failsafe would trigger a FS_OPTIONS procedure, the word “battery” is OK in the wiki text.
But in my opinion, the language could sure be a lot clearer. I’ve spent far too much time getting my head around this today. We all have.
I forgot to list BATT_LOW_MAH as one of the battery fail safes.
I hope there’s not anything else…