I’ve just released APM:Plane 2.76. This is a bug fix release for 2.75.
The primary motivations for this release was two serious bugs:
[ul]the airspeed autocal feature introduced in 2.75 was broken
a long standing serious DCM attitude estimation bug was found
The first bug (in airspeed autocal) only mattered if you enabled the new ARSPD_AUTOCAL feature by setting ARSPD_AUTOCAL=1. In that case the bug would lead the airspeed ratio to quickly climb to 4.0, which led to a very poor estimate of airspeed. This was a very simple bug, and was quickly fixed by Paul Riseborough.
The second bug is a long term one, not a bug introduced in recent releases. Under some fairly specific circumstances the DCM attitude estimation code could get a large error buildup, leading the plane to descend rapidly due to a large error in pitch estimate. This bug first came to my attention when Trent from MyGeekShow gave me a flight log for a crash of his Raptor140. The plane was doing a descending turn and lost attitude lock, continuing to dive into the ground rather than recovering. I spent quite some time analysing the telemetry log from the flight but I wasn’t initially able to find the cause. I then got lucky, as I managed to reproduce the problem myself on my AcroWot. I had months of flights on this plane without an issue, then on Friday it exhibited a uncontrolled dive very similar to what Trent had see. I pulled out in manual (pulling 8G while doing it!) so the plane is fine, and luckily I had full 50Hz dataflash logging to the SD card on the PX4 in the plane.
Armed with very detailed logs I was able to get much further on the problem. I wrote a python script to propogate gyro readings over the 11 seconds of flight where the dive occurred, which gave me this graph:
That showed that the controllers in the plane got into a severe oscillation and in a short period of time the DCM attitude estimate separated from reality.
Once Paul and I had that graph I then tried to find a way to reproduce it in the SITL simulator so I could investigate possible fixes. I found I was able to reproduce it by way of overtuning the roll and pitch controllers, then doing a rapid forced descending turn. The roll and pitch controllers would produce a 2Hz oscillation which would feed into a 2Hz 90 degree phase delay in DCM, leading to a rapid increase in DCM error.
The underlying cause turned out to be the lag in the GPS velocity measurements which were used to correct the accelerometers for centripetal forces before being applied as a drift correction on the attitude in DCM. The fact that the GPS velocity lag approximately matched the period of the roll/pitch controller oscillations is what made the DCM estimate diverge so quickly.
Paul and I then worked on several fixes for different aspects of the problem
[ul]we added a settable integrated accelerometer delay buffer to match the expected GPS lag (new parameter AHRS_GPS_DELAY)
we removed some constraints in the DCM code that could lead to DCM bias errors
we added some limits on the roll/pitch controllers to limit the amplitude of any controller oscillation
we also fixed a couple of heading related DCM errors that were found while doing detailed analysis of this bug
The most important change is the addition of the AHRS_GPS_DELAY parameter. In the simulator that solved the problem, and as a nice side effect also improved the attitude estimate accuracy in turns, allowing tigher tuning on the controllers without oscillation.
Paul and I have done several test flights with the new code which all went very well, plus a lot of testing in the simulator.
The release also contains some smaller fixes which would not normally have warranted a new release, but I included in the release:
[ul]fixed I2C semaphore handling for the MS4525DO I2C airspeed sensor on the APM2
added better timestamping on dataflash logs, to make future detailed analysis easier
fixed a uBlox issue where the GPS rate could sometime be 4Hz rather than 5Hz
We hope that you enjoy flying the 2.76 release, and I’d like to thank Trent for providing the initial crash log that sparked the investigation into this bug.