Sudden flip while in PosHold

I’m working on tuning my 5" quadcopter and am following the steps.

I was on the step " Test AltHold" - I realize now I had PosHold set but I don’t think that should matter(?)
It was holding beautifully at about 6 feet and I was just slowly moving it in each direction a bit so I could double check my vibration levels.Things were going great for about 3 minutes when it suddenly flipped, drove itself into the ground, then righted itself and started rapidly rising. I quickly disarmed and it only fell about 15 feet and didn’t damage anything but I’m really alarmed that it happened.

Here’s a BIN file of the flight

Any help would be greatly appreciated!

Hello! About what I see in the log, I think you had a desync problem, a battery problem or another type of hardware problem because the RPM of your motors came down suddenly and the voltage of your battery dropped from 10.9v to 9.3v. and your vibrations levels rised up.

A brief short circuit could explain the battery and the RPM drop. I hope this helps you a bit :wink:

Some instants before flipping:



·CTUN.ThO high values, reaching 1 (full power).
·VIBE.Clip0 grows.

No idea about the ultimate cause for all this.

Thanks for the input.
I’m using ESC telemetry for the battery monitor, is it possible a desync would erroneously show a drop in voltage?

Do you use Kakute F7 and the DShot Protocol?
Read this topic, it looks like your case:

I really hope that this error will not be forgotten when the next beta is released…

WOW.
That is the same setup I’m using and I am also using DShot150.
I’ll disable logging and see what happens.

I actually have a video of the crash. I could have sworn it actually hit the ground and then shot up but it may not have, it might have just recovered and shot up.

That’s the first time I’ve seen someone tuning a copter on a narrow sidewalk. I’d be more than afraid of hitting those cars… or someone.

On topic, I’m really glad now that my Kakute F7 build got delayed and I read about this bug a few days ago before trying to maiden it. :parachute:

All I was doing was gently going straight up and back to check the vibrations. I’ve got a 1 block square park nearby that I use when I’m attempting any actual tuning.

It is not necessary to turn off logging, don’t kill the copter!
There is an error in the code, it has already been found. It remains to wait for this fix to be included in the next release.

But it seems to be the consensus in other threads that turning logging off is a work-a-round.

Or you can use 4.1.0 (“latest”) which already has the fix included, if I’m not mistaken.

Where are you finding info on 4.1?

I found the firmware but the release notes just say
SITL: fix RPLidarA2 instructions and diagnostic output

Whatever you’re currently chasing - that patch won’t be relevant :slight_smile:

What is that supposed to mean?

The release notes for master/latest/dev version only list daily changes. The Kakute F7 fix was added some time ago I think.

I don’t doubt you but where could I have found this info on my own?

AFAIK, only in other threads mentioning this bug. I haven’t found some kind of cumulative changelog for the master version either, but that’s no surprise considering these releases are not really meant for public use.

If you’re using the Tekko32 as mentioned in the motor glitch thread, this may be more than an Ardupilot issue. Your Tekko32 may have defective hardware causing desyncs, and there’s a recall out for them.

I’m using the Tekko32 F3 4in1 45A ESC

It doesn’t say revision in BLHeli Suite so it sounds like I have “A”?

@wsmeyer that’s the one. I would contact whoever you bought it from about getting it exchanged for the new, fixed version. If you’re impatient you could grab another ESC and do another test flight to see if that was the issue right there.