APM:Plane 3.0.2 released

The ardupilot development team is proud to announce the release of version 3.0.2 of APM:Plane. This release combines some important bug fixes with some new features.

I2C bug fix

The most important change for this release is a bug fix for an I2C bug in the NuttX I2C driver code that would (under some rare circumstances) cause a Pixhawk to crash. This bug fix is the primary reason for doing a new release now.

This bug was able to be reproduced by creating a 1.3m GPS cable carrying both the I2C signals for a magnetometer and the UART signals for the GPS. Interference between these two signals could cause the I2C controller to give spurious data to the I2C driver. The I2C driver did not have sufficient protection against these errors and could crash the board.

While we have not been able to reproduce this error with the normal cables that come with a Pixhawk we cannot rule out the bug triggering with shorter cables, so we are doing a fast release to fix the bug.


This release also includes an important new feature - automatic roll/pitch tuning. While this feature is still considered experimental we have had very positive feedback from beta testers and have decided to include it in the release.

Full documentation for how to use automatic tuning is available here:

we hope that the automatic tuning will help users who have had difficulty with the standard APM:Plane manual tuning procedure. We plan on extending autotune to other aspects of fixed wing tuning in future releases.

Other changes
  • fixed a glide slope calculation error when very close to waypoints
  • fixed a bug when swithing to another auto-throttle mode during auto takeoff (thanks to Marco for finding this bug!)
  • added MIS_AUTORESET parameter (thanks to Andrew Chapman)
  • support compassmot calibration by supplying current measurments to the compass driver (thanks to Jon Challinger)
  • fixed a GPS driver bug that could cause GPS lag in case of lost GPS samples (thanks to Jon Challinger)
  • fixed a LOITER_TURNS bug in missions for counter-clockwise loiter (thanks to Iskess for finding this bug)
  • added support for OBC termination requirements to PX4IO
  • added support for pressure altitude termination to OBC module
  • fixed EKF wind estimation with no airspeed sensor (thanks to Paul Riseborough)
  • improved tuning of EKF for fixed wing aircraft (thanks to Paul Riseborough)
  • Converted rally point code to library AP_Rally (thanks to Andrew Chapman
  • added SITL checking for numerical errors

Thanks to testers!

Many thanks to everyone who tested the beta versions of this release! Special thanks to Marco, Paul, Jon, Iam, JNJO, sonicdahousecat and Keeyen for providing testing of both existing features and the new autotune code.

Happy flying!
E-mail me when people leave their comments –

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

Join diydrones


  • Tridge, After re-verification  through several times of loading the F/W in APM2.5, I would say that in HIL, the APM 2.5 is not accepting PPM signal from the receiver as it accepts in flight F/W.

    You can check at your end.

  • Hi nicolas levilly,

    I could not simulate the issue with 900MHz telemetry. Can you increase the length of your telemetry cable by soldering additional wires in the middle and keep the radio in the backyard of the fuselage and see ?

  • Hi Andrew,

    Below is the link with latest flights using Autotune Level 5. There are 3 flights with combine Autotune, Loiter and rectangular auto missions.

    Your comments are always welcome.

  • OK, I will try today to do some more flights with Autotune and then I will extract the dataflash log (should be the bin format as I understood).

    Below is the plane I am using, converted to brushless motor.


  • Developer

    Hi criro,

    To answer the question I'd really need to see a dataflash log of the autotune, and know what sort of aircraft you are flying.

    I mean, are they improved even on repeated flight or just in one flight?

    autotune starts with the current tuning values when it is tuning, so it can improve, but it should converge after a few minutes and stop changing (or at least not change by as much)

    Cheers, Tridge

  • Hi Andrew,

    I did test yesterday Autotune on Arduplane 3.0.2, see below the PIDs before/after autotune.

    I did start with Level 5 and I did follow the Wiki description, at least 20 rolls and 20 picth, 'rollercoaster', etc.

    When I treed Level 6, I did find the plane less stable, like overshooting. I was thinking it will stabilize if I fly longer on Level 6, but not. My question is: should I continue with Level 6 or back to Level 5? Second question: On repeated Autotune flights, with the same Level, those PID correction are cumulative? I mean, are they improved even on repeated flight or just in one flight?

    I did find this Autotune very useful. Thanks.


  • Hi Marco,

    No I calibrated my airspeed sensor manually some time ago with anemometer and blower and checked that my measure was well centered on the groundspeed in flight as described on the instruction page, and it was very precise. The calibration, manual or automatic is a ratio only and there is no offset to adjust.(My skyfun flies since years with APM and I think I made more than 1000km planned missions, I remember that some very  old FW version had bad issues with the airspeed sensor, and I just try to help by reporting it now because it look likes some issues are back with the 3.02).

    Yes I tried to move my telemetry module far away (20cm, which is my cable lenght), also put some ferrites but it didn't help. (I also soldered some 20µF ceramic capacitors on the telemetry module to better decouple the 5V supply, but it didn't improve too).

    It looks like the microcontroller ADC get some perturbations/noise depending on the telemetry output power (or power drain from it ?) but what is so strange is that I don't get it with thé 2.78b... Is the ADC / airspeed acquisition synchronized or done differently now that it captures more noise ?(in my case it's a bad offset, look the picture in my previous post)

    I get the same issue than you with the write/read mission during flight (and some time on the ground too) with wrong waypoints, but it is not new, that is why I always read the waypoints I wrote to be sure they are well inside the APM before switching to auto...

    Thank you again !

  • Developer

    Hi Nicolas, have you tried to perform a new "airspeed calibration" with the related "preflight calibration"?
    Also check the shield cable connection of your telemetry and airspeed.
    The only issue i've found is when i try to write ad read a mission during flight with APM 2.6, sometime when I go to read some waypoints are completely wrong, I think this is the fault of the lack of RTS/CTS in the telemetry I'm using here.

  • Hello Andrew, Marco and all dev team

    First thank you so much for all the work you do on the APM... I have so much fun using it !!

    I think I found an issue with the 3.02 (or at least a confirmed behavior difference with the previous FW2.78B I used before).

    My config is APM1 on a Skyfun with telemetry 433, power module, Ublox NEO6M, airspeed sensor.

    With the 3.02, I get a very bad airspeed offset (~4 to 6m/s when I power on the plane).

    With the previous 2.78B I was able to get a very precise airspeed measure and control (I put this Firmware back again to confirm it is not a hardware issue, and it is not). I also discovered that this offset is dependant to my telemetry output power (very strange, I agree..): At 20dBm I get the max offset (see the picture below, a windy day as you can see on the groundspeed, it is not the max error I get, my telemetry was set to 11dB). At 1dB I get almost no more offset, but not a great range too... 

    I confirm it again, with the 2.78B, the airspeed acquisition was ok whatever the telemetry output power...

    Do you have any idea what change can cause this ?

    Thank you again !



  • Developer

    Thanks Marco! Always nice to hear that things work well :-)

This reply was deleted.