Hello DIYD experts! I've been trying to get the continue mission on signal loss to work for the last few days, and wanted to see if you can spot what I might be doing wrong. I've captured it all in the video above.

I'm running Mission Planner 1.2.60 and tried both Arduplane 2.73 and 2.74b.

Thanks guys!

Views: 3300

Replies to This Discussion


It looks like the APM is detecting the radio signal was lost. As I recall this is when the throttle's PPM signal drops below 950 or so. I don't have an APM on me right now to grab screen shots, but it should be under the failsafe tab in Mission Planner. 


Try removing the checkmark from the throttle failsafe actions. I actually disable this by default. I had an incident where I forgot to turn my transmitter on. After the GPS locked the system spun up and took off across the room. 

Even so it still should continue in it's mission and not RTL. That is what the setting he refers to controls.

Agreed. Its doing failsafe just fine, it doesn't seem to be doing the right failsafe. 

Trent, we have done this before, what you need to do is NOT use the APM failsafe, but use the RECEIVER failsafe to select a certain mode when it does not get a valid signal. This way we were able to make it stay in AUTO when we turned off the TX. What Transmitter are you using? We got it to work fine with both JR and Spektrum systems. I have heard that many people have had major problems with this wiith the Turnigy system failsafe.

A few points tho.

1. TEST the system without props ALOT before finally trying it. Set the RX failsafe, turn everything on, turn off the TX, see what happens, Turn On the TX, make sure it goes back to the mode you want.

2. Be aware that many FAA approved bodies PROHIBIT this practice. In our country the Model aircraft association rules state that you HAVE to be in control of the "drone" at all times, so this would not be allowed. Check your local rules!

Try it an let us know.


Thank you Wessie, I'll try that. Agreed on testing by the way... I'll ensure it behaves properly on the ground first, and then test it in the air with plenty of altitude and a quick hand on the restart of the tx...

As for being in control, I intend to remain in control at all times, but as my long term project is to take off and land at different locations, returning to the launch point on a signal loss would be very bad, as it might lose signal towards the end of the flight, and not have the power to RTL. But no, I don't intend on making a habit of just sending it on it's way out of range and out of sight. 

Thanks! I'll report back.

I'm not sure I understand why it works that way. I've never tried setting it that way but according to the info in the parameter it should stay in AUTO on a failsafe if that's the way it's set. Why does this matter what the transmitter's failsafe is set to? If the APM knows when to go into fail-safe either because of throttle being below threshold or other reason AND you have it set to continue in AUTO if it's currently in AUTO then why can't the APM switch it to AUTO regardless of whether you have a Rx failsafe set up in a particular way. In fact if that was the way to do it then you wouldn't need this setting at all. Just set your mode switch to AUTO when you set your receivers failsafe and it will always go to AUTO on failsafe but that is wrong because then you might not even be in AUTO at the time yet it would put you in AUTO and if you didn't have a flight plan then it might just sit in LOITER.

@Wessie, perhaps you are thinking about using failsafe with previous versions of the code from many months ago.  

The best way to use the current flight code is to use the APM's failsafe functions with a properly configured receiver because the APM has a much more sophisticated failsafe than the receiver.  You can run into problems you just use the receiver's failsafe to fake out the APM.
The APM has the ability to handle different types of receiver failures as well as a battery or GPS failures, plus it operates in all modes, not just auto.  It also allows you to set your mode switch to whatever modes you want without requiring one of them to be your failsafe mode.
@Trent , the parameter you need to set is Short failsafe action (ArduPlane:FS_SHORT_ACTN)
The action to take on a short (FS_SHORT_TIMEOUT) failsafe event in AUTO, GUIDED or LOITER modes. A short failsafe event in stabilization modes will always cause an immediate change to CIRCLE mode.
In AUTO mode you can choose whether it will RTL (ReturnToLaunch) or continue with the mission. If FS_SHORT_ACTN is 0 then it will continue with the mission,
if it is 1 then it will enter CIRCLE mode, and then enter RTL if the failsafe condition persists for FS_LONG_TIMEOUT seconds.

I recommend you use the Failsafe page on Mission Planner to test the configuration and verify the behavior prior to flying.

For the rest of the studio audience the full instructions are here


Basically you need to set up the receiver so it drops the throttle channel to below normal in the event of a loss of receiver signal. 


The full parameters are described here
Keep up your great videos!

From his video it looked like he had ArduPlane:FS_SHORT_ACTN set to 0. It went into circle mode so it must have detected the fail-safe condition but it went to CIRCLE and then RTL like it was set to 1.

Here's the part of his video that shows them both set to 0.


Thanks Steve! You caught it!

You're welcome! Love your show btw! Some of the videos should be added to the wiki, if they are not already.

Thank you for the great feedback... you said it much better than I did. As Steve mentioned, I actually had both those modes set to 0, in fact, I even refreshed my params while it was in the air, just to make sure! 

When I turned off my Tx, it responded exactly like it was set to 1 instead of 0. Let me go through it all one more time, perhaps I missed something. (I'll look at the failsafe settings, the PPM for the throttle, ensure there aren't any conflicting PIDs, etc)

Trent and I just had a look at this issue on his plane, and we found that the problem was fixed with 2.74b, at least with his setup. I don't think it is a complete fix however, as I have found a possible code path in the code where the error could occur with 2.74b.

What happens is this:

  • the aircraft is in AUTO with the transmitter on. Both short and long failsafe are set to zero, which means it is setup to continue in AUTO on throttle failsafe
  • Trent turns off his transmitter
  • With the transmitter off on the FrSky receiver that Trent is using, switching off the transmitter changes both the ch3 (throttle) value and the ch8 (mode switch) channel
  • it changes ch3 to 900, and changes ch8 to a value that corresponds with a non-AUTO mode
  • this starts two timers in the code. One timer is related to mode switches on channel 8, and the other to throttle failsafe on channel 3.
  • the timer for failsafe on channel 8 can complete before the timer for the throttle failsafe on channel 3
  • if that happens then the aircraft will briefly switch to the mode given by the changed channel 8 value
  • then a moment later it will change to CIRCLE, as it is getting throttle failsafe in a stabilization mode

The timing in 2.74b is a better than the timing in 2.73, which is why Trent is seeing the bug as "fixed", but it isn't really fixed. It could still happen, it is just less likely. If the bug does trigger then the aircraft will go into CIRCLE mode and then RTL instead of continuing in AUTO.

I'm working on a fix for this at the moment, and will either do a beta of 2.75 or do a 2.74c release soon.

Cheers, Tridge


DIY Drones Monthly


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service