I'm running 2.6 Delta on a pretty standard tricopter. In stabilize mode I get a mostly rock solid hover. However, every 20 to 30 seconds, even when I'm just hovering 6ft AGL, there's a pretty large hiccup or twitch where the rear motor slows significantly. Sometimes it just causes the craft to dip backwards and recovers, but sometimes it is so severe that it falls out of the air.

I had the issue with 2.5.4 and 2.5.5 as well. I've replaced the ESC and switched the motor with one of the other arms, and re-checked all wiring, and it still happens on the rear motor. This has happened with two different APM2 boards even, so I'm pretty sure it's not hardware at this point.

I started trying to adjust the PID values and thought at first it was helping. First thing I did was set rate_D on pitch to 0 since I've read D has contributed to twitchiness in the past. I also started backing down rate_P, from 0.180 all the way to 0.9. I also switched to acro mode to narrow the problem down further, and it was still happening.

It may be my imagination, but it seemed that the last test, with lowered rate_P for both pitch and roll, the problem was getting worse the longer I'd hover, and the problem seemed to start happening in roll but not quite as bad as the pitch.


Any thoughts on what to look at next? I was watching the tuning graph and the RC input looks fine, so it's not a radio issue. Also the sensors all look fine, so it doesn't look like an attempt to compensate for a whacky sensor or vibration issue. The motor output for ch4 looks like it does drop out, but is that the cause or a reaction/symptom? I don't see any correllating change in input or sensor.

The fact  that it'll hover rock solid for 20 to 30 seconds (and sometimes even for a minute or more) confuses me, which is why I originally looked for intermittant hardware or wiring failures. I've even done some pretty aggressive flying and often it flies just fine (though I've seen it happen during aggressive flying too).

My limited understanding of the PID math made me think that this was some error build up that reaches a threshold and over-corrects, but I'm not sure where in the numbers this would happen, and I think I've eliminated most of that possibility (i've had rate_P low and rate_I and rate_D zero).


This is pretty frustrating, since I've already had to send my board back twice for the diode issue and a subsequent uart failure, and now that I've finally got a functional board, 2.6 Delta is otherwise amazing. I'm all decked out with FPV gear, but I can't risk flying more than a couple feet off the ground because it WILL eventually tank.


Any suggestions? I'll try to catch a tlog tomorrow, in case that can help.

Views: 1070

Reply to This

Replies to This Discussion

Yeah this is sort of what's happening with mine too. Mine will generally make a couple of twitches in a row once it starts, and it always pitches forwards. I've just gone back to 2.5.4 and it seems not to be so bad, but that's just with one flight to compare. Not that that helps you much...

What does your log show for pitch in vs pitch when it happens? With my one, each spike looks to be preceeded slightly by pitch in making a small but sharp negative spike, I have my pitch reversed in radio setup, so I guess this is why it pitches the copter forward. If I sit in mission planner watching my radio pitch input, with the copter off it stays pretty steady around 1500. There aren't any wires running near the radio ones, so I doubt it's getting interference from there either? 

Here's my log showing a couple of downward spikes, followed by me pitching back to bring it back after the 3rd one. Is yours similar?

Yes, my pitch in does almost exactly the same thing, a spike on the input even though I'm usually either not touching the stick, or holding it very steady slightly off center to keep in a hover (file attached). I'm just about to try a fresh config on the radio and to remove all extraneous electronics (3dr 915MHz radio & FPV video TX) to reduce the possibility of electrical interference, though there's nothing special about the placement of those that would make it exclusively affect the pitch like this.




I just used a freshly setup model in my radio and removed all other electronics, so it's just the APM2, a 5v BEC powering the RX and APM2, and the ESCs/motors/battery. The problem is still very evident.

I noticed that the problem may actually happen when I'm very close to (but not at) center on the stick for pitch. In fact it looked just now like it was happening most often when I'd be just slightly pulling the stick down (almost imperceptible movement, like 1 or 2 degrees deflection) to keep hover, then release it back to center. Almost exactly at that moment the tail violently drops as if I cranked the stick all the way down for a second.

I'm going to try to switch the order of the channels in the radio and connections between RX and APM2 to eliminate a bad channel. Other than that, I'm not sure what to do next.


Oh I also tried to get it to hover without any stick inputs for as long as I could multiple times, and I never saw the twitch when I wasn't touching the transmitter. It was only one battery of flight so that may not mean anything. I may go back to 2.4 just to compare the experience. I could also throw the multiwii board back in, as if it's really a pure radio issue, I should see similar behavior there.

I've now eliminated the independent BEC (running off the ESC's BEC through the output rail) and I swapped channels on the RX/TX, and the problem is still happening with pitch.

Given that I've gutted this down to the bare minimum functional requirements and almost assuredly eliminated the radio, I can't think this is anything but a software/PID issue. I've already tried extremes on both ends in the rate/stab PIDs (I had the twitch in acro mode so stab values shouldn't be the problem, though they may exaggerate the symptoms) and still noticed the behavior.

