This is starting to drive me crazy :) ....................autotune crash


25 KG All Up Weight
4 x P80III Tmotors
4 x Flame 80HV esc
Black cube
4 x 28 inch props

We managed to have decent pids manually. The Quad flies good in stab and loiter, no sign of strange things going on. So we decide to try an autotune.

Entered autotune made a twitch to the left, than on recovering the horizontal position the left rear arm staied down like it twitched on pitch too, eventually recovered, seconf twitch to the right and it started to act crazy and eventually crashed.

Only thing i notice from logs is that gyro rotation do not agree with motor pwm, for a twitch to the right you would expect motor 1 and 4 to go up in pwm…it logs the opposite. We are sure the twitch was to the right and the log of the gyro confirms it.

Any help would be GREATLY appreciated.


that’s a lot of accel clipping for just 2 minutes of flying

imo first step should be getting those vibes way down

Little vibes are caused from props a little chipped from previous crash. Didn’t have any vibs before and did same thing and same crash. So i would rule them out. There is a log of my light crash on the forum and no vibes there ( new blades ). Thank you for your suggestion.

link to previous log?

Anyway even on chipped prop there is no clipping, they raise only at the end because of crash. During flight, no clipping at all.

oh you’re right my fault

If you’ve had an older generation ESC, with an 8-bit 16MHz uC, the desync would’ve been pretty clear to the naked eye. But these new 100 MHz 32-bit chips muddle things up., making it less obvious. To avoid stall, they skip powering the motor for a couple of steps, while measuring bEMF trying to re-sync. And they do, pretty fast, but that off-power sequence is not what the autopilot expects.

That’s very interesting - good to see desync handling is improved with the newer generations of escs. But it should still be clear in ardupilot logs - no matter how the esc handles it, any desync will cause that corner to drop, and the AP will try to compensate by pushing that motor to 100% for a sustained period.

We strapped it down and run it. Put the rc ports in pass trough and moved stick really fast and by my understanding i see no sign of desync, actually motors spin up quite fast for the size.
I am pretty much at a loss, next will try a new black cube i have around and see.

I do not see any full roll/pitch commands until FC commands it during autotune. I bet you would produce the same malfunction outside of autotune by moving the sticks to max.

high 3 and 2 gives right roll

that’s exactly what his log shows

since you can’t produce a desync, it looks to me like you have a bad esc, and #4 looks guilty… the wild behavior begins only on left twitch and the copter pitches to the rear at this moment, so the FC then commands #2 to assist with the pitch, but all it does is stop the rear pitching until #4 finally kicks in and it pitches forward… #4 and #3 then seesaw for the remainder of the flight until crash… in fact, it looks almost identical to my esc failure here… the evil thing about bad escs is they typically don’t show symptoms until they reach a certain temperature, so be sure to run it hard for a few minutes on the bench

@fnoop This is exactly what the logs show, 100% throttle sustained over a long period of time - abnormally long, all things considered.

@Iketh It’s not e deffective ESC. It’s just they can’t cope up with the acceleration required with such a large prop and load. It tries, it desyncs, it re-syncs and it doesn’t output the requested thrust increase during this process. The desync protection is documented in the ESC literature, alongside FOC description and other marketing buzz. ESC stops powering the motor for a couple of steps, period.

well he just said he flipped the sticks rapidly and couldn’t produce a malfunction… the FC produced the malfunction on the second twitch! however, there’s a small pitch forward on the first twitch so you might be right… it’s almost like he has too much weight diagonally on the craft on motors 3 and 4

I gotta tell ya, I’ve only ever been able to produce desyncs on motors with no props, but i have no experience with +20" props

Weight is completely balanced, checked rate log in hovering and it produces almost zero, it means it doesn’t work to cope with an imbalance.

I may suspect esc 4 doesn’t work properly, but on first twitch (to the left) number 3 does the same, it stays high.

Maybe just PIDs to high and big props and mot can’t cope with them?

A bit at a loss here :slight_smile:

honestly the most frustrating thing about this post is you’re flying with manual pids and no mention if relaxed pids were tried (such as defaults) to get an autotune going

how would rates show 3 and 4 are heavier than 1 and 2 in a hover? in fact rcout wouldnt even show this kind of imbalance

ah yes, this graph shows absolutely classic desyncs, although odd it flips between two motors - perhaps these ESCs recover faster between twitches. My older ESCs didn’t really recover until it hit the ground…

This is normal. Autotune is very good at reproducing desyncs because it commands extremely sudden movements which translate into sudden and complete throttle up on a particular ESC. It’s these sudden throttle demands that cause the desyncs, and it’s not something that is easily (if at all) reproducible by a human movement with a control stick. If you look back through these forums you’ll find hundreds of similar cases, a lot of them during autotune - I’d wager desyncs are the most common cause of crashes particularly while doing initial setup of a craft. I’ve hit them several times with 14 and 15" props as have others.

You’re using extremely low KV motors and very large props which are hard to keep in sync with rapid throttle movements. It may be that you need better ESCs with better timing and desync protection. Hobbywing are normally very good but may be that you need a different range or bigger versions - if you ask them directly they can advise. These ones may be too small for the motors/props you’re trying to run.

Flame 80 by t-motor is what they advice to use, we asked them and they said flame 80 hv on 12s are ok on P80, but still you may be right. Maybe i should get the new ones from tmotor. The alpha. Alpha are foc too.

ahh ok, so I’m assuming autotune goes from, for example, 0 pwm to 2000 in one frame which is impossible to replicate manually no matter how fast you move the sticks, makes sense

You can’t desync a modern 32-bit ESC like you did on the old 8-bit SimonK. You won’t see the prop stutter with the naked eye anymore, and that screeching grounding to a halt.
All the modern ESCs, HW, T-M, BlHeli_32, Kiss and whatnot employ a trick. When the zero-crossing (that’s a pole step) doesn’t occur at the predicted moment they stop powering the motor, count and time the next few zero-crossings, then reappliy power with the measured timing. Now, depending on motor number of poles, this zero-crossing happens in a couple of degrees of rotation so the whole process described above takes probably half a motor revolution, or less. Human senses can’t detect a desync today.

But then you can experience an avalanche of desyncs. You can imagine a motor doing each half of a complete spin in-sync / de-sync when it cannot cope with the requested change in rpm. It will provide just half the thrust demanded. Also invisible to the naked eye, but extremely obvious to an accelerometer in the FC.

Now, I’ve recently built a 12S machine, with Alpha 60A HV ESCs and MN701 motors, but it’s sitting at a paltry 9 Kilos AUW, spinning 24 inch props. Sorry @Corrado_Steri, I didn’t download any logs off it, as it behaved OK, but I’ll have it back in a month or so when its owner comes for flight training.

There’s a fine balance between motor capabilities, prop size, prop pitch and load. Prop pitch, for instance, is an overlooked factor. Same diameter, lower pitch, will take your motor in a whole different rpm envelope with a different effort curve to provide the changes requested by the FC.

1 Like