Was it High Wind That Caused This Drone Drowning?

[BudWalker]

......

Being very new to drones, I'm keen to learn. You said the way I did the compass re-callibration wouldn't have helped. How do you tell if the compass just needs re-callibration because it's been in the car too long or otherwise and when it actually doesn't need re-callibration because the discrepancy between the way the drone is pointing and the direction the Go 4 app says the drone is facing is due to magnetic interference? I'm guessing you would walk to a nearby area that is most likely free of metal, such as a grassed area and see if the two agree there.

I suppose that you can't tell the difference. But, it's far more likely that if the Go App map heading indicator doesn't agree with the actual orientation it's because the launch site is geomagnetically distorted. The only way to fix that is to move the launch site to a location where the heading indicator agrees with the actual orientation. If you can't find such a location then it's time to think about re-calibrating.Or, that the compass is broken.

No amount of calibrating can "fix" the problem of a geomagnetically distorted launch site.

You said that you had flown in this area before without incident. The distortion extent can be small - less than 2 cm. So moving the AC 1 cm can make the difference.

BTW, in the incident you reported the Go App would have been showing a heading of 75° at launch but the AC actually had a heading of 30°.

 

[BudWalker]

Looking at your description a bit closer.

..... compass just needs re-callibration because it's been in the car too long ....

Are you powering up inside the car and then moving the MA to it's launch site? In this case the correct procedure would be to wait until the heading indicator aligns with the actual orientation.(Could take as long as 120 secs) Either that or power cycle the MA at it's launch site.

When the battery is turned on the magnetometer data starts at about 2 secs. Then Yaw is initialized from the magnetometer data. Thereafter Yaw is determined mostly from IMU data with magnetometer data providing low gain corrections, i.e. there is a delay in the corrections the mag data provides.The initial mag data would probably be incorrect since it was inside the car. Yaw would also be incorrect since it's initialized from the mag data. Moving the MA to a non-distorted, mag data correct site won't cause an immediate Yaw correction.

Power cycling at the non-distorted site (outside the car) will result in correct mag data, and, subsequently, correct Yaw initialization.

 

[briano216]

Looking at your description a bit closer.

Are you powering up inside the car and then moving the MA to it's launch site? In this case the correct procedure would be to wait until the heading indicator aligns with the actual orientation.(Could take as long as 120 secs) Either that or power cycle the MA at it's launch site.

When the battery is turned on the magnetometer data starts at about 2 secs. Then Yaw is initialized from the magnetometer data. Thereafter Yaw is determined mostly from IMU data with magnetometer data providing low gain corrections, i.e. there is a delay in the corrections the mag data provides.The initial mag data would probably be incorrect since it was inside the car. Yaw would also be incorrect since it's initialized from the mag data. Moving the MA to a non-distorted, mag data correct site won't cause an immediate Yaw correction.

Power cycling at the non-distorted site (outside the car) will result in correct mag data, and, subsequently, correct Yaw initialization.

Thanks for that helpful information.

The mention of the car was because at the time we were on a trip through the UK and so most of the time the MA was in the car. I wondered if the traveling over roads that were quite rough at times (particularly in the Scottish highlands) could put the compass out. Mind you, I always kept the MA in it's bag and in a soft place in the back seat. I never start the MA in the car, but move to the site I deem suitable for takeoff and then start it. On the day of the incident the car was about 100 meters away.

 

[Air Beetle]

If I power up and a compass calibration is required I always power down and back up after the calibration in the new location just for the heck of it. I have powered up on the tailgate of my truck to check settings and it hoses the compass every time, as expected.

 

[BudWalker]

If I power up and a compass calibration is required I always power down and back up after the calibration in the new location just for the heck of it. I have powered up on the tailgate of my truck to check settings and it hoses the compass every time, as expected.

I can't quite tell if you're powering up on the tail gate, seeing the compass error, and then re-calibrating because of the compass error message. If so, no calibration is needed. All you have to do is power it up at a location where you don't see the compass error.

 

[briano216]

Can someone please tell me the best website to use to analyse your flight log and your data file? I'm getting no sense from DJI regarding the fact that my drone drowned because of malfunctions so now I'm taking them to VCAT (Victorian Consumer Affairs Tribunal), so I need to be able to locate all the data myself so I'm not having to tell the tribunal that someone else got the data for me. I've had a brief look at the Air Data website - is that the best one to use?

 

[sar104]

Can someone please tell me the best website to use to analyse your flight log and your data file? I'm getting no sense from DJI regarding the fact that my drone drowned because of malfunctions so now I'm taking them to VCAT (Victorian Consumer Affairs Tribunal), so I need to be able to locate all the data myself so I'm not having to tell the tribunal that someone else got the data for me. I've had a brief look at the Air Data website - is that the best one to use?

Unfortunately none of the analysis websites will do anything close to the kind of analysis of the DAT or txt files that @BudWalker and I provided. It would be difficult to automate the process. CsvView will plot the graphs that @BudWalker posted or I'd be happy to send you any of the data files (as opposed to images of the output graphs) if that would help. Otherwise I'm afraid that the analysis is well beyond the scope of the casual user.

 

