AP 3.5.3: Autotune flipped me and RTL did not like to be upsidedown

[marcmerlin]

Airframe: normal plane (2.6m glider) I did 2 flights before this one after rebuilding it from its crash, and the plane flew fine in FBWA, CRUISE, and RTL. But since I had changed some wing servos, I figured I should autotune it again.

Here are my params: 48.txt I do have AUTOTUNE_LEVEL 7.000000 but I had it the entire time since this airplane had been built.

The OSD video shows what's going on: https://youtu.be/Q9p985vMqZ4?t=1m15s

I switched to autotune, did some left right, and it didn't feel that great, you can see at 1:30, that the left commands don't seem to turn left much anymore, but right works better. Then by 1:40 it seems to go left ok again. So I tried some up downs, I know I got close to stall speed, but the airframe stalls around 30kph when the motor is on. At 2:00 a wing drops right, maybe it tip stalled, but it's just a maybe. By 2:00, airspeed is back to 61kph so the airframe shouldn't be stalled anymore (also only 2 degrees up), by the time it goes left, it goes past 90 degrees, which I don't think should have happened in autotune. At 2:04, sadly I paniced, and hit a switch to switch to RTL instead of an override switch to back to MANU (I tried to get out of autotune since it did not give me proper control of the aircraft, but my mode switch is a round 6 position switch that is hard to access and turn quickly when my fingers are on the sticks). By then, it looks like I hit the same bug as https://github.com/ArduPilot/ardupilot/issues/3875 and RTL flies the plane into the ground again and destroys it :(

[marcmerlin]

Yes, I know that due to some toggle switches, flight mode did go into manu briefly, but RTL was in control most of the time, and had almost 100m of altitude to recover and failed again. Of course, the main point of this bug is why things went so wrong in autotune to start with. @tridge what do you think? Here's the flash datalog I forgot to attach: http://marc.merlins.org/tmp/48_autotune_flip_rtl_crash.BIN

[marcmerlin]

here are the values that were changed (ignore the non autotune ones). If I manage to glue this plane back together (unclear looking at the pile of foam), I'll restore the tuning values to the old ones, and probably never use autotune again unless I have more clarity on what happened and why it won't happen again, but the value changes may be useful in figuring out why autotune was doing so badly when I turned it on.

[marcmerlin]

Well after 3 days of work, and a lot of glue, I was able to rebuild the plane. After some test flights, I got a lot of altitude, a finger on manual/failsafe mode switch, and tried autotune again. This time it just worked. Attached is the result.

Unless the pixhawk board got detached from where it was glued with the anti vibration feet, I'm not too sure what could have happened the first time (i.e. why autotune got so out of whack and allowed the plane to go inverted). Looking at the original video, power was 35% during autotune, Now I see that the airspeed did decay to 32-36kph for brief moments, but they could have been small measuring issues too due to the sudden attitude changes (I have ARSPD_FBW_MIN,12 which is 43kph) Looking a back at the video, I see at 2:01 offset that motor power is increased as requested by RC control (as shown in mavexplorer data), further making it unlikely that when the plane pitches left, it's because of a 2nd wingtip stall (I'm willing to believe that the first big roll to the right could be a wingtip stall). Also looking at in Mavexplorer, I see airspeed staying above 14m/s after the first bit roll right, which was very possibly due to a tip stall, but the 2nd one when the plane rolls left and goes inverted, was unlikely due to low airspeed being over 14m/s the entire time. Of course, mavexplorer also shows that I'm giving full left/right aileron inputs, but that's expected. re-reading http://ardupilot.org/plane/docs/automatic-tuning-with-autotune.html it also says "Autotune won’t do anything until you are above the minimum airspeed you have set in the ARSPD_FBW_MIN parameter", which I have set at ARSPD_FBW_MIN,12 as well as saying that it behaves like FBWA, so since I have LIM_ROLL_CD,4500 it should not have rolled past 45 degrees the 2nd time to the left (when I'm pretty sure that the wing did not stall).

Here's a lot from a successful autotune today: http://marc.merlins.org/tmp/4_Autotune_Worked.BIN

[marcmerlin]

@tridge, I forgot to post this earlier when I did a quick analysis, sorry. This graph is pretty telling of what happened, but because I don't know the autotune code, I can't tell how it should have behaved, and how it flew so badly.

First it shows roll and desired roll getting more out of whack at the end as expected, but after the first big roll to the right (60 degrees) it and I try to correct to the left and it targets 45 degrees to the left At 12.13.17 or so, the roll is achieved, but AP was way too slow in removing aileron command and allows the wing to get way past 45 degrees left.

So basically autotune seems to fail at getting more in control of the airplane and stays behind it. Sadly by the time it allows the plane to reach 90 degrees left, I see RCOUT.ch2 going to full elevator down, causing the reverse spin and stalling of wings and the ailerons again. So basically it already starts doing the wrong thing with the elevator before I have the chance to switch to RTL which in turn just does more of the same and crashes. Ultimately, though it looks like autotune failed to tune, flew the plane worse than a student pilot, with way too much delay in changing the aileron servos, and allows the plane to go past its 45 degree roll limit.

[marcmerlin]

@OXINARF So, the RTL flew into the ground thing should be fixed already. Autotune behaving so badly, causing the airplane to flip over, that I don't know if it's fixed, and I'm not sure how I feel about testing this again :) (but if really necessary, I could, especially given https://github.com/ArduPilot/ardupilot/issues/3032 which could be partially due to a bad tune)

[IamPete1]

I'm not sure this crash report will be useful to fix issues in the current code, but if there is still some issue we can fix feel free to re-open.