This is an interesting one. My analysis is obviously incomplete at this moment, and I will not cover every single thing I saw (although the notch filter is definitely not configured properly), but it still might be helpful.
I will concentrate not on a crash, but on the first hiccup moment of the flight and on the following 25 seconds, because, as we will see later, something likely happened with the machine which complicates the further analysis. A video of the incident would have helped, but I would understand if there was none.
What I call the hiccup, started at timestamp 17:15, when the machine flying at horizontal speed of about 11 m/s was commanded to stop by moving the pitch stick from almost full forward to center in two seconds. The machine reacted by braking as expected, which changed desired pitch from about -7 degrees to about +9 degrees, and then, later, to +21 degrees. Around that moment, at 17:18, actual pitch started to run out of control, and things went haywire.
Note that here at this moment, the GPS altitude raised a little bit, from 10.8 to 11.1 meters, although this was not commanded: the throttle stick was centered at this time, and remained pretty much centered throughout the whole time segment I am talking about. What else changed is that CTUN.ThO, which indicates the relative average thrust commanded, went to straight zero just before the loss of control.
What I suspect was happening on the physics side of things, is a combination of several factors, although I am not quite sure in which proportions:
- Lift from the propellers increased temporarily as the machine was slowing down. As you brake, you are pushing the machine onto the oncoming undisturbed air, which you have some speed against, propeller bottom first, which temporarily increases the apparent lift.
- Propeller inertia made it impossible to slow down some of the propellers as quickly as the current configuration required them to do, so Ardupilot was essentially thinking the props rotated slower than they actually did
- The value of
MOT_SPIN_MIN was set to a default, which may be appropriate for a machine flying at roughly half throttle, and not appropriate to a lightweight machine that was hovering at around 0.18. Ideally, this one is set such that on minimum expected battery charge the resulting rotation speed still follows the general throttle curve, but not much more than that.
With CTUN.ThO at zero, motors started to hit MOT_SPIN_MIN, and with the configured throttle mixing, the machine started to give up its authority on axes to preserve zero throttle - otherwise, it thought, it would have run away. This is why the 17:15-17:18 section of RCOU looks the way it looks.
The RCOU trends from 17:18 onwards look as follows: motor 4 at max, motor 3 at min (both hitting their saturation limits very often), motors 1 and 6 above average, motors 2 and 5 below average. The average itself around 17:30 is much higher than hover throttle, but this can be explained by the fact that the machine tried to gain the altitude lost in the previous culprits. By looking at the wiring diagram, the aft right corner received very high thrust, and the opposite was the opposite. This, for me, does not indicate a motor or prop failure, which would result in one motor inconsistent with others and/or thrust loss warning at detection of such an imbalance.
What I suspect to be the immediate cause of the crash was that something moved in the frame towards aft right during the first incident of attitude control loss and recovery. It was something heavy, so for a nearly-empty craft my main suspect is the battery. The subsequent attitude control losses likely moved that in other random directions, and the machine could not cope with that - especially given the necessary throttle reduction needed to land.
The cause for attitude control losses, in turn, is, in my opinion, a combination of configuration issues and the machine being a bit overpowered for how it flies. One of the most obvious issues from my point of view is MOT_SPIN_MIN not configured to match the actual machine, but I also suspect that Loiter braking is probably configured too aggressively for the degree of control available.
