The ardupilot development team is proud to announce the release of version 3.0.3 of APM:Plane. This release contains some important bug fixes for all supported boards.

The key bug fixes in this release are:
  • fixed handling of filter divergence in the EKF filter
  • fixed a glide slope calculation bug when entering AUTO mode

The EKF fixes are the main focus of this release. During testing of APM:Plane with the AHRS_EKF_USE enabled it was found that under some circumstances the EKF could diverge, resulting in loss of attitude estimate. Unless the pilot quickly took control in MANUAL this could result in the aircraft crashing.

The fix for this problem was in several parts. The main fix was to prevent the divergence, but as a precaution against future bugs of this type additional numerical checks were added to allow the EKF to automatically reset in flight when the internal state shows large gyro bias changes, which are the first sign of something going wrong in the filter. If this happens again the EKF will automatically disable itself for 10 seconds, allowing APM:Plane to fall back to the old DCM code. The EKF will then reset itself using initial state based on the DCM state. The aircraft will report the failure using the AHRS health bit in the SYS_STATUS MAVLink message.

The default EKF tuning parameters were also updated based on a number of user supplied flight logs to increase the robustness of the filter.

The second bug fixed in this release relates to the glide slope calculation when the aircraft enters AUTO mode for the first time when at an altitude above the altitude of the first waypoint in the mission. The starting point for the glide slope was incorrectly calculated using the home altitude, which resulted in the aircraft descending below the first waypoint altitude before climbing again. In some circumstances this could lead to a crash due to local terrain.

Many thanks to everyone who tested this release. Special thanks to Dellarb for reporting the glide slope bug and to Paul Riseborough for all his work on the EKF code over the last few weeks.

Happy flying!

Please report bugs on the ardupilot forum

Views: 3493

Comment by Dan Wilson on May 18, 2014 at 5:53pm

What was causing the filter divergence? 

Comment by Kevin Hester on May 18, 2014 at 6:37pm

woot!  I can't wait to get back to flying my plane (next weekend)

Comment by paul riseborough on May 18, 2014 at 7:32pm


To get a filter of this size to run efficiently on our small micro, the numerical operations have been heavily optimised and we are using single precision calculations throughout. The divergence was caused when numerical rounding errors, combined with the way were were inhibiting certain states and their corresponding elements in the covariance matrix, resulted in the innovation variance for magnetometer measurements becoming negative under specific conditions. When this happens in a Kalman filter it is often game over as it is equivalent to reversing the direction of feedback in a control system.

This fault first exhibited itself on a copter flight of mine a few weeks ago, but would not repeat when the data was played back in the test-bench. Based on the observed behaviour, I theorised the  fault mechanism and produced a fix, but did not have the conclusive proof needed until it happened on Andrews bushmaster plane. Fortunately with his log we were able to replicate the fault in the replay, and I was able to prove I understood the fault and had a fix for it.

We now have three levels of protection against this fault happening again:

1) The numerical calculations that were causing the negative innovation variances have been revised.

2) The innovation variances are now checked for numerical errors and are not allowed to become badly conditioned

3) The filter now checks for divergence and resets if detected

Comment by Swift on May 18, 2014 at 9:53pm

Thanks Dev Team! 

Comment by Swift on May 18, 2014 at 10:07pm

And by the way I liked the window in Mission Planner showing that a new firmware is available. Nice work! I love it!

Comment by Christiaan van Vollenstee on May 19, 2014 at 12:19am

Hello, I uploaded this new firmware yesterday on my pixhawk and when I do tests to increase the throttle and let the motor spin(which prop on) the pixhawk reboots at around 50% throttle, why would this be? Also is it advisable to tune the PID's (manual) while flying?

Comment by Marco Robustini on May 19, 2014 at 12:23am

Awesome, thanks Tridge!

Comment by Andrew Tridgell on May 19, 2014 at 1:43am

Hi Christiaan,

Rebooting at 50% throttle sounds like a brownout. How are you powering the Pixhawk? If you can post some logs then I could look at the power status messages and see if anything shows up.

Also is it advisable to tune the PID's (manual) while flying?

You can, but you should only try it if you have someone else to operate the GCS, as taking your eyes off the plane is a bad idea. I'd also suggest you look at the new autotune mode.

Cheers, Tridge

Comment by Christiaan van Vollenstee on May 19, 2014 at 2:02am

Hello Andrew,

I am powering the pixhawk with a 3DR power module and the planes BEC from the ESC is in channel 3. What is the definition of a brown out? Is it serious?

Comment by Christiaan van Vollenstee on May 19, 2014 at 2:08am

I will get the logs tonight and post it.


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

Join DIY Drones

DIY Drones Monthly


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service