Help analyzing a Mini crash - link to Phantomhelp.com log provided

[Keule]

It was only 11 mph at 328 feet, she was only about 120 feet.

As @Meta4 already stated in post #6, the problem was not the wind.

 

[shorttimer]

It was only 11 mph at 328 feet, she was only about 120 feet.

Ventusky - Weather Forecast Maps

Live wind, rain, radar or temperature maps, more than 50 weather layers, detailed forecast for your place, data from the best weather forecast models with high resolution

www.ventusky.com

I totally agree graham, the wind shouldn't be a factor in this. Very possible what Meta4 suggests that taking off from a dirty magnetic area. I know he is really into the magnetic/compass areas. Need a Skydio 2 drone as it has no compass.

 

[pmshop]

It was only 11 mph at 328 feet, she was only about 120 feet.

Ventusky - Weather Forecast Maps

Live wind, rain, radar or temperature maps, more than 50 weather layers, detailed forecast for your place, data from the best weather forecast models with high resolution

www.ventusky.com

Forecst are just that.
Air Data uses an aglorythm from data that is generated by the craft.
Much more accurate reading.
No idea how far away that weather balloon was.
The AirData reading was taken by the craft itself.

 

[Prismatic]

Am bringing this over from the DJI forum with the pilot's permission.

As has been suggested, that flight certainly looks like a classic yaw error, usually induced by a magnetically distorted launch point. But I haven’t seen a proper log file analysis yet (and I’m not qualified to do it). This may require the help of @sar104 .

 

[BudWalker]

I have already analyzed this crash in the other forum.

I used both CsvView and also FRAP to analyze the flight log.

IMHO it is no fault of the pilot or wind.

1) Everything is fine except the GPS health being 4 instead of 5 during the whole flight.

2) The IMU had velocity and direction failure about 27 seconds into the flight.

View attachment 88760

A word or 2 about the IMUCalcs stuff which I've been meaning to document. IMUCalcs are calculations done by CsvView based on data in the .txt.

The calculations are based on two separate data sets.

1. VelN and VelE are computed by the Flight Controller using mostly the data coming from the accelerometers and gyros.
2. GpsLatitude and GPSLongitude are computed by the Flight Controller using mostly the data coming from the raw GPS data.

Ideally, integrating VelN and VelE should produce values that exactly match GpsLatitude and GpsLongitude. Also, differentiating the GpsLongitude and GpsLatitude values should produce values that exactly match the VelN and VelE values. When there is mismatch it’s usually caused by an incorrect Yaw value. In turn, an incorrect Yaw value can be caused by either 1) incorrect magnetometer data, or 2) the FC making incorrect decisions about how to compute Yaw.

The IMUCalcs does the integration and differentiation described above. It also compares the differentiated GPS position values against VelN and VelE.

The Velocity and Position error signals become true when a threshold is exceeded. Presently, the velocity threshold is 3.5 m/s and the position threshold is 6 meters.

 

[grahamjohnson10]

A word or 2 about the IMUCalcs stuff which I've been meaning to document. IMUCalcs are calculations done by CsvView based on data in the .txt.

The calculations are based on two separate data sets.

1. VelN and VelE are computed by the Flight Controller using mostly the data coming from the accelerometers and gyros.
2. GpsLatitude and GPSLongitude are computed by the Flight Controller using mostly the data coming from the raw GPS data.

Ideally, integrating VelN and VelE should produce values that exactly match GpsLatitude and GpsLongitude. Also, differentiating the GpsLongitude and GpsLatitude values should produce values that exactly match the VelN and Vel values. When there is mismatch it’s usually caused by an incorrect Yaw value. In turn, an incorrect Yaw value can be caused by either 1) incorrect magnetometer data, or 2) the FC making incorrect decisions about how to compute Yaw.

The IMUCalcs does the integration and differentiation described above. It also compares the differentiated GPS position values against VelN and VelE.

The Velocity and Position error signals become true when a threshold is exceeded. Presently, the velocity threshold is 3.5 m/s and the position threshold is 6 meters.

Please let me know what VeIN & VeIE stand for.

Sorry but I'm still learning how to anialize flight logs.

 

[BudWalker]

Please let me know what VeIN & VeIE stand for.

Sorry but I'm still learning how to anialize flight logs.

VelN == true North velocity
VelE == true East velocity

 

[grahamjohnson10]

VelN == true North velocity
VelE == true East velocity

