APM:Plane 3.2.1 released

APMPlane.jpgThe ardupilot development team is proud to announce the release of version 3.2.1 of APM:Plane. This is primarily intended as a bugfix release, but does have some new features.

The major changes in this release are:

  • fixed a mission handling bug that could cause a crash if jump commands form an infinite loop (thanks to Dellarb for reporting this bug)
  • improved support for in-kernel SPI handling on Linux (thanks to John Williams)
  • support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to Pavel, Holger and and PX4 dev team)
  • Multiple updates for the NavIO+ cape on RaspberryPi (thanks to Emlid)
  • multiple automatic landing fixes, including improvements in flare detection, glide slope calculation and lag handling
  • fixed a bug that could cause a change altitude MAVLink command from causing a sudden descent
  • re-enable CLI on non-APM1/APM2 boards
  • Lots of EKF changes, including reducing impact of ground magnetic interference, reducing the impact of a GPS outage and integrating optical flow support
  • added initial support for the PX4 optical flow sensor. Just logging for this release.
  • added support for MAVLink packet routing
  • added detection and recovery from faulty gyro and accel sensors
  • improved arming checks code to detect a lot more error conditions, and change the ARMING_CHECK default value to check all error conditions.
  • added support for BBBMini Linux port
  • increased number of AVR input channels from 8 to 11
  • auto-set system clock based on GPS in Linux ports
  • added SBUS FrSky telemetry support (thanks to Mathias)

IMU Failure detection

Perhaps the most important change for this release is the improvement to the detection and recovery of bad IMUs. We have had a number of reports of bad IMU data in flight from both the mpu6000 and lsm303d. Where possible the drivers how try to detect the failing sensor and reset it. Sometimes it can't be reset, in which case it will be locked out and the other IMU will be used, unless it is the last available IMU, in which case it will still be used. In either case the user is notified of the failure via the GCS so they can land.

UAVCAN support

The main new feature in this release is support for UAVCAN ESCs, GPS modules, compasses and barometers. Note that while support is in for UAVCAN ESCs and I have been flying with a UAVCAN ESC on my test plane for a few weeks very successfully, support for configuring the ESC is still fairly basic. You will need a debug cable to connect to the ESC to configure it as per the website. We hope to add MAVLink enabled configuration soon.

Many thanks to everyone who contributed so much to this release with bug reports, patches and suggestions. My apologies that we didn't get everything done that we wanted to get done. We have pushed some things out to the next release to prevent the release date sliding back any further.

Happy flying!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Thats alot of connectors for S.port , can the pixhawks uart invert and does it support single wire serial ? if not im sure we could get in down to a 4.7k resister and a cheap inverter cable , i plan on adding S.port and Jeti Duplex telemetry as soon as i can afford a pixhawk im just sure we dont need all that mess of cables :)

  • Andrew,

    That's what I was looking for a very long time !

    Mavlink message type RC_channels_override  (#70) can also overwrite this 3 additional channels? 

    Are there any other ways to use this additional channel inputs ? (other mavlink message types) ( special arduplane parameters assigment) ? 

  • Developer


    yes, if you have a receiver that can produce more than 8 channels and that can connect to the APM2 as PPM-SUM then you can use up to 11 input channels.

    Cheers, Tridge

  • Hello Andrew,

    great to hear about new AP firmware release !

    Could you add some more detailed information about:

    "increased number of AVR input channels from 8 to 11"

    Does it mean that we are now able to feed the pixhawk/APM board with 11 input signals ?

  • Thanks Mathias/Tridge

  • Mathias thank you very much

  • Developer
    The docs on setting up FrSky S.Port support are here:
  • Developer

    @Mark, yes, it is the smart port protocol

    @Jeroen, yes, sorry for the typo

    @Paul, I'm hoping Mathias will extend the wiki docs soon on how to use it

    Cheers, Tridge

  • "added SBUS FrSky telemetry support"

    That should probably read: "added FrSky S.PORT telemetry support"

  • Hey Tridge, well done man ! see the enormous amount of changes, shouldn't it be a 3.3 rather than 3.2.1 ?

This reply was deleted.