Ardupilot 4.3.7 autotune in plane mode causes Heewing T1 to crash uncontrollable
Logfile:
Is this a bug, this is not normal behaviour please help?
As you can see in the movements of your sticks you have not followed at all the guidelines to follow for an AUTOTUNE; fast and alternative movements up to the limits of the sticks travel, do not mix roll and pitch…
Once the Roll setting was finished (Roll finish message) as you kept making roll movements this setting was modified.
You left the autotune without finishing the pitch setting (the pitch finish message never appeared).
I recommend that you re-read the autotune procedure and then perform it following the guidelines.
After the roll tune finished I had to keep the plane in the air, because the roll movements were way to aggressive, the plane kept rolling to the left or right, even upside down. I know how to autotune a plane, but this one was not flying well after the roll tune. I couldn’t barely keep it in the air until it decided to be totally uncontrollable and went into a death roll to the ground, while it was doing this I tried to change mode to abort the autotune. I don’t think this has anything to do with reading the documentation because I did already many times. Normally when doing an autotune the roll and pitch movements are only very conservative, then you can give full stick movements and the tuning process proceeds.
It’s not normal and should not happen at all that the plane crashes while doing this, it’s crazy that this is even possible even when I do not move the sticks as indicated in the documentation!
A normal behavior is that the auto tune process keeps the conservative PIDS until the pilot makes the correct movements.
The PIDP.I indicates that you flew with the COG too far back; the tail was too heavy and the aircraft at all times was trying to lower the nose.
As you say after finishing the Roll settings the plane became very uncontrollable but in that case the best thing to do would have been to switch to MANUAL but you opted first to switch to QLOITER and then to CRUISE.
I wish I could provide you with more (and better) information. As I said in the previous post PIDP.I implies delayed COG but the elevator position indicates the opposite; with the elevator stick neutral the elevator tends to raise the nose (left highlighted area).
Also there is coherence in the premix (AETR) and in the output (RCOU); this is easier to see in the FBWA stage.
The strangest thing is that in the moments before the “decontrol in the pitch tuning stage” the behavior of the premix and the output changes radically (highlighted area on the right). In both zones you have, continuously, the elevator lever approximately in the center and yet this is not reflected neither in the output nor in the pre-mix.
I see that you bypassed the pre-arming checks (ARMING_CHECK,0). Maybe those checks would have prevented you from the bad end.
With the logs I now show you I think you had a magnetic interference problem that affected GPS and that made the EKF3 fail.
At the end of the AUTOTUNE phase the magnetic interference is triggered (probably by increased current intensity). You have always had a high Z component, but now X and Y components are also shooting up.
Although your aircraft configuration carried the X and Y components of the magnetic field well, the Z was always too high.
Here is the moment in which the GPS failures occur that end up generating the EKF3 failure. You can see that it coincides with the peaks of the magnetic field in the first graph.
Finally, here is the discrepancy in the magnetic fields; especially in the Z component
While throughout the flight the main discrepancy was in the Z component, at this point the discrepancy is in all 3 axes and the EKF3 could not handle it.
Alright, thanks a lot for explaining this, altough I do not understand this completely right now.
I will reconstruct the graphs myself and see what I can learn from this and study on your answer, thanks again for all the effort you put in so far, I really appreciate it.
The GPS glitch only happens right before the moment it all went wrong and lasts only a millisecond or so. Me switching to different flight modes was a panic reaction, I was trying to find the manual mode, but I finally found that button when it was already in pieces. I have had a lot of GPS glitches in the past with other planes, drones etc. but this never resulted in a crash.
The magnetometer fail is the correct analysis, according to the LogAnalyzer:
Test: Compass = FAIL - Large change in mag_field (46.07%)
Max mag field length (825.66) > recommended (550.00)
I see this in the messages log:
2023-08-16 12:39:22.969 EKF variance
2023-08-16 12:39:23.279 EKF3 IMU0 emergency yaw reset
2023-08-16 12:39:23.288 Short Failsafe Cleared
Which indicates to me that the EKF error was resolved at that point.
But even after studying for hours on all types of graphs, data and manuals, I find it extremely difficult to interpret these graphs, because I don’t know what the “normal” values are for most of the graphs, or what they even mean in comparison to each other.
I’m going to rebuild this plane and just try it again, thanks again for your time and help!
First of all, I did not talk about GPS glitches or update rates (GPA.Delta).
What is defining is the EKF3 glitch you see in this graph. The values are only supposed to exceed 0.5 occasionally and never reach 1.
- SV >>>>> GPS velocity estimation
- SP >>>>>Estimated GPS position
- SH >>>>>BAROMETER altitude estimation
- SM >>>>>Magnetic field estimation COMPASS [During AUTOTUNE, and not after, it will 1.47 / In addition, it was not only occasionally exceeding the value of 0.5]
- SVT >>>> Air velocity estimation PITOT
As I see that you show interest in understanding these parameters in the following website you have the necessary information. Specifically at the end where illustrative graphs appear.
Extended Kalman Filter Navigation Overview and Tuning — Dev documentation (ardupilot.org)
Good luck with your progress in Ardupilot.