Hi All,

My apologies for being a bit slack in keeping up with the ArduPlane forum questions lately. If you have a look at my blog post from today you'll see what I've been up to.Now that we've got the AP_HAL code in place, the move to github done and the PX4 port working, I'd like to do a new ArduPlane release soon. It would really help if you could all add any issues that need to be addressed for a new release in the issues list. Please label them as ArduPlane issues, and give enough information for me to try and reproduce it (flight logs, explanations etc). If you had an issue in the old google code list and it is still relevent then please re-enter it in the new list (sorry about that).

There has been a lot of code changes since the last release. Much of that is internal (AP_HAL changes and PX4 support), but there are also new features, for example:

ArduPlane now has a new flight mode called TRAINING mode which I'm really delighted with. I developed it in collaboration with an MAAA flying instructor, and it is meant to be used to teach people to fly RC models. The way it works is that if your roll/pitch is less the the limits you configure then you have complete manual control. If your roll goes past the limit then the APM prevents you going past the limit - much like the way training wheels on a bike prevent the bike from falling over if you lean too far, but when you are riding well the training wheel doesn't touch the ground and you are riding a normal bike. The same goes for pitch. Training mode is fantastic for learning to fly manually. I still need to write the docs for training mode (unless someone else volunteers to do that!), but I've flown it a lot and it works wonderfully.

Another new feature is one that has been requested many times, which is that you can mount your APM any way up in your plane. So if it fits better to have it mounted upside down or sideways then you can now do that by setting the AHRS_ORIENTATION parameter. I went for a flight today with my PX4 mounted upside down and it worked really well.

Cheers, Tridge

Views: 1464

Reply to This

Replies to This Discussion

Upside down! That's great, it will really simplify my build and stop me cursing the fact that I should have soldered the side entry pins on my APM. (Though I may change them yet!) thx for the hard work.

PS: i suppose this comes with the caveat that the GPS unit needs to have it' antenna pointing skyward, so APM 2.0 user with built in GPS will not be able to use this feature

Would you please add a throttle suppress in auto launch feature so my plane can clear my bungee launcher before activating the throttle? Maybe this feature already exists but can't find much info anywhere in the forums or wiki.

Also it sounds like people are having problems with the autoland features. Mission planner doesn't match up with the wiki.

Will the WP camera triggering features finally work in this next release?

That's great about the new AP orientation mounting feature! Will clear up some space for the soon to be working WP triggering and camera :)

Waypoint camera trigger please, especially if it can repeat several times

A way to do bungee launch throttle suppress could be to monitor the longitudinal acceleration and watch for the fall off -and- build in a delay to full on.  The thresholds for time and acceleration would be parameters to accomodate different launchers.  One thing that would be helpful would be data on acceleration v. time for your launcher from the "raw" group.  Not that I'm programming this, but I see how it could be done. You could use a onset trigger, tail off trigger and event duration.  This way you could utilize levels, time or both.

currently when a magnetometer is enabled the heading is set once it's recognized that the plane is moving more then 3 m/s. If the throttle were simply suppressed until this heading was set that'd be perfect for my application. I just need the positive pitch and stabilization on launch, then power on once heading is established.


Thanks for your work!

I've added an issue here : (RTH altitude managing)


Why my issue is closed.?


Is there really a need?

I had RTL crashes too, same way, and realized that they can be overcome by setting the ALT_HOLD_RTL param higher than the highest terrain, relative to home, that you expect to fly over. At RTL, the plane will go direction home, and climb or descend  within min. and max. pitch to home+ALT_HOLD_RTL altitude. Typically the target altitude is reached long before home position.

Is that the same feature that you requested?

In my experience so far, more complex features gets us more confusion and uncertainly. I like the relative simplicity of the current solutiuon.




Thanks for the reply,

Not really your solution, but something little different:

Explanations :

-Set "default alt" to 100 meters high above the ground.

In actual Arduplane code:

1) If you engage (or your failsafe engage) a RTL when your plane is under "default alt".

Your plane climbs to reach "default alt" -> OK

2) If you engage (or  your failsafe engage) a RTL when your plane is above"default alt".

Your plane dive to reach "default alt" -> Problem because you loose lot of potential energy to return to home. (In FPV flight, you could easyly lose your plane). Another problem , if there is an obstacle on the way of the return to home, you could crash.

The other solution could be that :

1) If you engage (or your failsafe engage) a RTL when your plane is under "default alt".

Your plane climbs to reach "default alt" -> OK

2) If you engage (or  your failsafe engage) a RTL when your plane is above"default alt".

Your plane keep the currentaltitude -> It's safer because you keep a maximum of energy keeping current altitude. If you loose your motor battery, your plane will accomplish more distance than the actual code.

(Option : when the plane reach home position, we can imagine circle down until "default alt")

Some post about the problem :





A steady, linear descent from above the set altitude would be nice to have. But if someone really flies his plane of of range and too far out to cruise home on remaining power, he must have wanted to lose it...



we look forward to be able to solve camera triggering  problem.

Thanks for your work!

Hello Tridge,

It have been realeased an update in Mediatek Firmware to version 1.9.

Since for older versions of arducopter the new firmware is not compatible, would the new version of arduplane be compatible with this new gps firmware version?

It would be great since I'm tempted to take my APM2.0 from my quadcopter and try it on my planes (upgrading/downgrading gps firmware everytime I'll change between quad and plane would be at least annoying :S ).

If you want, I could include it as a item in the issues list that you refered.




Reply to Discussion



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

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service