[briano216]

Thanks, sar104. I'm just wanting to be armed and ready so that DJI can't catch me off guard at the tribunal or confuse me because I'm new to drones. It only costs me $63 to take them to the tribunal and at the tribunal it's the judge that decides whose right, not DJI - hallelujah!!!!

If you're OK with it, I'll just take screenshots of the graphs you've both provided and use those to present the information. Is that OK?

I've understood most of what you both have written. The one thing I'm not totally clear on is what you mean by sensor fusion failure. I'm assuming that sensor fusion is the process of fusing or joining together the information from the IMU, compass and GPS so the that drone can then respond accordingly. Is that correct or is it something else? Also, which lines in that report indicate sensor fusion failure, please?

I'm tired of the nonsense that DJI have kept coming back with, so I want to see justice done. I'm asking for a total refund due to equipment malfunctions and repeated gimble drops that have ruined many of my videos.

Do you know anyone in Melbourne, Australia, who might be willing to assist me?

 

[sar104]

Thanks, sar104. I'm just wanting to be armed and ready so that DJI can't catch me off guard at the tribunal or confuse me because I'm new to drones. It only costs me $63 to take them to the tribunal and at the tribunal it's the judge that decides whose right, not DJI - hallelujah!!!!

If you're OK with it, I'll just take screenshots of the graphs you've both provided and use those to present the information. Is that OK?

I've understood most of what you both have written. The one thing I'm not totally clear on is what you mean by sensor fusion failure. I'm assuming that sensor fusion is the process of fusing or joining together the information from the IMU, compass and GPS so the that drone can then respond accordingly. Is that correct or is it something else? Also, which lines in that report indicate sensor fusion failure, please?

I'm tired of the nonsense that DJI have kept coming back with, so I want to see justice done. I'm asking for a total refund due to equipment malfunctions and repeated gimble drops that have ruined many of my videos.

Do you know anyone in Melbourne, Australia, who might be willing to assist me?

Correct - sensor fusion is the algorithm (typically using a Kalman filter) that uses slow, absolute data, in this case compass yaw values, to correct the IMU yaw value that is derived from fast, differential, rate gyro data that suffers from gradual drift. When the disagreement between the compass and the rate-gyro-computed yaw becomes too large to be due to drift, and corrected by the fusion algorithm - that is sensor fusion failure. In the event log stream that I included in post #7 you will see entries such as:

378.300 : 33403 [L-FDI][CTRL]: fault on , height_ctrl_fail​

378.317 : 33404 [L-RC]craft ctrl failed!!!​

379.238 : 33458 [L-FDI]NS(0) FUSION(1): fault on , magn_heading_err_large​

380.041 : 33505 [L-RC]craft ctrl failed!!!​

These correspond to the intervals in the data where the magnetic yaw and the IMU yaw diverge significantly.

Feel free to use anything that I've posted as you need.

 

[briano216]

This was not a wind speed issue - winds were 10 - 15 out of the southwest - it all goes wrong at around 436 seconds when the mode is changed to "Go Home". If you compare the GPS location with the location computed by integration of the IMU recorded velocities north and east, the position values agree well up to that point. But when the aircraft attempts align yaw for RTH the IMU completely loses track of heading and the position data diverge.

View attachment 45292

After that you have an aircraft in uncontrolled flight, apart from two brief periods of ATTI mode when it successfully stabilized pitch and roll. If it had stayed in ATTI it would have been flyable but in attempting stay in P-GPS (or Sport) the FC had no chance.

This was not compass interference at startup since the initial period of flight was fine - it is clearly some kind of IMU or compass problem leading to fusion failure. I would say it is an obvious warranty replacement case.

Hi sar104

I've got my case against DJI at VCAT (Victorian Consumer Affairs Tribunal) next Monday and am just preparing my presentation. This graph you have provided is really helpful, thanks. In case they ask me from which data it was compiled, would I be correct in assuming that the IMU data comes from the DAT file and the GPS data from the TXT file?

 

[sar104]

Hi sar104

I've got my case against DJI at VCAT (Victorian Consumer Affairs Tribunal) next Monday and am just preparing my presentation. This graph you have provided is really helpful, thanks. In case they ask me from which data it was compiled, would I be correct in assuming that the IMU data comes from the DAT file and the GPS data from the TXT file?

The data are in both files but those calculations were from the txt log - you hadn't posted the DAT file at that point. The GPS data are simply the recorded position which, even though the aircraft is using sensor fusion, is simply the GPS coordinates. The IMU location is computed separately by time-integrating the IMU velocity data, which is sensor fusion data. Those two are virtually identical if everything is working as it should, but yaw errors result in velocity errors and the two values diverge. I've found it to be one of the more sensitive tests of sensor fusion function. This graph shows the computed location from both IMUs. IMU_0 was the active IMU:



Note that the two IMUs disagree significantly with each other, as well as with the GPS data. IMU_0, which is active, is closer to reality but still offset.

Looking again at the DAT data, the two IMUs also start to disagree on pitch and roll at exactly the time that the inertial data go bad, which will be one of the reasons that even the magnetic yaw data become unreliable:







