APM:Plane 2.76 released

Archive
1

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
[/ul]

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:

scaled_dcm-err.jpeg768×404 31.4 KB

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
[/ul]

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
[/ul]

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.

Happy flying!

2

Good to see these bug fixed, many thanks I will download now :slight_smile:

Did you manage to re add the external LED option at all ?

3

Hi,

Today i did 6 flights on 2.76.

Wooow! :slight_smile:

It did very well!

AS auto calibration works now! I have set the ratio to 2,2 and it corrected it to 2,22.
It seams i was close. :smiley:

Did try auto takeoff and landing also.
On landing my plane got close to stall speed, but it did land nice.

On wind, i have a question. I think in a way it is a bug;

When i fly in level, it shows the right value for wind speed.

But when i climb or descend, it increases depending on the angle my plane climbs or descends.

Like theoretically if i dive 90° to the ground, my GS is 0, but as my AS let’s say 100 km/h than it would show a 100km/h wind, even if there is none. If the angle is 45° than 50 km/h, etc.

Are you planning to improve this?
On osd i had an if on this.

Like if my vertical speed is higher or lower than a value, than it did not update the wind variables.
It hided this on OSD. Far from nice workaround.

Gábor

4

Gabor, seems like you made an important observation regarding the climb / descend wind calulator.
Maybe you should consider filing an issue on the GitHub?

Tom

5

I am facing a problem in uploading the 2.76 version via Arduino IDE.

It gives me this error

