Replies to This Discussion

Permalink Reply by John Moore on June 26, 2012 at 4:04pm

So none of the experts have any ideas as to why this might happen? The software is set to ignore throttle failsafe in Auto modes but it triggers the failsafe anyway. 

• ▶ Reply

Permalink Reply by Andre on June 27, 2012 at 12:52pm

I know how you feel there is so much post and it seems like to little people wants to comment.
I als has a problem and its now almost 4 days and no reply.

• ▶ Reply

Permalink Reply by Vernon Barry on June 27, 2012 at 1:05pm

http://code.google.com/p/ardupilot/wiki/RadioSetup

http://code.google.com/p/ardupilot-mega/wiki/Failsafe

Here's what the failsafe will not do:

1. Detect if one more more individual RC channel has failed or become disconnected
2. Detect if you're flying too far away or are about to hit the ground
3. Detect autopilot hardware failures, such as low-power brownouts or in-air reboots
4. Detect if the APM software is not operating correctly
5. Detect other problems with the aircraft, such as motor failures or low battery situations (although the latter can be set up through the main code if you have the right voltage/current sensor)
6. Otherwise stop you from making setup or flight mistakes

---

• ▶ Reply

Permalink Reply by John Moore on June 27, 2012 at 1:51pm

Im not sure what youre getting at but the information in those links is out of date.

From the Wiki: For Auto and Loiter modes you have a choice (through the configuration) of if they will be affected by the failsafe or not. If so then the mode is switched to RTL.

There is supposed to be a way to tell the APM to ignore the throttle failsafe in AUTO mode but everything Ive done makes the plane go into failsafe in ALL modes. One of the links in the Wiki goes to a thread about setting up the failsafe with a DX8 where the poster states that you choose whether the RTL failsafe engages in AUTO by changing the parameter THR_FS_ACTION and set it to 2 (1 = continue on Auto mission, 2 is RTL).

The parameter THR_FS_ACTION does not exist on my parameter file from version 2.40 of the ArduPlane software. Im posting here expecting that someone with knowledge of the software could easily tell me if that parameter may be hidden, renamed, or maybe that function has been removed.

• ▶ Reply

Permalink Reply by Jesper Rooth on September 9, 2012 at 12:25pm

John, I have the *exact* same problem.

But I know this - THR_FS_ACTION is ArduCopter specific right? It does not exist in the ArduPlane code.

• ▶ Reply

Permalink Reply by James masterman on October 9, 2012 at 6:24am

Hi John,

Not sure if you are still having this problem, but I have discovered something about failsafe with my radio that may help. When my DX7 is in Auto mode and it flies out of range, Failsafe is triggered. This was perplexing me as looking at the code, there is no way it should have gone Circle->RTL when starting from Auto Mode. The answer was in how my radio handles Failsafe.

On failsafe, the receiver input into Channel 8 on APM was also changing along with the throttle, which meant the failsafe was inadvertently putting the APM back to manual mode. From here the normal Circle->RTL happens. The trick that worked for me was to bind my reciever with my switches already set to Auto position, this meant that on failsafe, it just stayed in auto mode and failsafe could be turned off by setting FS_SHORT and FS_LONG to 0. As far as I can tell from the code, these only have relevance in Auto modes anyway, and failsafe (Circle->RTL) is always triggered in the more manual modes (Manual/stabilise/FBW).

Your radio may not be changing the mode setting on failsafe, but it is worth checking. You can test by connecing to mission planner, using the tuning graph on the flight data page and watching the values of ch3in (throttle) and ch8in (mode). Turn off your Tx and watch what happens to the value of ch8.

 

 

• ▶ Reply

Permalink Reply by Jerry on October 11, 2012 at 1:56pm

I found the problem was the built in failsafe on my RADIO was "nudging" the APM2.5 board around a lot. For my rangelink, to disable failsafe, I just had to rebind. This solved the problem, and now my failsafes all work as published.

• ▶ Reply

Permalink Reply by moglos on April 25, 2013 at 2:34pm

Hi John

Have you had any luck with your failsafe problem? Or tested James Masterman's solution? I've searched and written a couple of posts but haven't had much in the way of help yet. I think I have the answer, but I was hoping a developer/expert would confirm it. See this post, and this older post.

My solution is to program the Rx failsafe to set ch 8 (flight mode) to auto, similar to what James Masterman said below, (he answered my posts too, thanks James) and disable the throttle failsafe. If it goes out of radio range then the Rx failsafe will keep it in auto mode so the APM can continue the mission. This feels like a workaround to me, I expected you should be able to configure the parameters to allow this to happen.

Note, I've only tested this on the bench so far and it works (stays in auto). I want to test it in flight this weekend.

• ▶ Reply

Permalink Reply by James masterman on April 25, 2013 at 4:07pm

I think this has been fixed in Arduplane 2.71. The release notes say that one of the improvements is "prevent control mode changes due to receiver input change when in throttle failsafe". I haven't tried this release, but it sounds like a case of problem solved at last.

• ▶ Reply

Permalink Reply by moglos on April 28, 2013 at 9:51pm

Hi James

I flew on the weekend using your suggestion programming Rx failsafe mode=auto and THR_FS=0 and it worked great on 2.71. Thanks for your help. 

I'm building a roll stabilizing gimbal, much like like your pic at http://www.diydrones.com/profiles/blogs/mapping-with-ardupilot?id=7..., but I'm going to have my camera aligned in landscape mode. It will take a wider image, so I need to fly less passes.

• ▶ Reply

Permalink Reply by James masterman on April 28, 2013 at 10:37pm

That's good news, I'm glad it worked for you. Hopefully, with the changes made to Ardupilot in 2.71, we will no longer need to do this to have proper failsafe control.

I am surprised more people haven't noticed this problem, but I guess not many are flying out of radio range!

• ▶ Reply