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
Tricopter frame
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:
RATE_RLL_D,0.004
RATE_RLL_I,0.001
RATE_RLL_IMAX,500
RATE_RLL_P,0.14
STB_RLL_I,0
STB_RLL_IMAX,4000
STB_RLL_P,3.6
STAB_D,0.001
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:
Tags:
Permalink Reply by James on June 12, 2012 at 2:26pm 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.
james
Permalink Reply by Glenn M on June 12, 2012 at 2:38pm 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?
Permalink Reply by James on June 13, 2012 at 2:28pm 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?
james
Permalink Reply by Glenn M on June 13, 2012 at 7:33pm 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.
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.6 members
129 members
185 members
87 members
24 members
© 2013 Created by Chris Anderson.
Powered by
