The ArduPilot development team is proud to announce the release of version 3.6.0 of APM:Plane. This is a major update so please read the notes carefully.

The biggest changes in this release are:

  • major update to PX4Firmware code
  • major update to QuadPlane code
  • addition of MAVLink2 support

Updated PX4Firmware

The updated PX4Firmware tree greatly improves support for the new Pixracer boards as well as improving scheduling performance and UAVCAN support. It also adds OneShot support for multirotor motors in QuadPlanes.

QuadPlane Updates

The QuadPlane changes are very extensive in this release. A lot of new features have been added, including:

  • improved automatic weathervaning
  • greatly improved support for mixed fixed wing and VTOL missions
  • automatic RTL with VTOL land
  • VTOL GUIDED mode support
  • greatly improved transition code
  • new tuning system for VTOL motors
  • extensive upgrade to logging system for much better flight analysis

The new QuadPlane features are documented at:

Please read the documentation carefully if you are flying a QuadPlane!

Tiltrotors and Tiltwings

This release has initial support for a variety of tiltrotors and tiltwing configurations. So far testing of these types of aircraft has been limited to simulations and it should be considered very experimental.

MAVLink2 Support

The new MAVLink2 support will allow for greatly expanded MAVLink protocol features in the future, and includes support for signing of MAVLink connections for the first time, making them secure against malicious attacks. I will do a separate blog post on upgrading to MAVLink2 soon. MAVLink1 is still the default for this release, but you can enable MAVLink2 on a per port basis by setting SERIALn_PROTOCOL=2.


Many thanks to everyone who has contributed to this release. Tom and I have been delighted at the number and quality of contributions across the community, and to the extensive testing and flight logs that have been provided.

We would also like to give a special thanks to UAV Solutions for sponsoring the development of many of the new QuadPlane features in this release and Airphrame for development of the improvements to the landing code. We'd also like to thanks aAVIonix for providing hardware for testing of ADSB features.

Special thanks also for the great contributions by many long term contributors to the project. Major contributions to this release have been made by:

  • Peter Barker
  • Lucas De Marchi
  • Gustavo Jose de Sousa
  • Leonard Hall
  • Paul Riseborough
  • Francisco Ferreira
  • Michael du Breuil
  • Grant Morphett
  • Michael Oborne
  • The PX4 development team

among many others. Tom and I really appreciate the effort!

Some of you may also have noticed that Tom Pittenger from Airphrame is now co-lead with me on the fixed wing support for ArduPilot. Tom has been a major contributor for a long time and the dev team was delighted to appoint him as co-lead.

Other Changes
Detailed changes in this release include:

  • added motortest for all quad motors in sequence
  • merge upstream PX4Firmware changes
  • new AC_AttitudeControl library from copter for quadplane
  • modified default gains for quadplanes
  • new velocity controller for initial quadplane landing
  • smooth out final descent for VTOL landing
  • changed default loop rate for quadplanes to 300Hz
  • support up to 16 output channels (two via SBUS output only)
  • fixed bug with landing flare for high values of LAND_FLARE_SEC
  • improved crash detection logic
  • added in-flight transmitter tuning
  • fix handling of SET_HOME_POSITION
  • added Q_VFWD_GAIN for forward motor in VTOL modes
  • added Q_WVANE_GAIN for active weathervaning
  • log the number of lost log messages
  • move position update to 50hz loop rather then the 10hz
  • Suppress throttle when parachute release initiated, not after release.
  • support Y6 frame class in quadplane
  • log L1 xtrack error integrator and remove extra yaw logging
  • limit roll before calculating load factor
  • simplify landing flare logic
  • smooth-out the end of takeoff pitch by reducing takeoff pitch min via TKOFF_PLIM_SEC
  • added support for DO_VTOL_TRANSITION as a mission item
  • fixed is_flying() for VTOL flight
  • added Q_ENABLE=2 for starting AUTO in VTOL
  • reload airspeed after VTOL landing
  • lower default VTOL ANGLE_MAX to 30 degrees
  • Change mode to RTL on end of mission rather then staying in auto
  • implemented QRTL for quadplane RTL
  • added Q_RTL_MODE parameter for QRTL after RTL approach
  • reduced the rate of EKF and attitude logging to 25Hz
  • added CHUTE_DELAY_MS parameter
  • allow remapping of any input channel to any output channel
  • numerous waf build improvements
  • support fast timer capture for camera trigger feedback
  • numerous improvements for Pixracer support
  • added more general tiltrotor support to SITL
  • only save learned compass offsets when disarmed
  • support MISSION_ITEM_INT for more accurate waypoint positions
  • change parachute deployment altitude to above ground not home
  • added AP_Tuning system for QuadPlane tuning
  • added initial support for tiltrotors and tiltwings
  • added LOG_REPLAY and LOG_DISARMED parameters
  • added Q_GUIDED_MODE parameter
  • major update to QuadPlane documentation
  • added MAVLink2 support
  • fixed origin vs home altitude discrepancy
  • improved Lidar based landing glide slope
  • fixed throttle failsafe with THR_PASS_STAB=1
  • prevent EKF blocking during baro and airspeed cal
  • allow for ground testing of parachutes with CHUTE_MINALT=0
  • fixed elevator stick mixing for above 50% input
  • added QuadPlane ESC calibration

