I've just released ArduPlane 2.60

The main new features in this release are:

  • wind estimation
  • long term dead reckoning support
  • wheeled takeoff and landing support
  • optional new roll/pitch/yaw controllers from Jon Challinger

For a description of the first 3 new features have a look at my previous post. All of these features have been test flown on my PulseXT 40 and have performed very well.

The new roll/pitch/yaw controllers from Jon can be enabled by building with


in your APM_Config.h. If you enable the new controllers then I strongly suggest you read Jons blog post about the new controllers and how to tune them. These controllers are still experimental, but if we get good feedback on them from users we will quite likely adopt them as the standard controllers in a future release.

Other changes in 2.60 include:

  • a new RECEIVER_RSSI_PIN compile time option, to allow you to display receiver RSSI via MAVLink. This should be useful for FPV flying.
  • an important fix from Jason Short for an erase bug in the dataflash. If you use dataflash logs then please erase them after loading this release to ensure the pages are properly initialised.
  • support for the new features in the new MTK GPS firmware
  • updates to the configuration parameters for the Mount code. If you use the mount code, then please check your parameters carefully, as some things have changed.
  • a fix to the JUMP command in missions, which solved a problem where the wrong command could sometimes be run
  • a fix to the initial yaw from AHRS when using a compass
  • new "OBC" failsafe code as a compile time option
  • new RST_MISSION_CH option
  • new STICK_MIXING option
  • support for dual stabilisation mounts (eg. one camera and one antenna)
  • removed old CLI switch and dip switch support
  • fixed a derivative filter bug that could have a small affect on AHRS attitude
  • fixed LOITER_TIME to match MAVLink spec (time is in seconds)
  • added FBWB_ELEV_REV option

Happy flying!

Views: 6567

Reply to This

Replies to This Discussion

Hi. APM controls the rudder in two ways:

1. It applies rudder in the direction of aileron deflection to counteract adverse yaw. If you pick up the plane and tilt it to the side while stabilization is on, the rudder should deflect opposite the roll (upwards.) This effect is adjusted by KFF_RDDRMIX

2. It applies rudder proportional to lateral acceleration, which means that the rudder will deflect in the direction of the roll (downwards) if you tilt it. This effect is adjusted by the yaw PID.

By the way, I recommend only setting the I term of the yaw PID, to something fairly high, in the 2-5 range.

OK, thanks for explanation.

Both cases seems to be reaction to tilting but counteracts (rudder movement). Or second case depends moreover on lateral acceleration?

Try setting only one at a time, and see what they do. If you have telemetry, graph the Y accelerometer, and graph the turn rate as you start rolling, and graph the actual rudder output, and then use the graphs to tune the gains.

Just to clarify. If I roll the plane to the left in stable mode, the left aileron goes down obviously and the rudder should go right to correct a yaw to the left because of the roll to the left? Is that how it should work? I usually test to see if the direction is correct by putting it in stable mode and then giving full left stick on the roll so the left aileron goes up and the rudder goes to the left to assist the turn.

Any recommendations for I max?

Also what’s the philosophy behind using 0 P and a very high I?


Would no gps lock effect the altitude hold. Again it holds altitude in a right 45 degree bank. To the left it initially holds altitude but then starts in a spiral dive. I noticed the gps was turning blue but apm was reporting 0 sats.

I have this bug also, on APM 1.4 :(


I am recently using the ArduPlane 2.6 code (MP 1.2.9) with my APM1.4 and noticed a strange behaviour when looping a path with the do_jump command. EEPROM was erased before loading AP2.6, APM was reset.

Now, this is how I programmed the mission:





do_jump to WP1

WP6 (fake)

WP7 (fake)

This is what the plane does:





HOME, moves towards ground altitude but as I have put HOME in between the WP4-WP1 path, after it reached HOME (descending), it goes further to WP1 and repeat above cycle.

So somehow the home location gets in between the WPs while looping.

I am attaching the log files, I hope someone can have a look.

thanks in advance



Hi Dries,

I believe this is fixed in 2.61. Please test!

Cheers, Tridge


I'll test it out as soon as weather permits and report back!
Also looking forward to test out the new non-airspeed control functionality



Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service