Strange brief uncontrollable incident during loiter endurance flight

ArduCopter Copter 3.6
1

Hello all in the ardupilot forums. Your help has been invaluable, and I hope that you guys keep helping people like me in this journey of discovery of the amazing CUBE controller and Ardupilot firmware.

Yesterday, in a flight made to test the battery failsafe of the copter (which has a CUBE and the latest copter firmware to date), during an extended loiter, our pilot decided near the end of the run (after 19 mins) to give a small input to the copter (coaxial octo-copter), and right after the set of inputs the copter became out of control, as if something was wrong, for a total of approximately 3 seconds, after which, the copter regained stability, allowing us to ground the copter:

Gyro Readings:
image
Acc Z:
image
Pitch/Roll P (controller):
image
Desired Roll/Roll:
image
Desired Pitch/Pitch:

image
image.png720×149 24.5 KB

This event also triggered all kinds of issues, such as velocity/magnetometer variance triggers in the EKF, reduction of the satellite count in the GPS, voltage drop, but all of these I believe are just synthoms of the problem.

So far, the following are the possibilities I have been thinking about:

  • Possible accelerometer gyro cross-coupling caused by the addition of a soft mount to the CUBE, since it used to experience very strong vibrations (we are aware that the recommendation is to hard mount the cube, but this frame is a large copter and vibrations could not be avoided).
    image
  • Possible mistuning of the copter, which led to an unstable mode that almost caused the copter to lose control from the very specific input given. The copter was tuned using autotune at its most restrictive setting.
  • Much less likely: error in the GPS/Compass reading due to the addition to the new Here2 module connected by UAVCAN protocol.

If the first possibility happens to be the case, is there any for sure way to see if there is a cross-coupling between gyros and accelerometers directly from the dataflash log? Because FFT doesn’t show anything meaningful above 25Hz (no 80hz peak).

Here is the log of the flight. Any type of input will be appreciated.

2

At full battery you are hovering at only 17% throttle, before the incident, at lower voltage , at 21%
This is dangerously close to your MOT_SPIN_MIN of 0.17 , and incorrectly set MOT_SPIN_ARM of 0.18 (should not be that high)
The roll input instantly caused some motors to start bottoming out at the MOT_SPIN_MIN

You should maybe soften up RATE_P , but most importantly: check if you can reduce MOST_SPIN ARM, check the motors/ESC for desync issues at such low RPM (is that about 120KV motors?), and consider using MOT_BAT_VOLT* for better regulation.

3

Hello Andre, thank you for your input. It makes sense that hovering at such low throttle setting and these tight thresholds may be inducing problems (which we will see how to address right away), but we also had other previous inputs during the flight (mid-way) without any problems, so I am still not sure that the issue can be just blamed on the overpowered motor.
However, it is clear that there was a divergence in between motors 2/5 (upper left) and motors 4/7 (lower right) where they will attempt to compensate on each other (maxing one set, bottoming the other set) with a growing amplitude, where the rc input occurred at line 478200:

image
image.png1870×600 30.3 KB

So perhaps the issue can also be a poorly tuned gain in the motors, just like you said in the end, but it could be due to a poor auto tuning due to the soft mounting that I am using with the drone?

Thank you again for your reply

4

There is not only one cause to what you have seen.
Certainly not PIDs alone.
Be sure to test for desync issues, and you may lower PIDs , and/or enable PID logging.
In case of such behaviour again, in my experience, it helps to switch increase throttle, and input some pitch/roll, to reduce such oscillations.