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: 6494

Reply to This

Replies to This Discussion

A small errata ... the wheeled takeoff code doesn't work in 2.60 if you enable Jons controllers with APM_CONTROL=ENABLED. I've fixed that in master for the next release.

Quick guide to tuning my controllers. Looks complex, but each step is individually easy:

Gain names:

  • AP Angle P – default 1.0.
  • FF Feed-forward – default 0.4.
  • RP Rate P – default 0.0
  • RI Rate I – default 0.0
  • RMAX – Rate limit – default 0.0 (disabled) – separate up and down components for pitch
  • PTCHCTL_RLL_FF (pitch only) – feed-forward from roll angle. This helps with the pitch diverging during rolls.


  1. Note that APFF and RMAX have defaults that are functionally equivalent to ArduPlane PID defaults (P of 0.4). If you know the P gain that you are using, you can just input it into FF, but don’t go too aggressive.
  2. Fly in FBW-A. Note that stabilize will not do.
  3. I would start with pitch.
  4. Set RP until the plane starts oscillating. Back it off a bit, and then test it in various attitudes and see if you can make it start oscillating again. If you can, keep reducing it until these go away. Then cut it in half or so.
  5. Do the same for RI.
  6. Set FF to zero. The plane should still fly.
  7. The next step is easiest to do with a rate limit set. This is the RMAX parameter. For roll, initially go for 5000 to 7000 (50 to 70 degrees per second). For pitch, initially go for 2500 to 4000.
  8. (For this step, ideally you would have telemetry and can watch a graph of your angle.) Input a large change in the axis you’re tuning, and watch for overshoot. Start setting FF up slowly until it goes away. On most airframes, pitch is a much less linear process so you may not be able to get it 100% perfect.
  9. Repeat for other axis.
  10. Roll hard. Watch your pitch. If it changes, start setting PTCHCTL_RLL_FF up.
  11. Set up the AP gain and RMAX gains to your preferences. AP gain can be set in a fairly wide range to get different behaviors. RMAX can be set to literally anything, it could be set to take the plane two or three minutes to roll 45 degrees, or you can set it to zero for no limit.
  12. Play with the gains until it works the way you want. I caution against setting the feedforward too high, as that will completely clobber the rate limit and cause overshoot or undershoot.

Also note that my blog post is inaccurate regarding stabilize mode. Stabilize mode works now, and there is an additional "STAB_GAIN" on the controllers, which controls how strongly they stabilize when you switch to stabilize mode. It has no other function.

Oh, it is no longer PTCHCTL_RLL_FF, it is just PTCH_RLL_FF

Additionally, there are YWCTL_P and YWCTL_I gains. To tune yaw (somewhat important for dead reckoning during GPS outages, also helps to prevent stalls), graph the rudder output and increase YWCTL_P until the rudder seems to oscillate or get too noisy, then cut it down to maybe a third to half of that value, then set YWCTL_I about 20% higher than YWCTL_P. Set YWCTL_IMAX to maybe 2000 (or 20 degrees).

You'll also want to tune KFF_RDDRMIX. There are 2 ways:

- Graph the turn rate of the plane and increase KFF_RDDRMIX until it doesn't spike in the opposite direction when you initiate a roll. This can be graphed with mavproxy 

- Graph the y accelerometer (RAW_IMU.yacc) and increase KFF_RDDRMIX until it doesn't spike when you initiate a roll.

- I guess there is a third way: just make a wild-ass guess.

Great work!

Iam using an APM2 on an Easyglider with a Futaba 7C 2.4.

Please could someone explain how i would go about using the RST_MISSION_CH?

Iam not really sure where to start.

Thank you

I would imagine, just set it to a channel number that is a momentary switch, and press the button when you want the mission to reset.

Great work Andrew!

About OBC new features, it is possible to set the number of attempts for GPS Loss as well for COMMS Hold if GPS signal returned as well GCS Heart Beats regained?

If time out on GPS Loss it will trigger that Pin you created in the past for Geofence crossed?

Kind regards

Hi Omar,

I didn't put a counter on the GPS loss in the OBC module. It is possible to implement a counter via the JUMP counters in the mission if you want to, or you could manually override the target waypoint if needed.

The geofence pin does indeed still work with the OBC module, but you can also setup a heartbeat pin using the FS_HB_PIN parameter. If you get a dual failure (GPS loss and comms loss) the heartbeat will stop changing (it normally changes at 10Hz). If just the GPS fails, it will start dead-reckoning, as well as jump to the FS_WP_GPS_LOSS waypoint. You can setup that waypoint with a 30s loiter followed by navigation to airfield home.

Good luck for your D3! Have you posted your D3 video somewhere?

Cheers, Tridge

Thank you Tridge!

Interesting combination of the features. For the GCS failure detection, it is taking in account those 10 seconds to start the jump to COMMS Hold?

I asking these questions because I have the rules in my mind as I did some changes in Arduplane according with OBC rules for our team.

Unfortunatelly our plane crashed on the weekend before the delivery so was not possible to complete the logs for D3 :-(.


keep us posted with your advances,


kind regards,


Thank you Tridge, great work

test it next weekend ... 

Nice work John!  Glad to have a PID controller that works well.  How long before this gets set as the default control scheme?

I'm also a little confused by your terminology.  I'm not exactly seeing how it is different from the PID terms.  If you're using a PI controller that works on the rate then isn't that the same as the derivative?

Are you also working on making this an adaptive control scheme?  Eliminating tuning entirely sure would be nice, especially for moving the controller from airframe to airframe.

It is a cascaded PID. Yes, the RP gain basically the D gain. The controller is based on a cascaded PID, but has an additional feedforward gain and all of the unnecessary gains are left out.

The reason this is better is the rate is a faster process. The IMAX is fixed at full servo throw, so this control scheme should easily withstand an aileron servo failure, for example.

No plans for making it adaptive, but I've dabbled in trying to learn the FF gain. I think it is doable.

Hi Omar,

For the GCS failure detection, it is taking in account those 10 seconds to start the jump to COMMS Hold?

yes, it doesn't trigger comms failure until it has not seen a HEARTBEAT message from the ground station for 10 seconds.

Unfortunatelly our plane crashed on the weekend before the delivery so was not possible to complete the logs for D3 :-(.

oh, I'm sorry to hear that!

Cheers, Tridge

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service