had a really bad time today after my copter went out of control and crashed really hard…
I flied it before after updating to Copter 4.0.3 and it was ok.
Today I wanted to do an autotune run because I noticed some oscillation in the last flight.
I don’t know if this has something to do but I also had some EKF2 Yaw inconsistent issues while disamed in the flight before.
Well what happened after 2 minutes or so while autotuning:
The copter suddenly started turning to the left like it lost the level somehow.
I immediately switched to stabilize and gave throttle to gain height. But all it did was accelerate even more to the left. So all I could still do was push the throttle down and let it crash because it was moving way too fast.
The only good thing is that nobody got hurt besides the copter and my feelings…
Some information:
Hexacopter 550mm frame
Old flight controller (AUAV-X2)
Copter 4.0.3
Actually looks like desired and actual angles look good, however your battery absolutely tanks at the end with the current spike - 80A and a 4S pack at 11.8volts.
Sorry it crashed, that’s never fun.
Always pitch/roll and Desired pitch/roll don’t separate much and do not show the oscillations of a poorly tuned copter. At least that is good.
I can see that yaw you mention, which may be autotune turning to face the wind. About that time GPS speed begins to pick up (and Lat Long are changing) and GPS Vdop start going bad but I cant see what’s causing it. Motors 1,4 and 6 (back and right) generally get commanded high, not like total thrust loss but like a big weight shift - battery came loose or something like that.
I can see RC inputs probably trying to stabilise or bring the craft back, but it’s not helping.
At one point, after the FS-EKF-INAV event, and around the same time as the GPS-Glitch, your battery voltage takes a nose-dive from about 14.5 to 11.8 and there’s a huge current spike - like something shorted out. This the same time as motors 1,4 and 6 are briefly commanded to about maximum.
That current spike seems a bit high to me, even for maximum motor outputs, considering you’re normally humming along nicely on about 20amps and the spike goes to 85amps. The current then settles on about 40 to 60 amps for the rest of the out-of-control period.
It looks like the battery voltage only sags because of the excessive current draw, and it even recovers as the current reduces.
Once you get this rebuilt, keep all your existing parameters as a starting point, and probably just change these to begin with:
BATT_ARM_VOLT,14.7
BATT_CRT_VOLT,14
BATT_LOW_VOLT,14.4
MOT_BAT_VOLT_MAX,16.8
MOT_BAT_VOLT_MIN,13.2
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
I am going to second the short circuit theory. During the period of your uncontrolled movement I can see motors 3 and 4 fight each other, as show below: (other motors removed to highlight 3,4)
Probably trying to level the craft, overshooting and trying to re-correct
You have a peak of 85amps, yet not all motors are commanded at full throttle
What I find very interesting is the line where there is no variation in VCC, that just doesn’t look right at all, and it happens right before the massive power surge. I am wondering if your power circuit is failing.
I think that straight line in Vcc (circled in green) is the jump in time while landed and disarmed - but for sure not all power bricks and 5volt regulators are created equal.
Thank you very much for your replies!
The battery didn’t come loose. I would have seen it slipping out the rail and the straps are still tight even after the crash.
Yes, that current spike must be because I commanded full throttle after switching to stabilize as I wanted to gain height. I think it is not a short circuit because the copter is powerful enough to draw this much current for a short amount of time. The out of control period began a few seconds before I switched to stabilize, because when I noticed it, I switched the flight mode. I however didn’t switch off the Autotune switch on the remote control if that matters.
Can it somehow be seen in the log that there was a difference in motor commands between the hovering before and after the out of control period? Because that would show that the copter had a gyro drift or something like that (that is what it felt like). It also wasn’t really out of control, as it reacted to my throttle input, but it didn’t level itself anymore (or what the copter thought was level, wasn’t level anymore).
@rmackay9 it would be great, if you could have a quick look. Maybe you have a suggestion what could have causes the “level”-shift and how to diagnose it.
I just uploaded my log to https://plot.dron.ee/ and did another analysis.
You can see at the map that starting from 11:52:11 the copter started drifting.
At 11:52:13 I switched to stabilize, because I had noticed that the copter was going weird.
The log shows the following errors:
TIME
Subsys
ECode
Description
11:52:12
16
2
EKF CHECK: EKF CHECK BAD VARIANCE
11:52:12
17
1
EKFINAV FAILSAFE: OCCURED OR FAILED TO INITILIASE
11:52:13
11
2
GPS: GPS GLITCH
What is the cause for this?
Right before that, the log shows the following message:
The vehicle will gently lean (up to 10 degrees) towards a “target point” which is initially set to the vehicle’s location at the moment AutoTune was invoked.
Maybe it got stuck in this move or it lost the target point?!
Hopefully someone can explain the behavior to me. I don’t want to risk another crash after I built it back up. I need to find the cause for the failure so I can fix it.
It is a long shoot, but I think it was a failed gyro in IMU1. If you see the log IMU1 and IMU2 GyroZ/X values are running together up until the last two twitch. At first there was an unnecessary spike on IMU1.GyrZ (red circle 1) then after the last twitch both GyrZ and GyrY started to diverge on IMU1 and IMU2 (Second red circle) and not matched again. After a couple of seconds EKF changed the AccelZbias from 5 to -20 most likely caused by the faulty Gyro data that feeded into it. This was the point when the flyaway started.
Of course it is just a theory based on looking for anomalies in the log.
Thanks for your analysis!
That sounds really interesting.
How can something like this be caused?
Do I need to replace my flight controller because it has a faulty imu?
Well, it can be caused anything. Faulty chip most likely.
Faulty IMU equals certain crash. In this case it can be intermittent, so you can have a some good flights then suddenly crash.
Under normal circumstances it must be replaced, but It can be still used for desktop testing, development etc.
If you desperate then it is possible to disable IMU1 and use it for flying, but it is not recommended and definitely not with a frame that has value.
