I have remove the heated conversation above as it is not relevant to topic at hand.
@Hover1
I can see you have followed what looks like the mission planner setup guide or similar.
It does look like you have got into a large occilation but the aircraft appeared to be flying reasonably stable before this.
The aircraft seems to respond reasonably well in pitch but roll looks like it may be oscillating. However, the loss of control appears to be more in pitch.
The loss of control seems to be very sudden. I wonder if this is a motor out or maybe a position controller oscillation.
You do have a very large offset between motors. But when I zoom in it doesn’t look like the classic motor loss output. Maybe this is an ESC calibration problem or an offset CG.
It does look strange though. You are commanding a decent of 3.5 m/s. It looks like this decent is what kicks off the oscillation.
Ok, so why did this oscillate…
Before I go into my long discussion on Autotune, I thought of another potential cause of this oscillation. It is possible you are using fixed PWM esc’s and have set the PWM range too large, maybe not set the spin min and max properly. This can create a dead band at the top and bottom of the thrust curve. Once you enter it with a significant disturbance you start oscillating.
The results of autotune are not great but also suggest problems with the way the aircraft is setup or handling. Autotune needed to drop ATC_RAT_RLL_P to 0.02783866 to stop the overshoot. Pitch was a little better but still less than half what I would like to see. It is hard to know without seeing the autotune log. You have halved AUTOTUNE_AGGR to 0.05. This should only be done on a low noise aircraft with all the filtering set up. This makes autotune very fussy on the overshoot and doesn’t leave much room if an aircraft has any problems.
Can you provide the Autotune log?
There has been a lot of discussion about autotune lately. So I will address that again here. The Ardupilot developers have always tried to make it as easy as possible to setup aircraft and manually tuning aircraft has always been difficult for users. Autotune provided the first automated tuning algorithm that produced great results. However, it demanded a reasonably well setup aircraft to begin with. I designed it to fail if the aircraft didn’t respond as expected. However, Autotune has been adjusted over the years to make it continue rather than fail. The thought was that a bad autotune was better than a bad manual tune.
I am making changes to return Autotune to the original behaviour where it would stop tuning rather than “do it’s best” when an aircraft shows problems. I have also found a few little areas where we can improve the autotune result. We have started testing but I am not sure what version it will be released in. I may start a blog looking for testers soon.
There have also been some discussion about the importance of the setup instructions. While it is possible to skip steps and get an aircraft flying reasonably well, following the instructions for manual tuning, control testing, filter setup, autotune, control testing again, all adds a lot of safety. These steps help catch problems before they become serious incidents like this one.
While I may not describe each step as “mandatory” I would say that it would be irresponsible for developers to advocate ignoring those steps as they are there to keep aircraft and people safe.
@Hover1 In particular the section of the Wiki you should use to check your tune is here:
https://ardupilot.org/copter/docs/evaluating-the-aircraft-tune.html#evaluating-the-aircraft-tune
These steps are designed to excite oscillation in a more controlled way, letting you sneak up on it.
