Quadcopter Crash on AC 3.4-rc4

ArduCopter Copter 3.4
21

@rmackay9:
Thank you very much for the detailed answer.

It is good that it is confirmed stabilize could help in high vibration situations like this. Unfortunately, everything happened so fast and by the time I’ve switched to stabilize, the aircraft was already out of my sight.
Although I cannot see the board to bounce inside the case, I will also use extra double-sided foam to secure it better.

Again, thank you for considering adding the fall-back to barometer based altitude hold to ArduCopter, it really improves safety.

When the parts arrive and after rebuild, I will do more tests on rc4 (or whatever version is current by that time) and provide feedback.

22

@Frontier
Hi

You can track the progress of a possible solution here https://github.com/ArduPilot/ardupilot/issues/4825

As a general rule I would urge all users to reserve one channel for the Motors Emergency Stop.

http://ardupilot.org/copter/docs/channel-7-and-8-options.html

Remember that it kills the motors, BUT you have 5 seconds to change your mind :slight_smile:

23

@LuisVale: Thank you very much for your help and suggestions.
I will flash my PixRacer with -rc5 and when the new frame/motors arrive and start re-building, I’ll reserve one channel for the emergency motor stop function, just in case the new build tries to skyrocket again :smile:

24

Hi rmackay9,

     Happy to hear that you and your parter(other developers) have been aware of this issue, I have also met this issue before and resulted in several crash.
     After that, I spent lots of time and wanted to know the reason why high vibrations will cause rise even low throttle.
     Now we have found the reason and solved this issue as follows:
     In this function AC_PosControl::accel_to_throttle(), we calculate throttle out according to  measured accel_z and target accle_z. Therefore, if the vibrations too high or accel sensor is bad, the measured accel_z is unreliable. 
     I have analyzed our logs of crash, and found ratio in EKF2 equals to 0 or 100,and accel_z in imu1 or imu2 is unnormal and the bad accel_z caused rise.
     Now, we have two improvements: 
     1.add limitation in the function AC_PosControl::accel_to_throttle().

z_accel_meas = -(_ahrs.get_accel_ef_blended().z + GRAVITY_MSS) * 100.0f;
z_accel_meas = constrain_float(z_accel_meas, -_accel_z_max_meas, _accel_z_max_meas);

      2. add a function rate_to_throttle() in AC_PosControl::rate_to_accel_z()

_ekf.getIMU1Weighting(ratio);
if (ratio >= _ratio_threhold && ratio <= (1 - _ratio_threhold)) {
_last_imu_ok_time_ms = hal.scheduler->millis();
} else if (hal.scheduler->millis() - _last_imu_ok_time_ms > POSCONTROL_IMU_ERROR_TIMEOUT_MS) {
rate_to_throttle(_vel_error.z);
return;}

    That's to say, if ratio is normal, we use accel_to_throttle(), if not ,we use rate_to_throttle() to calculate throttle out according actual velocity_z and target velocity_z.
     Hope it  helpful to you, and hope also you can have better solution to release this issue.
     If any problem, contact me by email. 
     Eric Xiao           Email: qifu.xiao@outlook.com