Autotune: hexa sudden climb 40m -- CTUN.Dalt negative -- DANGER

[Webillo]

These are two autotune logs:
-First log: using a weak but still usable battery.
-Second log: using a fully charged good battery.
After first, I disarmed with Autotune on (ch7 switch), so for second should be used the modified parameters on first.

Both autotunes were done on AltHold around 3m high (under sonars range). First autotune with first battery (weak) was normal, but a few seconds after starting second autotune with second battery (good) it suddenly started climbing towards selenites.

Hexacopter F550, 10" propellers, 4S, a bit overpowered (without camera and gimbal):
Frame: HEXA
RCOut: PWM:1-8
fmuv3 002F0046 32385108 38383435
ChibiOS: d4fce84e
ArduCopter V4.0.3 (ffd08628)
Frame: HEXA
RCOut: PWM:1-8
fmuv3 002F0046 32385108 38383435
ChibiOS: d4fce84e
ArduCopter V4.0.3 (ffd08628)

First battery (weak) voltage drop was more than 1V during autotune:

but on the second autotune second battery voltage voltage was higher and voltage drop was less:

Battery voltage compensation was active on both autotunes:
MOT_BAT_VOLT_MAX,16.94
MOT_BAT_VOLT_MIN,13.5

There was also a battery current limit:
MOT_BAT_CURR_MAX,40
MOT_BAT_CURR_TC,3

During first autotune current was around 35A:

but current was much greater on second autotune while ascending:

These are barometer and rangefinders altitudes for first autotune:

and these for the second:

Spikes on rangefinders seem to appear always with bright sun and over dry yellow grass.

There are two GPS’s, giving similar altitudes.
First autotune:

Second autotune:

These are CTUN.Dalt and CTUN.Alt for first autotune:

and these for second, very strange:

It could happen that if it “thinks” it is at -80m high it would climb immediately.
Unfortunately, there was an altitude fence, but it was disabled:
FENCE_ALT_MAX,10
FENCE_ENABLE,0
although if it “thinks” it is at -80m high perhaps would be useless.

This is the pressure on the barometer for first autotune:

and this for second autotune (with output to first motor):

Vibration levels were moderate for first autotune:

but suddenly exagerated (following 11 seconds of normal autotune) for second while climbing:

Roll and pitch were maintained on both autotunes (horizontal):

(On second, shown with BARO.Alt to show that it was horizontal during sudden climb)

So what really matters is knowing the initial cause for it to suddenly climb. I am not sure if second autotune higher battery voltage is a cause for it or a coincidence.

Others:
-Why CTUN.Dalt altitude suddenly appears 80m negative in second autotune?
-Why so high vibration levels on second autotune?
-Why 40A current limit not obeyed in second autotune?

Thanks for any help.

[mboland (Mike Boland)]

You can see the cause of the climb in VIBES
With that much clipping the obvious result is loss of altitude control.

Finding the physical reason for that vibration is going to be trickier.

[rmackay9]

Yes, as @mboland says the vibration levels are quite high. I’d go so far as to say incredibly high at over 120m/s/s. We recommend keeping the levels at below 30m/s/s for Z and below 15m/s/s for x and y axis.

In this case the vibration failsafe started and brought the vehicle back under control. I’m sure the altitude hold wasn’t good but at least it didn’t climb too high. It’s very good that this copter had 4.0 on it or the result would have been much worse.

@Webillo, I think when building a new copter, it would be good to check the vibration levels as one of the first steps.

[proficnc]

How is your flight controller mounted?

[Webillo]

Thanks all for your analysis. Possibly there are vibrations in excess, so I’ll correct that. But still there are strange facts:
-Given there are vibrations and FS_VIBE_ENABLE=1, should it go up suddenly?
-There are differences on both autotunes (batteries used), but there was battery voltage compensation (moreless the recommended values):
MOT_BAT_VOLT_MAX,16.94
MOT_BAT_VOLT_MIN,13.5
Is something wrong, as if meaning compensate above 16.94V (absurd) and below 13.5V (absurd)?
Is battery voltage compensation active in autotune?
-Parameters messed, as CTUN.DAlt and CTUN.Alt reaching -80m. This has no sense.
-MOT_BAT_CURR_MAX=40 ignored.

Here is a video of both autotunes tlog capture:

20200906 Hexa-4 autotunes experimental experiment

First autotune: shows “AutoTune: success 0/4”, so possibly unsuccessful because of vibrations.
Second autotune:
-Hud shown captured with red bars on EKF, high vibrations and height -66m.
-Autotune starts at 5’35".
-Proceeds normally during around 11" (visually no vibrations, several autotune twitches observed).
-Suddenly goes up at 5’46".
-On Vibration Failsafe it says that when triggered “Vibration compensation ON” will appear on the Ground Station HUD, and when recovering “Vibration compensation OFF” will be displayed on the HUD, but neither appears on above video.

@mboland

cause of the climb in VIBES

Yes, but vibrations were moderate during 11" of the second autotune, visually no vibrations were observed, and suddenly it went up towards selenites.

@rmackay9

go so far as to say incredibly high at over 120m/s/s

11" of normal autotune and then suddenly up towards selenites, with CTUN.DAlt and CTUN.Alt reaching -80m (negative). No holes, unevennesses or similar at the site.

I’ll try to be under the vibration values you say

@proficnc

How is your flight controller mounted?

With adhesive sponge tape. Certainly I’ll substitute it, with a thicker and softer one.

[rmackay9]

The “Vibration compensation ON” and “Vibration compensation Off” appear in the Hexa4_autotune2incomplete_batstrong_229_2020-09-06 11-27-54.bin file so they were sent to the GCS. If this message doesn’t appear in the telemetry log then I think it’s most likely a bandwidth issue or perhaps just too many messages were being printed at the same time so it didn’t appear for long.

The vibration compensation failsafe takes some time to recognise the problem so the vehicle often shoots up for a bit before the failsafe is engaged. 40m is about what we’ve seen in the simulator for really bad vibration levels.

[Webillo]

@rmackay9

The “Vibration compensation ON” and “Vibration compensation Off” appear…

Thanks, very clarifying.

Have you an explanation for negative CTUN.DAlt and CTUN.Alt, reaching -80m? Barometer pressure descends (copter goes up), so I can’t understand this.

[rmackay9]

@Webillo,

With such high vibrations levels a lot of IMU data is lost and so the altitude estimate will often drop. The desired altitude will also be pulled low because (for safety reasons) we don’t allow the desired to be too far from the actual.

[Webillo]

@rmackay9

altitude estimate will often drop

This window capture (1490x4673) represents BARO.Press and CTUN.ThO, with CTUN messages. There is an interval in which there is full power and during one second CTUN.ThO=1. CTUN.DAlt and CTUN.Alt begin to be negative there.
Moreless there is the message you show in your capture above “Potential Thrust Loss (3)”.

The one second duration is curious. Under what circumstances would it happen?

[Webillo]

@Webillo

There is an interval in which there is full power

Similar case:
Vibration, EKF variance and associated GPS Glitch results in cascading failsafe