Happy flying!

Views: 7165

Comment by Jeremy Randle on July 21, 2016 at 1:47am

My problem is with a Spektrum Receiver, not Futaba.

I have been using a genuine 3DR Pixhawk and a Spektrum AR7700 receiver with no problems in my existing aircraft. The receiver is connect to the Pixhawk via its SRXL output.

I have been using Plane V3.5.2 with no problems.

I am now trying to replicate this setup for a second aircraft. Under Install Firmware the latest version of Plane is 3.6.0 Tried to find 3.5.2 under the Previous Versions but it was not visible. Next most recent version was 3.5.0

I Installed 3.6.0 but the throttle channel and Flight Mode Channel (5) kept bouncing around in terms of the measured values. I recalibrated Radio twice but pointless when the values keep bouncing around. I plugged a servo in to the Gear Channel (5) and there were no jumps in the output. I don't think there is a problem with the receiver.

I then tried an identical new receiver and had exactly the same problem. The servo plugged in directly was also fine,.

I then installed Plane version 3.5.0 and it works perfectly, no jumping on Throttle or Flight Mode.

I can only conclude that something to do with reading the Spektrum receiver port changed in version 3.6.0 even though there is no mention of it in the the revision notes.

I hope somebody can help. My preferred solutions in order would be..

1) Can somebody please tell me how I can see version 3.5.2 to install it.
2) Can somebody tell me how to get version 3.5.2 off my existing Pixhawk and copy it to my new one
3) Can somebody please fix version the code and release a new version.



Comment by JB on July 25, 2016 at 9:22am

Hi Tridge/Tom

I've posted a safety issue for quadplane on the arduplane forum that I think needs attention:


Comment by Tom Pittenger on July 25, 2016 at 9:30am

Hi @JB,

Thanks for the post, I responded there.

Comment by Omri Ifrah on August 6, 2016 at 2:06am


as soon I did update to arduplane 3.6.0 I got "BAD_AHRS"...

why and how to fix it?

Comment by UAS_Pilot on August 16, 2016 at 11:25am


How does 3.6 handle Barometric pressure changes to prevent large altitude variations over long endurance (8hrs) flights. 



Comment by Tom Pittenger on August 16, 2016 at 11:29am

Great question. As far as auto landings go, there is a recent change that I think made it into v3.5, maybe it was 3.6. When using a rangefinder it will remove the big bump from the baro drift. Landings are much smoother and the baro drift is handled gracefully. This does not effect in-flight offset though.

Comment by UAS_Pilot on August 17, 2016 at 6:27am

Thanks for the response, But I am not looking at just landings. If you are flying at 3000' and a maned airplane is flying at 3500' indicated and the Barometric pressure changes and the manned airplane adjusts his Alt. setting. He is now too high and will be lowering alt to meet up with the desired alt of 3500' The UAS does not make this adjustment and is still at the 3000 but actually it is at 3500.. See where i am going with this..... They are reporting different alt. but at the same alt. This is going to be an issue for long endurance flights. We need an easy way to enter new altimeter settings like manned aircraft so that we are also adjusting for barometric changes.


Comment by Nick Sargeant on August 17, 2016 at 7:11am

Joe, a valid concern! Out of interest, what platform do you have that can fly for 8hrs (and where do i buy one :P )?

Comment by Pascal P. on August 17, 2016 at 7:58am

Joe, during flight and out of barometer, only source of altitude will be long range laser and GPS. Accurate altitude would need differential GPS. But if +/- 10m is enough in Z, raw GPS + EKF should be enough.

Comment by Tom Pittenger on August 17, 2016 at 10:00am

Any feature requests (and bugs) listed here will be forgotten because it's not searchable. Please post an "issue" here: so developers can be aware.

As far as baro drift management, there's GND_ALT_OFFSET which allows you to manually enter a baro drift value, if known:

You can fly with EK2_ALT_SOURCE=3 for GPS only: and there's talk of adding ability to merge baro+GPS together too.

Baro drift in drones is not nearly as bad as full scale aircraft. They auto calibrate/zero on every takeoff and the technology used in full-scale aircraft vs drones is a huge difference. The sensors in drones these days are new-age technology which are temp compensated where the ones in the aircraft are quite old. Also, they calibrate what your AGL is compared to the ocean then an offset is given for the nearest airport. That gives a lot of room for error. Drones give you AGL and GPS alt of your exact location at takeoff. It's just totally different method. You'll never see anything near 500 foot error in your baro.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service