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!).

Regards, Bill

Views: 8472

Reply to This

Replies to This Discussion

Wow Marco, thanks for really trying to explain it to me. And I must admit I have not updated PPM encoder, maybe I should do that (even if I yet do not understand what problem that is solvin). Using APM2 board, I thought that decoder/ encoder would be reasonably up to date. But as I understand it that is about internal failsafe, like what happens if RX dies and there are no signals from RX to APM?

I am specifially addressing that sub 975 µs triggered FS feature, the only one described in the flight modes / failsafe wiki. Have you been able to implement this method?

Assuming that if I run into range problems during flight, or my TX dies or gets turned off, then the failsafe setting of my RX will engage. And following the wiki, I programmed it to output 945 µs throttle in case of failsafe. Confirmed in MP:

That alone should trigger a position freeze, climb to safe altitude, return to home, loiter and land. Or is the wiki not valid at all? (But Don has got it working...)

Don, good to hear that it works like that in HIL. Using APM 1 or 2?

I attempt to test the failsafe setup by:

Waiting for GPS 3D fix

Arming, in STABILIZE mode

Setting hover throttle, holding it in my hand

Turning off transmitter.

ch3in immediately goes like 948, as pic above, and all motors stop.

MP Flight Data mode indicator shows RTL, but I don´t know if that is because my failsafe programming for CH5 is RTL or if it is because of the throttle < 975 input. (I should re-program RX failsafe to output stabilize mode value instead, to see if APM arrives at RTL or Stabilize.

When you do it in simulator, does it announce "FS RTL" or just "RTL"?

Is there any other parameter that must be set in accordance, to make this work without cutting the motors?

Agree that optimal FS implementation is not trivial, but I think that this RTL concept with initial climb before returning can accomodate a a good amount of the most common failsafe situations. That´s why I want to get it working so badly.

Ideally, the 975 µs failsafe (eg TX turned off) should never be allowed to initiate a flight from ground, armed or not. That limitation should be rather trivial to implement, if not already in force.

I'm very sorry Tomas but i've updated all my apm1 board with the new ArduPPM, can't try all your request with the sim.
Anyway why do not you try? DIY! :-) (with the sim, of course).
Unfortunately the "climb concept before drift to home (in RTL)" is a wonderful opportunity that the dev team so far has completely ignored, Mikrokopter has it and use regularly.
I soon discovered that even the parameter "ALT_HOLD_RTL" is present but completely disabled in the code, then the quad in the case of RTL back to home at the current altitude, no choice.

things you can customize in the future V3, then the only solution is to make do, as I do, but i can't release these "patches" because i'm not sure what I have implemented and will not cause trouble for anyone, although here work perfectly.
I do not think that the planner in any way signal the failsafe, only "RTL", and in any case should tell you "FS" is hired only if the internal one.

I agree...


Has ANYBODY got the FAILSAFE throttle<975us to work on APM2 ??

I am trying hard and it does not respond at all. Is that only me??

Link to wiki

And can anybody provide info on the THR_FAILSAFE parameter, please? 

What is it for, and what value (s) should apply?

Tomas, 1 enable, 0 disable, same as on APM1.
Why you can test it whit the sim?

I finally had a go at this today. Hovering about 2 foot above a grassy snowy field, I switched my Tx off. The motors did not cut, as seems to happen to others, but they did reduce, so it just plonked down. When I switched my Tx back on, it slowly flipped over and got everything covered in snow. Not sure what the conclusion is here. Having read the rest of this thread, I will try to reduce the throttle setting to 900, as I had the Failsafe setting at 964, may not have been enough of a difference to trigger the RTL I was hoping to see.

If you hovering at the home point and turn off the radio it's normal, quad is over the home and for the "autolanding bug" it just plonked down.
Wait the next release of AC and my videos where i explain how the failsafe work in the reality.
I've published the video with this bug, do not try again this at the moment... :-)

Marco, I never used the sim...

But seems like I have to do learn to use it :-/
Nevertheless I would like to find a way to do a reliable flight-test of the failsafe, without risking the copter falling out of the sky with motors shut off... 

You are completely right about THR_FAILSAFE param, I found the info, not in AC wiki, but in ArduPilot wiki about MAVParam.

This info should of course be mentioned in AC failsafe wiki, as it totally determines whether the feature is enabled or not!!  

Furthermore (added this to an wiki issue) the AC wiki is contradictory to the MAVParam table with regards to THR_FAILSAFE_ACTION. MAVParam table states "...If FAILSAFE_ACTION is 1 when failsafe is entered in AUTO or LOITER modes the aircraft will head for home in RTL mode."

While AC failsafe wiki states:  "If you are in Auto and prefer to continue your mission, the parameter THR_FS_ACTION should == 1."

One of them has to be wrong, doesn´t it?

Then another observation, in the same MAVParam table, column 6 "Enabled (0 = no, 1 = yes)"

In this column, the cells for THR_FAILSAFE and THR_FS_ACTION are empty, means it is undefined whether the parameters are enabled or not. But I suppose the person who updated the table just wanted to save  a couple of 0 or 1...

I have been testing with THR_FAILSAFE = 1. 

With motors armed but disconnected, 3D GPS fix, in the house.

I remain uncertain what is going on. When I turn off the TX the flight mode indicator switches to LOITER with motors running (my failsafe on CH5), but then when I turn on TX again, there comes a MAVLink debug message " MSG FS OFF 1464". The number displays the pulsewidth when RC link is restored. That indicates that it has been in FS mode! But not the indications on MP Flight Data "HUD".

Despite all good advice (thanks), I am still confused and frustrated with this.

I feel stupid. Have spent MANY hours trying to sort this out. :-O

Marco, would you please post the link (in this thread) to your autolanding bug video, for convenience.

That seems to be very relevant in this context, and maybe one explanation to why bench tests gives so confusing results.

Nevertheless, failsafe wiki badly needs a thorough update. Maybe with a link to one of your instructional videos :-)

No, I was probably about 20m away. Or is that close enough for the failsafe code?

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service