I recently updated to 2.6d and had a short flight which ended with a snap roll-over crash while about 5 metres up, and I would love to find the cause so that I can avoid it from happening again. I'm not sure if it was related to my pids, or something in the code? I had flown extensively with 2.5.4, albeit with different pids and never had a problem like this.
Hardware: APM1 2560
Unfortunately I don't have a log since my logs stopped working with 2.6d, but I do have the onboard video.
What happened, was the copter would start to want to roll slowly to one side or the other, and I would have to provide opposite stick input to keep it level. While I was doing this, my minimosd was showing the virtual horizon was slanted quite a bit when I had the copter held level with stick input, and the first couple of times, it just did it mildly, and eventually re-centered itself. I tried to land because it was getting sketchy, but it was trying to roll to the left, so I put in right stick to oppose it, but it climbed while it levelled, so I backed off on the throttle, and then it rolled over to the left past 90 degrees over the course of about half a second. I provided full opposite stick to try and keep it level, and then it suddenly snapped back and rolled about 270 degrees before plowing into the ground.
My pids were as follows:
Is there any way the RATE_RLL_I built up enough to cause this? From the video, does it look like a built up RATE_RLL_I term would cause an increasing lean over to one side that needed to be countered? If not, which parameter would likely be the culprit?
Here's the video:
cases where the artificial horizon shows an angle while you hold it level with stick input usually seem to be caused by vibration. i had a case of "the leans" although as i remember it only tried to pull to the left, it seems in your case it pulls in different directions?
my problem was solved simply isolating APM better from vibrations in the frame.
Hmm, just seems it was a bit weird that I had 50+ flights on 2.5.4 with the same frame and mounting of the APM and no issues, but then got this on the second flight with 2.6D which makes me think maybe one of the pids being different was amplifying the vibration to the point where it caused a constant lean?
fair enough, does seem suspicious.
as the artificial horizon showed the craft was rolled to the left when level then the problem is almost certainly with the attitude sensors. the PID loops run further down in the process, and rely completely on the correct attitude indication, once in this kind of situation then yes, an i term could build up in response to the constant error to keep level, but it wouldnt be the cause of the problem.
there doesnt seem to be any change in the DCM in 2.6d, which in the code, is where this would have to originate. any hard knocks recently? perhaps a component has a bad connection on the shield somewhere?
Mine hadn't had any hard knocks other than the crash caused by this, and going back to 2.5.4 it seems to be flying fine, so I don't think it's a bad attitude sensor input... well fine is a relative term. My multiwii board feels significantly better to fly the same frame than my APM, so maybe the APM will just get relegated to use as my secondary system until the performance is better.