Throttle "freeze" during landing

After a approximate 8 min video flight we do the final decent in LOIT mode to above the landing area to execute normal landing. At a stable hover, we first selects ALTH for some seconds and than to STAB as normal procedure during landing. During seconds ALTH and STAB mode, strange things happend:

-copter yaws to the left a bit (I dont know if this is wind or a motor input.
-you can see on the ground monitor recorder that the camera is rolling smoothly to the left. The gimbal controller have nothing connected to the roll input channel. (see video clip below)
-the throttle seem to be “frozen”; the pilot can not arrest the decent even with full throttle.

This end with a VERY hard landing with a tipover. The motor/propeller are still running after tip over dispate the throttle stick is pulled to minimum by the pilot. After approx 2 sec, the motors stops (thanks for the crash detector function).

Here is some details:

-PixHawk
-ArduCopter v3.1.5
-Octocopter
-There is a directional antenna on a mast approx 100m away that are pointing approx through the final flightpath.
-The ambient temp was about 23*C.
-The copter have throttle and failsafe function activated.
-ESC configured with softcut and cut threshold of 2.85v/s

Can someone have a look on the log and the video clip and maybe understand more than we manage to do? Thanks!

Video clip http://youtu.be/3BHr3jDIzxc

IMU and RCOU logging was turned off. Please set your log bitmask back to the default.

Your hover throttle is too high for your aircraft to have any redundancy from being an octocopter - over a quadcopter, you’re just wasting weight having extra arms and empty space that you could be filling with bigger props. You should lighten it or get more power somehow (possibly tuning MOT_TCRV_MAX could get you a few percent)

It’s possible to descend with power if a toroidal vortex forms around the props during a descent (vortex ring state)

I’d say either a motor failed or you ran into vortex ring state.

Good points.

I dont think vortex is the reason. I know very well how this looks and the uncontrollable descent startet from stable hover.

And your theory do not explain those elements below:

*I could not idle throttle after the crash/tipover (motors continue spinning until crash funksjon shutted them off).
*the 3 axis gimbal controller start yawing camera to the left a bit (according to log, I think this was gimbal only) and (the not connected) roll axis going to left roll (see video in post #1).
*I have tested octo max thrust to 13 kg and the copter mass is 8 kg

One thing is the ESC, could it be that they have to little cooling air around? So that they auto redusing power; first the one, than the next until not enough motors to keep the copter in hover. The ESC is rated to 30 amps and are using 9 amps at hover.

Why this MOT_TCRV_MAXPCT? Isnt max output PWM set when calibrating the ESC?

The log bitmask is set to 830 (default). Should I switch ON IMU as standard? Have red that this reduces processor performance.

This was a lot of questions, but we are two persons that can not understand the octo’s behavior. We assume, but can not nail anything… Thank you for help jschall or anyone!!!

830 isn’t default on PIXHAWK. There really isn’t enough being logged to know what’s going on. CPU is not an issue unless you’re using APM2.

I think you had a power plant failure of some kind. I missed the video last time, sorry. The gimbal screwing up is interesting - maybe caused by vibrations. The amp draw fluctuations also show that there may’ve been a power plant failure.

TCRV exists because there isn’t a linear relationship between PWM input and thrust on most ESCs, so we added a configurable curve and the defaults are whatever is best for 3DR ESCs.

Have now also talked to a independent model flyer and radio amateur. He experienced that using 1.3GH near ESC, resulted in stuck/unstable ESC. After a lot of pros/agains, we have concluded that the most likely cause of the situation above is high radio noise affecting electronics components. But we are of course, open for other opinions…

Well, RFI could cause glitches potentially, but it isn’t likely to cause a “stuck/unstable” esc.

Basically, what is seen in the logs is that the throttle output maxes out and the copter can’t climb. Without RCOU being logged (PIXHAWK logs it by default), it is impossible to dig much further.

Can the data be there somewhere? I loaded the SD card only. Is there more data somewhere else? The logging was set to default during flight…

We could try a telemetry log.

The dataflash log is most assuredly not set to the default value, though. You probably copied settings from an APM2.

Before the flght I set “Default” in mission planner. Then it gives logging parameter value 830 in the parameter list. But for now I have set “Nearly all” in the log setting and can see that IMU is included.

That throttle maxing out can also be because the ESC is stuck. Maybe RFI making false PWM signal (for example 1400uS), and thats this is also the reason for the gimbal rolling to the left.

How warm can the ESC work? Can the ESC have redused pwr due to overheat? Now Im measuring 32C in hover (outside airtemp of 8C) on the heatsink side of the ESC. Is that too warm?

Thank you very much for discussing!

[quote=“mskogmo”]Before the flght I set “Default” in mission planner. Then it gives logging parameter value 830 in the parameter list. But for now I have set “Nearly all” in the log setting and can see that IMU is included.

That throttle maxing out can also be because the ESC is stuck. Maybe RFI making false PWM signal (for example 1400uS), and thats this is also the reason for the gimbal rolling to the left.

How warm can the ESC work? Can the ESC have redused pwr due to overheat? Now Im measuring 32C in hover (outside airtemp of 8C) on the heatsink side of the ESC. Is that too warm?

Thank you very much for discussing![/quote]
That’s definitely not too warm.