I'm delighted to announce the release of ArduPlane 2.50 for your flying pleasure. This release has a lot of advances to some of the core ArduPlane code, and should be a big improvement for many people.

Perhaps the most important change in this release is the new DCM code that does acceleration correction based on the GPS. This improvement is based on work by Bill Premerlani which really advances the state of the art for attitude estimation on small microcontroller based autopilots. The improvement in attitude estimation is very noticable in flight, resulting in significantly more accurate control. Many thanks to Bill for his patience in working with Jon Challinger and myself to bring this improvement to ArduPlane.

Other significant improvements include:

  • updates to the barometer driver to sample the pressure and temperature much more rapidly, leading to better altitude estimation
  • updates to the AP_AnalogSource driver to be interrupt driven, allowing us to sample all analog sources much more rapidly. For ArduPlane this improves the airspeed sensor on the APM2 a lot.
  • updates to the waypoint completion logic, to use a "finish line" algorithm. This prevents the problem of circling around a waypoint when we miss it by more than the waypoint radius. The waypoint is now considered complete when we pass a line that is perpendicular to the track, and passing through the target waypoint.
  • improvements to the AP_Mount code, allowing for control of roll/pitch/yaw stabilisation via EEPROM variables that can be set over MAVLink. This allows you to setup the mount once, and it will resume operation as soon as you boot. These changes also fix a number of bugs in the AP_Mount code, so it AP_Mount hasn't worked for you, please try again. Many thanks to Greg Fletcher and Amilcar Lucus for the AP_Mount improvements.
  • Lots of improvements to the ArduPlane parameter documentation.  This documentation should be the first place you look when trying to understand ArduPlane configuration parameters. Many thanks to Andreas Antonopoulos for his great work on generating these wiki docs based on the source code markup.
  • New LAND_PITCH_CD parameter to control the landing pitch when not under airspeed control. Thanks to Jeff Taylor for fixing this!
  • New SCALING_SPEED parameter that allows you to set the base speed for scaling PIDs. Previously we assumed a standard speed of 15 m/s, which is too low for fast aircraft. By adjusting SCALING_SPEED you can have the same set of PIDs for both airspeed and non-airspeed flight control.

There is one change in this release which may require some re-tuning. We were using the wrong value for time delta when using the PID controller for navigation roll. This has been fixed by making the PID library calculate the delta time internally, but it means that existing HDG2RLL_I and HDG2RLL_D values  will be incorrect. I have fixed the defaults, but if you have your own settings for these, you will need to drop HDG2RLL_I by a factor of 5, and raise HDG2RLL_D by a factor of 5 to get the same result as for the previous release.

Thanks to everyone who has contributed to this release!

For the next release the plan is to concentrate on improved stabilisation and navigation controllers, based on the great work being done by Jon Challinger.

Happy flying!

Views: 15022

Reply to This

Replies to This Discussion

Congrats, Tridge!

Hi Andrew,

I have two questions.

Is FBW_B elevator still reversed in 2.50?

Can i read RSSI information trough MAVlink now?



WOW thx a lot.

Hmm strange can't compile it with the arduino-0100-relax with the 2.4 there wasn't any problem.

Has something changed do I need to take the "real" arduino IDE?

EIDT: OOOPS my fault didn't copy the whole zip into the sketch folder :)



Is there a way to have altitude hold flight if I do not have an airspeed sensor? I would like to be able to just fly around at a constant altitude.



Hi Gábor,

The FBW_B behaviour hasn't changed. Maybe I should add a parameter to control what direction people want the elevator to go for FBW_B ? Some people want it one way and some want it the other.

Cheers, Tridge

Hi Mike,

Altitude hold works fine both with and without an airspeed sensor. The only time when an airspeed sensor is really critical is when you are flying close to the stall speed, which usually only happens when you are landing.

Cheers, Tridge

Hi Gábor,

I forgot to answer your 2nd question. If you have a 3DR radio you get RSSI for that radio through MAVLink, but otherwise we don't yet have it. It's not a big change to add it as long as your receiver/radio gives RSSI in an analog voltage of no more than 5V. Did you submit an issue so I remember for next time?

Cheers, Tridge

Hi Andrew,

First of all, thank you for your attention!

I did not submit this as someone already did: Link

And here is my topic where we are trying to make MinimOsd better: Link

To have RSSI would be great! :)

Also got another  question; witch port should i use for RSSI on APM1?

On APM2 there is a sign.

Thx again,


Hi Andrew,

I submit an enhancement request about RSSI readings. For example, my RX gives 0.5V for minimum signal and about 1.0 V for maximum. The analog read is linear.


This is the request in the arduplane page:



Thanks for your effort.


Regards from Spain,



Hi Andrew,

That would be great!

What made me confused is that i take off in manual mode, than flying a little in stab mode than switching to FBW_B. Suddenly the elevator starts to work reversed. I was like, ughhhh  What is this? :D

As FBW_B is very "automatic", it is not a huge problem, but does not feels comfortable.  

Thank you


The reason that I am confused is because I don’t know what mode to use. I don’t see an Altitude Hold Mode. FBW-B looks like the mode I want but it says that it won’t work without an airspeed sensor and reverts back to FWB-A, which is NOT Altitude Hold. So you see why I am confused?





The RSSI that you are talking about here is not the one we would like.

On the receivers in our planes we have a RSSI output that can be feed to the APM. It can vary greatly from receivers to receivers. I own two from the same company, one goes .5 volts for a bad signal, to 1 volt for a good. The other .5 volts is poor, 3.3 is good.


We can however decode it on the MiniOSD if the raw voltage would be transmitted on the Mavlink message "MAVLINK_MSG_ID_RC_CHANNELS_RAW". Right now it is locked to a 1.


A few lines of code is all it would take, one maybe in the sensor.pde, two in the MAVLink.pde.


Myself, I have tried to modify the APM code, but as you know, a simple change could cause other things to fail, and would rather let the experts handle the APM. As for the MINIOsd, if it fails in flight due to a software bug, I don't lose a plane.


Thanks for reading


Burt Green



Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service