AC 4.6.3 Autotune Crashed

Hi @xfacta
My Quad configuration using below components
1.MAD 5008 300Kv
2.Reflex ESC 6S 60A with ESC telemetry.
3.carbon fiber propeller 18*6.1
4. 6S battery
5. Here4 dual configuration for GPS for YAW.
6.Cube orange+
After basic Configuration done, flown for 1st flight in Stabilize and Althold for 1Minute to collect IMU Batch sample to configure Notch filter configuration.

Since my ESC Support telemetry i configured Notch parameters as ESC telemetry along with other necessary parameters for Notch parameters.

Then Carried Autotune procedure for the very next flight. Takeoff in stabilize mode and change to Althold mode and observed behavior for couple of minutes, then changed mode to Autotune.
After couple of sec it crashed the angle attitude error was 110degree.

any thing i am done wrong in the Notch configuration or PID configuration or anything else.

Vibration level are under control for the flight.

Just a question (did not look into log) - in alhold, did You do some manual roll and pitch to check if that is not getting into oscillations? Hoover itself might be OK, but once You touch the sticks with short aggressive moves bad things can happen. I am asking because I have never crashed during autotune, except once with ESC failure resulting in falling ball of fire and smoke.

yes, i tested with stick input on pitch ,roll on both stabilize and Althold. Additionally in Althold mode done altitude ascend and descend as well.

Regarding the filtering, you should enable also the 2nd harmonic as it is the most prominent on your machine.

But this is not the reason for the crash. I conjecture it’s the initial tuning, which is too sloppy to recover from strong deviations. The reaction to your inputs in AltHold at 8:28 in roll and 8:58 in pitch, among other, suggests me this interpretation.

This is a larger machine than I mainly work with, but I only enter autotune if I am reasonably sure the machine can handle it, which I would not say for your case. Your machine, in my opinion, needs a bit more manual tuning, which in your case, based on in-near-hover angle deviations:

and corresponding PID contributions (roll as an example):

rather requires a proportional increase of rate P, I and D. I would probably start at a factor of 1.5 - but only after notches are fixed as noted above.

The angular acceleration measurements during the two autotune twitches also suggest increasing ATC_ACCEL_{R,P}_MAX by a factor of about 2. The measured acceleration was reported to be about 100k in the units of AC 4.6. A too low value here results in the machine very reluctant to perform sharp output changes, which might have contributed to recovery from the twitches.

After making these changes, perform a short hop (e.g. be prepared to land quickly - so maybe in Stabilize rather than AltHold) to check for oscillations. You can usually see and hear them, but after landing, it would be wise to also check PID log entries, if they exceed 0.1 in amplitude even when you are not doing much of an input, it’s not good, and PID values need to be returned back to where they were - but I conjecture it is unlikely to happen.

If no oscillations, I would test for autotune readiness as follows. Perform an AltHold test with numerous pitch, roll and yaw inputs. Inputs should preferrably be sharp (in terms of how quickly you move sticks), but of different amplitudes (how much you actually move the sticks) - this is to simulate step inputs to mimic what autotune does, but at various smaller scales to find out whether the machine can hold it. You should roughly remember your feelings (e.g. how responsive the craft felt at different stages of the test) and compare these with the logs how well the actual angle was following the desired angle (this would also calibrate your feelings). If the angles are tracked without significant overshoots, it should be much safer to run autotune.

(Sometimes autotune crashes are caused by hardware or ESC issues. I had a spectacular and terrible crash of one machine during the first ever twitch, because a gear tooth broke in one of roll servos, which resulted in constant output roll, which drove the craft into a wall and broke it into tiny pieces. But your logs don’t suggest that anything like that happened.)

Agree with this. There is not enough attitude authority with the Rate PID’s set. Look at this reinforcing Roll oscillation.

After making the changes @MaxBuzz suggests run Quicktune first.

Hi MaxBuzz

Thanks for the detailed analysis and suggestions given for the upcoming test how it should be implemented.

The initial PID I just arrived using the mission planner initial tuning instruction panel as per battery and propellers size I entered.
Based on that I started the flying to collect Gryo noise and applied Notch filter to minimise the Noise to the PID loop.
I would like to know that what is the factor of 1.5 means, do you want me to increase the initial Rate PID value by 1.5 times from the current values and how about the Vibration at this level.

When I use ESC telemetry as a notch driving, I need to set the SERVO_TELE_RATE = 100 hz (default was 10Hz) . Notch driving options I also setup for “Multi source” since 4ESC and Checked the box “Update Loop Rate” . Really I having confused among this parameters how to set up regarding the ESC telemetry update to track the RPM data.

Any phase lag identified after configured the Notch since the Notch bandwidth I configured only 10 to reduce the phase lag .

I need to rebuild the frame as it totally damaged from last crash after that I will follow up your suggestion on that .

Yes, this is what I meant.

Vibe entries look not extremely bad for first two IMUs (VIBE[0], VIBE[1] are generally within 4-8 for X and Y, and within 10-20 for Z) but quite bad for the third one (VIBE[2] are all 20-50). The third one, if I remember correctly, is the one not internally dampened in CubeOrange. To me, this is an indication that you want to improve your assembly. The peak -10 dB of raw noise (in my machines it’s below -30, which is a huge difference) at 2x the motor rotation frequency, aka one hit per prop blade, suggests that this has something to do with the frame arm mount rigidity, but it is very difficult to decide correctly from logs alone.

Roughly 1/5 of the frequency with four notch sources is correct to my eye. (The bandwidth is not 10Hz, it’s 10/54-th (that is, INS_HNTCH_BW/INS_HNTCH_FREQ) of the real reported motor rotation frequency)