Alt_ Hold OCTA crashed, Am I right? I am not sure

Sadly my octa crashed after 5 minutes of flying, everything seemed normal before switched to alt hold mode it suddenly increased the throttle and tipped . I have been flying the octa for many times without any issues.
But the FC increased the throttle after changed to alt-hold mode

Log files (dataflash log):here


I guess that FC increased the throttle after switched to alt-hold , the ‘rc3_trim’ was set to 1094 while the RC3IN was keeping 1492,Am I right?
Is it unnormal about the NKF6.Roll?
Thank you all!

I’m looking at your log. Still not sure exactly what happened, but I can tell you this:

  1. RC3_Trim of 1094 is okay. Low throttle trim is normal.
  2. IMU 2 is malfunctioning. The accelerometers are not getting any readings:

    Are you using Cube Black? If so, you may be affected by Service Bulletin 2.

This is why EKF 2 is confused. However, EKF 2 was not being used at the time of the crash, so I don’t think this is the cause.

  • The flight controller did not command the drone to tip over. It looks like motor 8 failed.
  • Maybe motor 8 failed because of the sudden throttle increase. Maybe unrelated.
  • I don’t know why the throttle increase happened. When you switched to Alt Hold, it set a desired altitude that was higher than your current altitude. Normally, switching to Alt Hold will set (desired altitude = current altitude) and (desired climb rate = current climb rate) to prevent throttle changes.

Rick, there’s the moment where the EKF throws an error. It coincides with GPS NSats going from 5 to 13 (obviously achieving 3D lock) and AHR2.Alt getting a 8 meters bump, and then staying at BARO + 8 for the rest of the flight. When Alt Hold is invoked, suddenly there’s a CTUN.DAlt of +8m.

All motors ar kicked hard, but if you look at BARO readings, there’s zero height gain.

FC is reported as fmuv3, ChibiOS, 3.6.11. I’d treat it as a Pixhawk clone with rev3 uC, but there’s a 2nd baro being logged that baffles me. It could as well be a Black Cube, with Here2 on CAN, and an old bootloader, not loading the proper firmware and being affected by the Service Bulletin issues.

That’s what I suspect. It’s possible to load fmuv3 firmware on a Cube, and this will cause the service bulletin warning to not appear.

This looks normal to me. The EKF sets its origin when the GPS gets a lock. The desired altitude doesn’t seem to match any of the various altitudes. And it should, given that RC3 was within the mid-stick deadzone.

OK. You’ll have to explain to me that EKF origin discrepancy in altitude :wink:

Why it crashed, for me, is clear. It’s the first time in the entire flight the motors get pushed, and they can’t deliver. Desyncs, FETs that let out the magic smoke, solder getting liquid, ESCs running slow, I’ve seen them all. Whenever I take off, and there’s no need for default P/D adjustments (it won’t oscillate) I do a couple of hard rolls, then hard pitches,and a pair of left-right 360 yaws just to validate the platform is airworthy. I’ve seen a lot of builders going slow and pampering their builds, and also seen the aftermaths :smiley:

Now, back to that height discrepancy. Notice that there’s an arm/disarm event further in the log that doesn’t clear it !?

Yeah. AHR2.Alt can be understood as “absolute barometer altitude,” and it’s basically baro alt + home altitude. The offset that appears is the home location being set on arming. The home location uses GPS as its absolute altitude source, which was unavailable on the first arming event, so the offset appeared on the second arming. The third arming event changed the home altitude only a tiny bit, so the ~8 meters offset stayed.

No, the FC is Pixhack V3x, What should I do next to prevent it crash again ?
Thank you very much.

What caused the message ’ EKF primary changed to 0 to 1" ? Is it a hardware error?
Then I connected the FC to Mission Planner, It showed the ’ ax ay az , ax2 ay2 az2(IMU2), ax3 ay3 az3 were all normal with numbers and were changing.

No, this happened just after the drone landed, so probably the impact from landing or the vibration from spinning the motors on the ground caused this. Not a concern.

Alt Hold shouldn’t cause a sudden throttle increase. I don’t know why that happened. However, you might want to test your motor/ESCs. They should be capable of handling rapid changes in throttle without failing.

1 Like

Yes,I agree with that. But my drone is 170KG flight weight with 62 inch props
The single motor is 6KG weight and slow response

That’s uncharted territory, and all you can get is a wild guess. My experience stops short of 20 Kg AUW, and that wasn’t an easy to fly copter.

First things first: are you sure that your ESC/motor/prop combo is performing ? In all my tests with large props - upto 28 inch, mind you, so I shouldn’t use the term “large” - it was the ESC that couldn’t cope up with demands. Or the motor. Or a combination of both. It’s actually hard to tell, in the brushless world, where the blame lies, without very specialized equipment.
Because a certain prop requires a certain motor torque to act well, and you’ll never ever see torque@rpm listed amongst motor characteristics. kV, power, maximum volts and amps, but no torque.
And it’s torque, or the lack of, that usually makes things go south in our 'copter world.

Do a test, bolt a motor with prop to something solid, assign a channel to a 3-pos switch, set its positions to 1000 - 1150 - 2000, and start flipping between the two top positions of the switch. If it’s not actinng smooth, there’s your fault.