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:
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!
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
Comments
Hi Tridge, I seem to be having telemetry problems too
Had an APM 2.6 running 3.03, no problems at all. Both of my Pixhawk boards(one genuine one clone acquired just to test this problem) have a very difficult time connecting with both 3DR radios and XBEE modules, with the problem only occurring on 3.03.
Hi Tridge,
I was asked to make you aware of a problem with APM:Plane v3.0.3
Basically i could not get ANY Mavlink data to my MinimOSD from my PX4.
The only way to get it to work was to downgrade to v3.0.1 where upon it worked straight away.
Here is the link to my problem and findings
http://diydrones.com/forum/topics/adding-extra-functions-to-minimos...
Thanks
James
Hi Tridge,
Thank you for the very informative answer.
Okay, I feel more reassured now. I think we are some who prefer a set of well proven algorithms with known and acceptable limitations, rather than getting involved in trying out new things. I'm into software myself and I knw how surprisingly many flaws in a system can turn up once you let a lot of people use it. But as I read you, there are still only well proven parts actually in control (does it mean the bugs that this release fixed only can occur in a nondefault configuration?) and with some additional possibilities for verification.
Thanks!
Regards
Soren
Hi Soren,
The EKF code is disabled by default. It is off by default because it is still quite new, and is a very complex piece of code.
The main advantage of enabling EKF is that it gives more accurate estimates of roll and pitch, and copes better with sensor errors (eg. small GPS glitches, too much vibration etc). For most people the differences are small and hardly noticeable, but for some people the EKF is a significant improvement and very worthwhile.
The other big advantage of the EKF is that it gives us a second independent AHRS to compare to in the logs. So when I get a flight log and it looks like perhaps the attitude estimate is off I can compare the EKF solution to the DCM solution and see if the two deviate. The fact that they are based on totally different maths makes them fairly independent (this is helped by the redundant sensors too, as in log playback I can choose which set of sensors to use). Both systems are always running and always logging, the AHRS_EKF_USE parameter just determines which one is used to control the aircraft.
Long term I think the EKF will be the default AHRS system, but I won't enable it by default until it has had a bit more more time for us to be confident that it is more reliable than our DCM solution.
Cheers, Tridge
Thanks Tridge for your comments. Yes, I know that FBWA is not an altitude hold mode and that is precisely the most confusing issue of my crash (and maybe one of the reasons because I took so long to react to that problem with altitude). I will continue this analysis in http://ardupilot.com/forum/ as suggested, including log files.
Hi,
Is there a story somewhere to be read on the background of the decision to implement EKF? Which practical benefits does it bring?
I ask because I would like to know what drawbacks there would be in disabling it and returning to only DCM -> fewer potential bugs I would think. But what is the loss?
Regards
Soren
Andrew,
Installed beta , it connection is fine now with both params set AUTO (2). Is there any more changes I need to know in it? I'd like to stick with it.
Eladio,
FBWA mode is not an altitude hold mode, so holding altitude is the responsibility of the pilot. You are probably better off with CRUISE mode.
If you want me to look at the logs then the best option is to post them to http://ardupilot.com/forum/
Cheers, Tridge
Rostislav,
The default values didn't change actually. I think I've found the issue. When you get a chance can you try 3.0.4beta and see if the original values work for you?
Cheers, Tridge
Hi again,
I would like to attach my logs but I don't find the way for doing it... :-(
-
1
-
2
-
3
of 3 Next