If you need any other supporting information then just let me know.

 

[briano216]

The data are in both files but those calculations were from the txt log - you hadn't posted the DAT file at that point. The GPS data are simply the recorded position which, even though the aircraft is using sensor fusion, is simply the GPS coordinates. The IMU location is computed separately by time-integrating the IMU velocity data, which is sensor fusion data. Those two are virtually identical if everything is working as it should, but yaw errors result in velocity errors and the two values diverge. I've found it to be one of the more sensitive tests of sensor fusion function. This graph shows the computed location from both IMUs. IMU_0 was the active IMU:

View attachment 54274

Note that the two IMUs disagree significantly with each other, as well as with the GPS data. IMU_0, which is active, is closer to reality but still offset.

Looking again at the DAT data, the two IMUs also start to disagree on pitch and roll at exactly the time that the inertial data go bad, which will be one of the reasons that even the magnetic yaw data become unreliable:

View attachment 54275

View attachment 54276

View attachment 54277

If you need any other supporting information then just let me know.

Hi sar104

Thanks very much for the very clear description of what sensor fusion failure is and for the graphs - they'll be very helpful!

I noticed that the x-axis of the first graph in the above post had the label Time (s). I'm assuming that was meant to be Distance East (m). Are the x-axis labels on the last 3 graphs correct - that is, Time (s)? Just wanting to make sure my data is water-tight when I present it.

Also, with the last graph showing IMU_0 Magnetic and IMU_1 Magnetic, is that showing what the IMUs worked out was the yaw occurring?

If I win this case, I'll have you to thank. You've been so helpful!!!!!!!!!!!

 

[sar104]

Hi sar104

Thanks very much for the very clear description of what sensor fusion failure is and for the graphs - they'll be very helpful!

I noticed that the x-axis of the first graph in the above post had the label Time (s). I'm assuming that was meant to be Distance East (m). Are the x-axis labels on the last 3 graphs correct - that is, Time (s)? Just wanting to make sure my data is water-tight when I present it.

Also, with the last graph showing IMU_0 Magnetic and IMU_1 Magnetic, is that showing what the IMUs worked out was the yaw occurring?

If I win this case, I'll have you to thank. You've been so helpful!!!!!!!!!!!

Good catch on the axis typo - fixed. The others are correct. The last graph shows the magnetic yaw value computed by the two IMUs from the raw compass data. There's only one compass, and so the differences in the results are entirely due to the different pitch and roll being computed by the two IMUs. Obviously those should be the same - the fact that they are not is compelling evidence that there was a serious IMU problem going on.

 

[briano216]

Hi sar104 and BudWalker

I had my VCAT case today (it was to be December 3 but got adjourned to today) in which I claimed a full refund for my Mavic Air due to 1) the IMUs malfunctioning, leading to sensor fusion failure, and 2) repeated instances of gimbal drop. Thanks to all the extremely helpful information you gave me, I won the case and will be fully refunded!!!!!!!

Thanks so much for your help!!!!!!

 

[Bazza]

Congratulations briano216, your perseverance has been rewarded. Excellent support from the forum, especially sar104 and BudWalker.
Great result all around.

 

[briano216]

Good catch on the axis typo - fixed. The others are correct. The last graph shows the magnetic yaw value computed by the two IMUs from the raw compass data. There's only one compass, and so the differences in the results are entirely due to the different pitch and roll being computed by the two IMUs. Obviously those should be the same - the fact that they are not is compelling evidence that there was a serious IMU problem going on.

Hi sar104

I realised you probably wouldn't see my above message becasue I didn't send it in a reply so here it is now. I had my VCAT case on Wednesday (it was to be December 3 but got adjourned to January 9) in which I claimed a full refund for my Mavic Air due to 1) the IMUs malfunctioning, leading to sensor fusion failure, and 2) repeated instances of gimbal drop. Thanks to all the extremely helpful information you gave me, I won the case and will be fully refunded!!!!!!!

Thanks so much for your help!!!!!!

 

[briano216]

Congratulations briano216, your perseverance has been rewarded. Excellent support from the forum, especially sar104 and BudWalker.
Great result all around.

Thanks. Yes, sar104 and BudWalker were very helpful. Initially it was just me trying to get justice and I may not have persisted alone, but when I got their feedback it gave me confidence that what I believed was right and so I pressed on.

 

[sar104]

Hi sar104

I realised you probably wouldn't see my above message becasue I didn't send it in a reply so here it is now. I had my VCAT case on Wednesday (it was to be December 3 but got adjourned to January 9) in which I claimed a full refund for my Mavic Air due to 1) the IMUs malfunctioning, leading to sensor fusion failure, and 2) repeated instances of gimbal drop. Thanks to all the extremely helpful information you gave me, I won the case and will be fully refunded!!!!!!!

Thanks so much for your help!!!!!!

That's excellent news, and was clearly the correct decision in this case. It's unfortunate that you had to go to those lengths - DJI generally seems quite reasonable and often refunds in far less clear-cut cases.