I am somewhat against the idea of a software bug. Everything, in my opinion, points to two factors: an extremely poor building quality, and a noticeably poor tuning.
For the build quality, the very first glaring issue is that vibrations are Really Bad.
This should not be allowed to fly over people. With vibrations routinely reaching 80 according to IMU1 and 100 according to IMU2 - which is 8g and 10g respectively (!!!) - one just cannot expect any reasonable performance.
What is more, this can also explain GPS glitches. A GPS antenna may be mounted differently than the flight controller, but this level of shakiness can reach the antenna too. And GPS chips have a legal duty to stop sending you signals when they detect high accelerations. Basically, I am quite sure that the GPS glitch that happened at 23:10 was because the chip started to think it was guiding a missile.
(My skills and tools to analyse GPS-related issues are currently limited, but I do see that there is a single GPS log record that is co-located with the “GPS or compass error” message and stands out by its timing: it got logged 20ms earlier than it should. It may be for different reasons, and I cannot diagnose this right now, but my primary suspects are the above and the EKF lane change, which got logged at the same moment)
These levels of vibrations are IMHO very probable to also cause all sorts of power connectivity issues.
Now to the crash initiation sequence, which is very likely to have nothing in common with GPS issues - because I see nothing extraordinary control-related in the logs in first second after the GPS event, so the flight controller reacts gracefully at least. This sequence, among other effects, raised the vibration levels to their extremes (10g and 12g depending on which IMU you look at).
I would not say that, based on what I see in the configuration and in the flight. For instance, the notch filter is misconfigured because INS_HNTCH_REF is zero. It does not filter anything except for few fixed frequencies - so it does not work.
Overall, the copter is barely tuned, and it is a sheer luck that the default PIDs are not catastrophically off for this particular machine. The default D term value is a huge red flag, for instance.
And here is another mandatory safety rant, because
one does not fly over unrelated people and buildings when doing basic tuning, period. This is non-negotiable.
Out of the tuning issues, the most contributing issue to the crash, in my opinion, is the position controller. The Initial Tuning guidelines tell to set PSC_D_ACC_P to be 0.1 of the throttle hover, and PSC_D_ACC_I to 0.2 of the throttle hover. The defaults (untouched!) assume that throttle hover is 0.5. This machine has 0.13. As a result, we have quite strong altitude controller oscillations throughout the flight:
One can see these with a naked eye in plots for motor outputs, where all motors “jump” synchronously. This reduces control margins, and this definitely contributed to the initial loss of control:
Here, in the moments leading to the instability, we are flying fast forward and start descending quite quickly. One can see the altitude control oscillations here both in the peak (when the machine was commanded to ascend for a bit) and as motors came close to their minimum output. The copter might have worked through this request nicely if not for the altitude controller oscillations. Once the motors get cropped by MOT_SPIN_MIN, the machine has to decide whether to keep altitude (e.g. the descent rate) or to keep attitude (e.g. the angles), and with quite a high horizontal speed giving up on either is dangerous.
TL;DR in my opinion: a very poorly built, poorly tuned overpowered drone. (“Overpowered” by itself is very manageable, but it does not play well with the other two characteristics). And a very low safety culture atop of that.
