Mavic mini moved alone without stick input

[BudWalker]

I have made the link public

I took a look at the .DAT you provided.

There were none of the usual indications that uncommanded descent occurred. The leftBack motor was commanded > 95% briefly. But, there was none of the prolonged 100% commanded seen in the back motors that normally happens in an uncommanded descent.


There were two yaw adjustments; the first at 826 and the second at 846. The FC decided, for some reason, that the yaw value is incorrect and changes it without actually rotating the MM. Here is the yaw and magYaw plot.

Not shown is the time integrated Z axis gyro data which confirms that the MM didn't rotate and that magYaw is actually correct. I'm not entirely clear if this was involved in the incident. But, it does invalidate the wind calculations present in the .DAT as well as those done by AirData.

In my previous post pitch data was used but tilt (roll and pitch) should have been used. In addition, since Yaw is invalid then magYaw should be used instead.

As expected, the tilt angle increases to 30° with the change to Sport mode. However, 15° seems to be the maximum for P-GPS where it should be 20°. I'm not entirely clear why it's limited to 15° but I do see this limitation in other flights.

Looking at the flight path It can be seen that the MM is being pushed backwards in P-GPS-mode but then makes forward progress in Sport mode. The cyan bar shows the magYaw value which assumed to be the MM heading.
.

Got all that? The best explanation I can offer is that the MM was being pushed by the wind.

 

[Meta4]

Got all that? The best explanation I can offer is that the MM was being pushed by the wind.

The speed data has a lot of false values.
Can you explain what causes the crazy indicated speed changes?

 

[BudWalker]

The speed data has a lot of false values.
Can you explain what causes the crazy indicated speed changes?

The short answer is that I don't have a good explanation for those velocity values. In .txt-to.csv converters previous to the .txt-to-.csv found in both AirData and the FlightReader there was aliasing in the hSpeed data. These converters created the hSpeed data by time differentiating Lat/Long data; i.e. hSpeed wasn't extracted from the .txt. I've since learned from @msinger that that the .txt-to-.csv converter used by FlightReader extracts the hSpeed data from the .txt.

I had previously stated that CsvView creates hSpeed data by time differentiating Lat/Long data. That's incorrect and pretty embarrassing since I wrote the code that creates the IMUCalcs:hSpeed data. CsvView creates IMUCalcs:hSpeed as being equal to sqrt(xSpeed * xSpeed + ySpeed * ySpeed). This field was added to CsvView in response to the aliasing problems encountered in previous .txt-to-.csv converters.

Regarding the origin of the spurious hSpeed values. It's unknown, at least to me, how the Flight Controller computes hSpeed. But, generally, it must be the result of fusing raw data such as magnetometer, accelerometer, gyro and, to a lesser extent GPS velocity data. Unwinding all this is difficult since it's unknown how hSpeed is computed. The relatively low sample rates don't help.

Note that my supposition that the incident was wind related doesn't depend on hSpeed data. It only depends on the tilt angle, position data and heading.

 

[Meta4]

The short answer is that I don't have a good explanation for those velocity values.

I haven't run into this velocity data issue before.
Do you have an idea how commonly it shows up?