A few comments on how to make the wiki clearer on how to set up Failsafe, and a question on how to test it. Extract from the wiki with my comments:
If you have enabled failsafe (how? I have set my config THR_FAILSAFE to 1 - is that correct?), your copter will RTL back to home, and auto-land after 20 seconds.
To enter failsafe, you must be armed (failsafe does not work when disarmed) and you must set your receiver to output a low throttle signal (below 975µs by default). To send a throttle value that is below your radio's normal neutral throttle value (say 1100), please read your radio's programming manual.
I would make this a bit clearer. For instance, "you must set your receiver to output a low throttle signal (below 975µs by default). This can be done by looking at the Status or Raw Sensor View (Radio) and changing the end point on your low throttle setting so that it is below 975µs. Then programme that into your receiver as a Failsafe setting (refer to your receiver's manual). Then reset your low throttle setting back to what it was e.g. 1100. Test that the receiver Failsafe setting is working by viewing the radio data as above and then switching off your Tx. The Ch 3 setting should now drop to the below 975µs setting. Switching the Tx back on should restore the Ch 3 setting to your normal neutral throttle value. Recalibrate your radio settings once you have completed this exercise.
How do I safely test that this will work? I tried taking my copter outside, powering it up, getting a GPS lock and then arming it and looking in Mission Planner. I could see Ch3 in reducing to 965 when I turned my Tx off, but there was no indication of a change in mode. Oddly enough, I am reluctant to turn my Tx off when I am flying it.
Any guidance on this would be much appreciated as I would like to have this safety feature as insurance to help prevent injury (and crashes and money!).
About Failsafe wiki for AC!!
Unfortunately the use of THR_FAILSAFE_ACTION as described in the AC failsafe wiki is still inconsistent with with regards to the mavlink parameters table (as pointed out before). They directly contradict each other on the effect of using 1 as value for THR_FAILSAFE_ACTION. I cannot believe you really intend this contradiction in Ardu wikis, it must be a mistake. Either in the AC failsafe wiki or in the Mavlink paramter wiki.
Also, it would be recommendable that AC failsafe wiki explicitly states how the failsafe will work if THR_FAILSAFE_ACTION is 0, which is actually default value according to the Mavlink parameter wiki.
Please comment on this and correct where applicable.
Thanks. / Tomas
ps. Issue filed
After two recent test flights of 2.3.1 (downloaded from GIT some hours ago), APM2, MP1.1.35, 3DR stock frame I have at least sorted out which one wiki correctly describes THR_FS_ACTION; The Mavlink parameter wiki is correct (and the AC failsafe wiki is not).
Ergo, the AC FS wiki should be corrected to read:
" If you are in Auto and prefer to continue your mission, the parameter THR_FS_ACTION should be set to 2.
If you prefer to have the copter RTL even if it is flying under autopilot, set THR_FS_ACTION to 1."
So this afternoon I had two flights out over the frozen lake.
FW 2.3.1 GIT (as per this morning), APM2, MP1.1.35.
I have already reported about how copter in AUTO mode reacts to failsafe, depending on the THR_FS_ACTION.
But I also did hand tests, well away from HOME (due to the 10 radius limit, see the wiki) to find out what happens in Stabilize mode while turning on TX (entering failsafe).
Now maybe it almost works;
Holding the quad in my hand at hover throttle and shutting of the TX would instantly make the motors drop thrust, but soon, within half a second i guess (have not yet checked the log) recover. But that momentary thrust drop-out was reason enough for me not to try this in flight! Anyway it would of course be desirable that when copter for whatever reason enters failsafe RTL, it should do it firmly but at same time with a certain smoothness in the transition. Even more important on big copters with mass and momentum, as well as for trad helis.
I am aware about the fact that a real situation RX failsafe is a rare situation for most multicopter users. But the day we need it we really want it to work flawlessly and predictable, right?
I request that you, honoured developers and test pilots, run rigorous flight tests on the failsafe before official release of 2.3.1.
Should have been done by 2.3.0 release, but let´s make it right this time ;-)
Last flight I shut off the TX during AUTO flight. And I let it continue AUTO mission until last WP with auto land. I was determined to let it try to do a decent auto land. It went so-so. Last meter had high sink rate, and on touch-down it bounced up and flipped over, lying upside-down in the snow, motors running. Even though I switched TX on, entering stabilize (throttle at zero), switching modes, it would not react. Motors kept going. Had to pull the battery chord. I dont know if that was due to AC firmware or something happened to RC RX, since there was plenty of snow in the electronics hub. (I should get some more snow proof dome...)
Picture: Quad drying in the dryer box.
Tomas, I had exactly the same experience when I tried an RTL Failsafe, at least in that it just plonked down but then failed to respond to my switching the Tx on, and eventually did a flip, motors screaming and I had to disconnect the battery. The post-landing part of Failsafe definitely needs to be worked on, but presumably it should just now point to the RTL-Autoland code. Regards, Bill
Has this been addressed in 2.4 Bill? Although I was testing RTL and not FS when Ive also had the problem of not being able to turn motors off when the rig is upside down. I'm luck that I have an off on switch rather than have to pull out the lead connectors. If not then may be we can out it in issues?
John, not tested yet, but have had no indication that anything has been done about Failsafe. I think Tomas raised an issue. Regards, Bill
I set my receiver too set RTL switch until i,m sure of what its going to do but mines on a plane i just didn't want it to try to autoland. on a quad it should shut off motors if upside down in any auto modes and FBWA (shouldn't be upside down unless there is a problem). On a plane or TH we can still fly with throttle off and can fly upside down :P
Today I tested failsafe again (using the 975us throttle trigger), during hovering in stable mode. GIT 2.4.1 this morning.
I really enjoyed when my friends at the field dropped their jaws upon watching me resolutely turn off the transmitter. For like half a second RPM dropped noticeably but quickly resumed without any significant altitude loss. It entered RTL, just as it should. I did not let it do a fully auto land, since the touchtown and shut down of motors still seem unreliable (I have not implemented JLN patch, but I hope it will be included in future releases).
However, I could not see it climb 10 meters or to predifined altitude and then return. Seemed to keep the altitude it had. HOW do I set it up to do that safety climb before returning??
It's easy Tomas, ALT_HOLD_RTL is disabled in the code, at present this parameter is useless, so the quad go to home at the current altitude, when engage RTL switch or failsafe.I agree with you that this is absurd, so I hope the altitude of security is implemented in the future.
For me Mikrokopter has the best procedure "go to home":
This is the best RTL, number one in security.
Marco - (AC Dev Team)
Thanks for info, Marco!
Confusing! The AC failsafe wiki says:
"If you have enabled and triggered failsafe, your copter will rise 10m, RTL back to home, and auto-land after 20 seconds."
Anyhow, would this hack work ok? Any side effects to expect?
static int32_t read_alt_to_hold()
// Tomas commented out the block comment out below (so the block IS now active)
if(g.RTL_altitude <= 0)
return g.RTL_altitude;// + home.alt;
Seems I was wrong about that not working. I flew Stable mode today, turned the TX off. AC dropped for a fraction of a second, then, according to the log, it climbed 10m while coming home, loitering and land. Ok, I am glad to be proven wrong on that one!
That said, I will probably set it up to climb to an altitude of 35 meter upon failsafe, to reduce the risk of running into some trees on the way home. I mean, if the failsafe occured at low level (where it is more likely to loose radio link), lets say 5 meters, it would otherwise climb to 15 meters and bolt home. But the trees and houses are often higher than that.
Nice to hear the failsafe protocol is working for you.
Just to summarize things, can you provide the specs of your setup.
What version of the software you used and is it indeed as simple as turning the value of the THR_FAILSAFE to 1 (0 = disabled) in the mission planner to activate failsafe?