Unexpected Rapid Climb on Takeoff

Hi everyone,

I’m having an issue with a recently purchased RTF quadcopter (ZHT Naga X4) equipped with a Cube Orange+ and Here3+ GPS. The aircraft had noticeable vibration problems out of the box. The dynamic notch wasn’t configured and the tune wasn’t ideal, so I began retuning following the recommended procedures. To address the vibration, I replaced the FC damping foam and set up the notch filters.

It’s worth noting that I have already flown the copter on these same tuned parameters previously, and no parameters were changed before this problematic flight.

During today’s takeoff, the copter suddenly started climbing extremely fast (around 8–12 m/s), despite PILOT_SPEED being set to 3.5 m/s. I instinctively switched to AltHold and then RTL, which restored control.

I’m considering two possible causes:

  1. ESC desync or a faulty motor/ESC,

  2. I armed the copter without props before the flight, which caused MOT_THR_HOVER to rise to 0.42 (normally around 0.15).

While reviewing the logs, I also noticed a lag between the desired and actual values. Could this have contributed to the unexpected climb?

Flight Logs

Any insights or suggestions would be greatly appreciated. Thanks in advance

Every single post on this forum is a request for help. No need to mention that in the title.

Reduce vibrations and start following a more structured approach to configuring and tuning.

1 Like

You have very old firmware on that craft and the tune is terrible. Reset all to default, update to the latest Stable version of firmware and start over. As @amilcarlucas said the vibration levels are way to high to advance, fix that 1st.

1 Like

Thanks for the feedback, both of you.

Regarding the vibrations — I agree they need to come down further. I’ve already replaced the FC damping foam, checked the frame, and enabled the dynamic notch. I’ll continue working on reducing the vibration levels before doing more tuning.

About the firmware: the quad came with that version pre-installed (it’s an RTF unit), so I initially kept it to maintain consistency during troubleshooting. I’m okay with wiping the configuration, updating to the latest stable release, and starting from scratch if that’s the best path. Before doing that, though, I’m trying to understand whether the sudden climb could be explained by anything visible in the logs.

My main concern is the unexpected ~8–12 m/s climb despite PILOT_SPEED being set much lower. I had a number of flights on this tune before the incident, with no parameter changes in between, so I’m trying to determine whether:

  • the temporary rise in MOT_THR_HOVER after arming without props, or

  • any lag between desired vs. actual values

could have contributed to the behaviour.

I’m happy to reset and retune, but I’d like to understand the root cause so I don’t repeat the issue after the rebuild.

@rmackay9 I’d appreciate your input on this as well if you have a moment.

Hi @1afridi,

I pretty much agree with the others comments. Another red flag for us is that a number of the ARMING_CHECKs have been disabled including the “INS” (e.g IMU). I strongly recommend setting ARMING_CHECK = 1 and then try and resolve any issues that come up in the pre-arm checks. My guess is that they will tell you the cause of the issue.

The vibrations in the Y axis (left-right) are very bad. The X (forward-back) and Z axis are quite good actually so there’s almost certainly something physically wrong with the vehicle.

I agree with the advice to upgrade to 4.6.3.

I was expecting to see an EKF issue with the velocity and position moving in opposite directions but we don’t see that.

The lowest level vertical acceleration control’s “Act” (actual acceleration from the IMU) are incredibly noisy. This is the cause of the inability for the vehicle to control its altitude.

.. surely the issue is vibration, it’s just slightly surprising that it doesn’t show up in the VIBE.Z message.

1 Like