Ascending in Loiter '0' throttle in?

Log Analysis -- deprecated Copter Logs -- deprecated
1

I had a bit of a scare testing Loiter on a flat hex powered by KDE 3520-400kv and KDE 55A ESC’s.

After working through the fixed 1100-1900us PWM range, finally changing the PWM output from the throttle channel on the Taranis, I went out for a test flight. The props do not turn when armed, I’m guessing I still need to adjust that. I also have not adjusted the throttle midpoint, as I know that has an impact on hover for any mode using the alt hold subsystem.

The issue is that I saw it climb while in Loiter, so I decreased throttle. It continued to climb so I moved throttle even lower, and even down to 0, yet it climbed even further and faster. I finally switched to Stabilize and obviously in the heat of the moment didn’t think through how much throttle I would need. So it fell out of the sky and I caught it at the last minute to soften the crash with some lateral velocity I could not compensate for quickly enough.

My question is, why did it not descend and in fact climb even with 0 throttle?

Conditions were clear skies with maybe 10mph wind, so definitely not a calm day. I believe that explains the z axis from the IMU’s.

The two “failures” of note in auto-analysis are IMU Mismatch and PM. The Pixhawk is isolated with two strips of Kyosho Zeal, so I will try 4 squares instead. I also may have some servo cable tension. However, I had one other short test flight with a pretty solid Loiter while I was tweaking the PWM range. I have heard the “PM = FAIL” tends to be a red herring with Copter 3.2.

[attachment=3]Screen Shot 2015-07-18 at 4.06.37 PM.png[/attachment]

Here you can see just before the rapid climb that my throttle stick input is at 0. Altitude rapidly increases and throttle output becomes erratic. I recall the wind acted up right then as well, but it seems like the baro was working fine (to my untrained eye).
[attachment=2]Screen Shot 2015-07-19 at 7.25.01 AM.png[/attachment]

Here the IMU’s appear to be fairly in sync with one another, with a lot of z-axis activity during the radical climb and obviously during the crash at the end. Is this indicative of vibration during wind, or something I can fix?
[attachment=1]Screen Shot 2015-07-19 at 7.26.23 AM.png[/attachment]

Here you can especially see my throttle input cut to 0, with a selected motor output becoming quite erratic (they all look essentially like this, so I just picked one as an example):
[attachment=0]Screen Shot 2015-07-19 at 7.28.33 AM.png[/attachment]

What would you recommend I try before attempting another Loiter test flight? The full log is attached for review.

2

any thoughts on the log? This is a great forum and you guys are doing yeoman’s work as service to the community, so it’s understandable that threads like these so often get buried. If you don’t have time to analyze the log is there any chance you could recommend a more suitable forum? I might try rcgroups.

3

I suspect you’re not getting answers mostly because you don’t have an obvious, straightforward problem. And you’ve already done a fairly detailed analysis yourself. Whatever’s going on is a bit deep for me, but I’ll take a shot.

As you’ve already stated, and I’m showing on my attached plot, while in Loiter mode you dropped your Throttle in to 0 and your craft continued to climb. All three altitude indicators show an increase. But notice that while they are mostly in sync during the early part of your flight, they diverge during the unrequested climb. This is usually the result of vibration.

I also took a look at the vibration data from both IMUs. The X and Y axes were pretty clean but your Z axis really went up during the climb, sometimes actually going positive (the Z values should bounce around -10, on average). In fact, if you look at what might be an “average” Z value reading during your climb, and compare it to the readings while it was falling immediately after you switched to Stabilize, they look rather similar. So I’d guess whatever vibration was occurring, and it only appeared on the Z axis, spoofed the Pixhawk into thinking it was falling.

Now that’s NOT supposed to happen. All this new EKF goodness is supposed to prevent exactly that. I am pretty unclear on the inner workings of the EKF but it amazes me that it appears to weigh the accelerometer data so much more than the Baro data, which was showing a huge and ongoing diversion.

Since you have your Pixhawk already mounted on Zeal and are aware of vibration isolation steps I suspect you’re OK there. Also, if there was a “normal” vibration issue with the Pixhawk it should show up on all axes, not just the Z. The only thing I could think of might be some sort of weird resonance in the plate the Pixhawk is mounted on, causing it to vibrate only vertically.

I doubt you’ll get any useful feedback on a problem this unusual from RCgroups. Your best bet is either here or on DIYDrones.

4

thanks so much for your thoughts. Yeah, I mean, it’s definitely a “problem” from my perception that it flew way high in the air with 0 throttle, but yeah, the crazy vibes on z certainly would have thrown things off. It really freaked me out picturing all that hard work floating away into the ether with no throttle input.

I guess I will try switching from Zeal pads to smaller squares at the corners, check cable tension, and try again. Knowing that you don’t see the “typical” vibration problem is encouraging.

just to cover my bases, it appears baro is totally fine since it “saw” the ascent, right?

5

Yeah, your baro seems fine since it showed the ascent. But if you plot RelAlt and BarAlt you see something bizarre. The BarAlt is just the baro but the RelAlt also merges in the accelerometer data (I think). Normally they track each other perfectly. Vibration problems are indicated when the RelAlt goes down and the BarAlt goes up. In those cases the flight controller is “tricked” into thinking it’s going down, so requests climb power. That’s pretty obvious.

But in your case while the RelAlt and BaroAlt diverge a bit during the climb and vibration, the damn RelAlt is in fact going up. So the Pixhawk KNEW it was climbing despite seeing a zero throttle input. This is the sort of “man bites dog” thing one of the Devs should look at. It’s very…weird.

6

weird indeed. I thought this might have to do with THR_MID being offset, and I know I’m a somewhat special case due to using pre calibrated opto ESC’s with a static 1100-1900us PWM range.

Because throttle works in Stabilize I don’t think the range would be an issue.

And even if THR_MID was way off, it seems like going right down to throttle 0 (1100us) it would at least know to descend.

Understanding relative altitude helps a ton too, thanks.

One thing I definitely noticed just as all of this began - the flight was 100% normal in Loiter until a big gust of wind. Can that possibly explain the z-axis accel craziness, or the ascent? I can’t make sense of it.

7

If your THR_MID is way off if would only affect your hover at mid stick. At zero throttle it should be descending. You are completely correct in your understanding there.

A gust of wind could have set off a resonance, but it’s odd the vibration only really shows up in the Z axis.

I noticed you list rather large motors at low KV. Are you turning big props? You can get into all sorts of unexpected low frequency vibrations with large props, difficult to isolate from. They can be something of a black art.

8

props aren’t extraordinarily large; 16" APC. I know there are others running very similar rigs. What do you think?

[attachment=0]IMG_1943 copy.jpg[/attachment]

9

Possibly, but probably not. Those 16" APC props are pretty heavy and I had serious vibration problems when I used them on a somewhat flexy tricopter. I ended up going to 17" CF props and it made a huge difference.

For more detail, here’s a writeup I did where I talk about those 16" props. But like I said, given your stiff, tubular arms I wouldn’t expect any vibration problems from the props. Although your tips look pretty close, and odd stuff can sometimes happen from that.

otherhand.org/home-page/dron … tricopter/