[color=#FF0000]avrdude: verification error, first mismatch at byte 0x3c000
0x29 != 0x08
avrdude: verification error; content mismatch[/color]

If I go back to version 2.75, it compiles and uploads fine.

What could be the problem here?

6

@mzahana:
You already posted this question here!
[color=#FF0000]Please refrain from crossposting the same question all over the forums![/color]

7

Just want to show you, how much fun i had using 2.76.

To fly like this you really have to trust in your autopilot, and i do! :slight_smile:

(Also it was a long awaited weather.)

So these are my “thank you pictures”:

Gábor

8

Hi All,
I had a strange crash last weekend. I have APM with HK Clone which is flying on SkyEye. I was trying to see how long it can fly therefore i setup a mission and repeat it few times, after second or third repeat. It was entered to deadly spin and crashed i try to switch to manual mode to recovery unfortunately, couldn’t recover it.

I would be glad if some expert could analyse the log files and tell me what is wrong.

Thanks
Aytek

9

Testing a X8 wing and after enabling the airspeed autocal the value is now on 1.447 from 2.4 which I had set. Is this the value it will be flying with currently or is this while it is sitting on the test stand in still air?

Secondly, is that a realistic value considering the old one was 2.4 and was found by experimentation?

Another Q, is some sort of autotune being considered for APM:Plane, like on APM:Copter?

10

I know everybody very busy but i really need a help. And boy has a change to help me ?

Aytek.

11

I would say something failed, broke or came loose just before the crash, possibly an aileron, pushrod or servo, I could be wrong but that’s my interpretation based on:
At 09:51 the yacc raw_imu_t suddenly deviates (vibration or oscillation) and the servo1 out (aileron) tries to stop the shaking/oscillating.
At 09:56 there’s a switch to manual but I’d say whatever broke or came loose perhaps did not allow for regaining control?

12

[quote=“aytek”]I know everybody very busy but i really need a help. And boy has a change to help me ?

Aytek.[/quote]

Aytek, I am not too good with helping others yet as I can barely help myself. But I looked at your log file and you had a couple of errors on the HUD that are unknown to me… but at those times you had some weird stuff going on with your voltage … It dropped to 14 volts for a few seconds the first time then the second time same thing but ended with a crash.

Is your battery okay?

EDIT: I did not see the reply right above mine, so he is probably correct…

13

Repeating this as it got no responses:

Testing a X8 wing and after enabling the airspeed autocal the value is now on 1.447 from 2.4 which I had set. Is this the value it will be flying with currently or is this while it is sitting on the test stand in still air?

Secondly, is that a realistic value considering the old one was 2.4 and was found by experimentation?

Thirdly, is some sort of autotune being considered for APM:Plane, like on APM:Copter?

14

Graham, harfordhawk.

Thank you for your time and checking my logs. I was sick and couldnt reply until now.

When i was check the pleane after crash all surfaces attached and working. However there was a huge vibration while motor running may be because of vibe or damaged mpu chip cause the crash.

@Graham, as far as i know there is bug in auto speed cal code. I disable it from params.

Anyway,

Thank you for your time.
Have a nice days
Aytek

15

Hi! I’m having a little trouble. The GCS failsafe is activating even though the GCS is connected.

There is no difficulty issuing commands from the GCS or writing waypoints, and telemetry is coming in loud and clear. It does this whether it is connected via USB or radio, even if the radio is at 99%.

Any ideas? Thanks!

16

Graham,

You will need to run the airspeed autocal while the plane is flying. It uses a Kalman filter to estimate the airspeed ratio, probably by comparing the reading to GPS speed at a range of heading angles to remove the effect of wind (I haven’t looked at the code).

Sam

17

Sam,

I have the airspeed autocal enabled as my post clearly says, I was wondering about the discrepancy. The value gets calculated on the fly and if it varies by more than a certain percentage over a period of time it, it changes.

Graham

18

OK, I’m going to stick my neck out here, but after about 60+ hours of flying v2.76 I’m convinced it has a serious bug. (Or all our APM’s are bad :open_mouth: ).

We’ve tried 9(!) different airframes, tuned the planes to the nth degree, fixed every issue that has cropped up or been overlooked, triple-checked, reflashed, reset, erased, changed every parameter we can think of or that has been suggested to us but still are getting the following:

  • loss of height during downwind leg of turns, sometimes a little (2-5m), sometimes a lot (20-40m), the stronger the wind the greater the loss.
  • the motor then races to gain altitude
  • only when the aircraft turns back into wind is the altitude regained and then the motor slows down.
  • if the loss of altitude is high then the aircraft goes SO fast attempting to “push” itself higher that it gets dangerous to the aircraft, close to or exceeding VNE, our one X8 exceeded 120km/h.

TECS_speedweight is set to 0 but the motor still screams when the aircraft is low, going too fast and descending.

I’ve said this before, an aircraft turn can be rudimentarily be described as “bank-&-yank”, yet it seems we’re getting the “bank” but NOT the “yank”!

On some airframes in calm conditions this problem doesn’t manifest itself or is very mild so as to be not noticeable.

On Thursday we’ll be going back to v2.73 as there doesn’t seem to be a solution to this and I’ve run out of options.

19

[quote=“Graham Dyer”]OK, I’m going to stick my neck out here, but after about 60+ hours of flying v2.76 I’m convinced it has a serious bug. (Or all our APM’s are bad :open_mouth: ).

We’ve tried 9(!) different airframes, tuned the planes to the nth degree, fixed every issue that has cropped up or been overlooked, triple-checked, reflashed, reset, erased, changed every parameter we can think of or that has been suggested to us but still are getting the following:

  • loss of height during downwind leg of turns, sometimes a little (2-5m), sometimes a lot (20-40m), the stronger the wind the greater the loss.
  • the motor then races to gain altitude
  • only when the aircraft turns back into wind is the altitude regained and then the motor slows down.
  • if the loss of altitude is high then the aircraft goes SO fast attempting to “push” itself higher that it gets dangerous to the aircraft, close to or exceeding VNE, our one X8 exceeded 120km/h.

TECS_speedweight is set to 0 but the motor still screams when the aircraft is low, going too fast and descending.

I’ve said this before, an aircraft turn can be rudimentarily be described as “bank-&-yank”, yet it seems we’re getting the “bank” but NOT the “yank”!

On some airframes in calm conditions this problem doesn’t manifest itself or is very mild so as to be not noticeable.

On Thursday we’ll be going back to v2.73 as there doesn’t seem to be a solution to this and I’ve run out of options.[/quote]

Graham, I am with you. I had a stable platform before upgrading to 2.74, then I went to 2.76, so many problems… I always hesitate to say its a bug, "cause I know I’m not as smart as the people making these developments, but I am at my wits end… for me the RTL and loiter is all out of sorts, but I do get the loss of altitude in waypoints as well… I t was scary first time, but as you say, it doesn’t drop too far every time.

I hate to go back to 2.73 because that means fiddling with MP and trying to find a version of that that works also… they come as a pair, as you know.

What MP version will you use?

20

Actually you can go back to v2.73 with any MP, they’re not released as a pair, just click “Previous Firmware” in the Install Firmware page.

I’m going to try a few more things before downgrading. One is to mechanically increase elevator throw.