Thank you

 

[grahamjohnson10]

VelN == true North velocity
VelE == true East velocity

Thanks a lot for your help, so what is your take on this fly away.

 

[sar104]

This was not caused by high winds. The txt log doesn't really provide enough information since it only records the IMU sensor fusion solution rather than the raw sensor data, but comparison of the time derivative of position with the recorded velocity shows significant disagreement:



That's generally indicative of a yaw error, but not definitive. Additionally, the high frequency oscillations are unusual.

The mobile device DAT file may shed more light on this:

How to retrieve a mobile device DAT file: How to retrieve a V3.DAT from the tablet

 

[BudWalker]

Thanks a lot for your help, so what is your take on this fly away.

Almost certainly caused by a geomagnetically distorted launch site. I have posted this back over on the original DJI forum thread.

Errors with MAVIC MINI! Flyaways caused two crashes!
post #49

I suggested to the OP there that she retrieve the .DAT for additional confirmation.
@sar104

 

[BudWalker]

Thanks a lot for your help, so what is your take on this fly away.

BTW, the IMUCalcs calculations that CsvView does is due to @sar104. CsvView now implements what he is able to do with the data analysis package he uses. The post before this one is an example.

 

[BudWalker]

This was not caused by high winds. The txt log doesn't really provide enough information since it only records the IMU sensor fusion solution rather than the raw sensor data, but comparison of the time derivative of position with the recorded velocity shows significant disagreement:

View attachment 88783

That's generally indicative of a yaw error, but not definitive. Additionally, the high frequency oscillations are unusual.

The mobile device DAT file may shed more light on this:

How to retrieve a mobile device DAT file: How to retrieve a V3.DAT from the tablet

Additionally, the high frequency oscillations are unusual.
Overall, the IMUCalcs that CsvView does looks the same as the calcs you do with Igor.



But, the CsvView calcs have some of the finer detail missing. I suspect that Igor does a better job of calculating the GPS position time derivative to obtain the velocities. Is it possible that the Igor derivative routine is introducing an artifact that makes it look like oscillations are occurring?

 

[sar104]

Additionally, the high frequency oscillations are unusual.
Overall, the IMUCalcs that CsvView does looks the same as the calcs you do with Igor.

View attachment 88789

But, the CsvView calcs have some of the finer detail missing. I suspect that Igor does a better job of calculating the GPS position time derivative to obtain the velocities. Is it possible that the Igor derivative routine is introducing an artifact that makes it look like oscillations are occurring?

I'll take a look at those derivatives and check for numerical artifacts, but I wouldn't expect them - they don't usually occur in these situations.

 

[sar104]

Additionally, the high frequency oscillations are unusual.
Overall, the IMUCalcs that CsvView does looks the same as the calcs you do with Igor.

View attachment 88789

But, the CsvView calcs have some of the finer detail missing. I suspect that Igor does a better job of calculating the GPS position time derivative to obtain the velocities. Is it possible that the Igor derivative routine is introducing an artifact that makes it look like oscillations are occurring?

The oscillations seem to be in the data, rather than numerical artifacts. If you plot the lat/long data directly against each other:



Converting to distance north and east, and differentiating with respect to time:



The resulting velocities appear to correctly reflect the discontinuities in the position data.

 

[BudWalker]

The oscillations seem to be in the data, rather than numerical artifacts. If you plot the lat/long data directly against each other:

View attachment 88791

Converting to distance north and east, and differentiating with respect to time:

View attachment 88792

The resulting velocities appear to correctly reflect the discontinuities in the position data.

I suspect this is the result of the fusion scheme having to make relatively large corrections. The Lat/Long isn't pure GPS data - the time integrated VelN and VelE are being used a little to compute Lat/Long. The relatively large errors in VelN and VelE cause larger errors in Lat/Long values. Presumably, the GPS data (if we had the .DAT) will be smoother.

 

[sar104]

I suspect this is the result of the fusion scheme having to make relatively large corrections. The Lat/Long isn't pure GPS data - the time integrated VelN and VelE are being used a little to compute Lat/Long. The relatively large errors in VelN and VelE cause larger errors in Lat/Long values. Presumably, the GPS data (if we had the .DAT) will be smoother.

Agreed - I think that is a probably good illustration of sensor fusion struggling when the weighted average from the slow data disagree significantly with the fast data. I'd argue that the FC should give up and switch to ATTI when faced with this kind of divergence.