This last test I saw more supportive evidence that the problem happens exclusively when there's a tiny bit of input from the pitch stick. I hovered for a collective 5 minutes without pitch input and never saw it once, but if I'm adjusting to hover in a small area I see it two or three times a minute to varying degrees of severity. As soon as I pull the stick down the slightest bit, the jerk happens.

I'm wondering if in the code there's an issue with very very small input values blowing out a variable precision, possibly wrapping around or something.

My next (and last, unless I can think of something else to try) test is to try to set a dead zone on the transmitter so it never sends incredibly small deviations from center, and see if that makes any difference.


Any other ideas would be greatly appreciated!

Here's a video example, with two of the twitches (@ 0:02 and 0:15):



I'm attaching the tlog for this flight. I did not download the on-board logs (and hadn't enabled PID logging), so hopefully these are a somewhat useful. This example was on 2.6 Delta. I'll try to capture a good example with 2.6 release as well.

Looks exactly what mine was doing with 2.6 delta, except my tail was pitching up because my pitch channel is reversed. It's gone for me in the 2.6 final release.

Yeah I was really excited when I read it went away for you in 2.6 release. I ran out and flew 2.6 release (near pitch-black at night, couldn't wait) and for 8 minutes I was really optimistic as it seemed perfect. Then I had two minor twitches and one bad one just as my batt was running low.

I've flown several more long flights today and the problem is definitely a lot less drastic, but I've still seen it occasionally (very minor) but also seen one or two big enough to keep my confidence level low. Of course, the fact that it happens a lot less now means it'll be a lot harder to diagnose and test. :(

I'm going to log some more with 2.6 and try some tuning too.

Hi Guys,

i had a similar problem like Luke, but only on the Yaw channel. It made my tricopter yawing occasionally for up to almost 45 degrees. This happened more often at the beginning of the flight. The yaw-in of my log showed exactly the same spike like Luke's in his link.


So i thought this must be receiver issue. Then I switched my Futaba 6008HS from analog to digital output.... and the problem was gone... at least on the YAW axis ... now i have occasionally small twitches on the throttle channel :). But thats not a real problem, because you only hear slight change in RPM.

I hadn't had the time, yet. But i'm going to test it with another Futaba receiver and see if it is totally gone then.

My setup:

APM 1.4

Futaba T10CG 2.4 TX and Futaba 6008HS RX

Rcexplorer.se style Tricopter with Turnigy Plush 25A, DT750 and APC 10/4.7, 45 cm arms

APM, receiver and sero are powered individually from one ESC each.

Best Regards,


Hi Patrick,

Interesting that you too are using Futaba radios, I am as well. Since the issue appears at first glance to be an input interpretation issue (though I'll be the first one to say my evaluation on this is fairly uneducated and quite possibly a red herring) I wondered if it was a peculiarity of the tx/rx. I don't have any alternatives to try right now, so I'm still trying to sort it out in software.

That said, I removed the STAB_I for pitch/roll and reduced RATE_D and my problem is now minor enough that I'm fairly comfortable with it, and have flown about 120 minutes with only a handful of small twitches. I'm going to continue to tweak the values a bit more, but if I get another 100 or so minutes of uneventful test flights on it, my confidence will be somewhat restored and I'll start recreational FPV flight again.

I guess if the problem is still there and just more rare, I'll eventually see it again, and hopefully not be in a situation where a crash is the result. To be honest, 2.6 is so damn stable that as long as I don't panic (or am flying low and/or between trees or something) I can probably recover anyway.

Hi Guys,

sorry this took some time. But with a Futaba 617FS all glitches are gone!

Which receivers are you using?


Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service