Hi All,
We’ve flown hundreds of hours on these hexacopters, but I’ve never seen this.
As the hexa was descending down a hill in auto mode (terrain following), the PWM for all 6 motors went to the minimum value of 1190, ie all 6 motors stopped and the drone descended another 32m into the ground. I’m really perplexed as to what’s happened.
You’ll notice on the photo of the crash that none of the props are damaged, indicating they weren’t spinning on impact. There is a tow rope caught around one propellor, but we’ve had a tow rope get caught before and the hexacopters are amazing at flying perfectly fine without a motor spinning.
I’ve looked through both for a long time and can’t see any reason for this happening. Yes, the drone is poorly tuned with individual props stopping in flight for short periods throughout the flight. The drone is made to have long flight times and our payload was only 500 grams, therefore the motors are normally only running at 25% and the minimum arming % for the motors is16%. No errors for any of the sensors appear, from what I can see.
If anyone has any ideas as to how this happened it would be much appreciated. Thanks, Adam.
The Throttle was full down, and the climb rate was steady. With the way the motors were oscillating there must have been enough confusion for the controller to think it was landed.
Thanks Allister, you’re right, sorry I hadn’t seen the events, I can see it now.
I’m reading ardupilot/ArduCopter/land_detector.cpp at master · ArduPilot/ardupilot · GitHub
It seems that the throttle is one of the first identifiers on whether the copter has landed;
SET_LOG_FLAG(motor_at_lower_limit, LandDetectorLoggingFlag::MOTOR_AT_LOWER_LIMIT);
SET_LOG_FLAG(throttle_mix_at_min, LandDetectorLoggingFlag::THROTTLE_MIX_AT_MIN);
Then it checks the angle, because if landing, the angles are going to be at a minimum. In this case the drone was descending, vertically down a vertical hill.
const Vector3f angle_target = attitude_control->get_att_target_euler_cd();
bool large_angle_request = angle_target.xy().length() > LAND_CHECK_LARGE_ANGLE_CD;
Then it checks that the aircraft is not accelerating forward or back, which it wasn’t because it was descending vertically,
bool accel_stationary = (land_accel_ef_filter.get().length() <= LAND_DETECTOR_ACCEL_MAX * land_detector_scalar);
It then checks that the vertical speed is less than 1m/s
bool descent_rate_low = fabsf(inertial_nav.get_velocity_z_up_cms()) < 100.0 * LAND_DETECTOR_VEL_Z_MAX * land_detector_scalar
For some reason the drone had only descended 1m over that 4 second period. It should have been descending faster.
The next check is if the range finder is above 2m. We didn’t have a rangefinder installed. I think we will need to install rangefinders as this would have stopped this event. Perhaps this check should also include terrain altitude being above a larger value like 10m, as the terrain altitude at this time was 38m.
The next step in the code is to say if all of these parameters are true then landing has occurred.
From reading the code, it appears that any very slow (less than 1m/s) vertical descent when draping terrain for a copter without a range finder would cause this failure.
Also to note, we had flown this hill previously, but with a 6.5kg payload attached and it descended fine, the difference would have been that with the large payload the throttle wouldn’t have been 0, it would have been about 50%.
I think there’s a bit of a perfect storm of things happening. Perhaps if the tune was better it may have handled the descent better without the motor oscillations. That probably would have kept the throttle from going to min value. Also if the drone is that powerful, you may need to consider a minimum weight for that type of terrain.
The tune looks poor with high Output, Rate and Attitude Oscillation. Notch filter should be configured and the PSC_ACCZ_P&I parameters are not right. Perhaps P is for the loaded condition but I isn’t.
