Mavic 2 Pro Wild Ride....

[sar104]

This must be a MP2 thing. My MP1 never asks for a compass cal no matter how far I travel, unless I try to start it up near some metal; in which case, the warning goes away when I move it.

That's correct. It is a Mavic 2 thing.

 

[CrouchyUK]

Yes, I think in 14 months of ownership I only had to calibrate my MP1 2 or 3 times- and then I kinda knew it would as I suspected rebar under a concrete pad or something. MP2 seems a needier child. And then it flies off anyway.....

 

[sar104]

Yes, I think in 14 months of ownership I only had to calibrate my MP1 2 or 3 times- and then I kinda knew it would as I suspected rebar under a concrete pad or something. MP2 seems a needier child. And then it flies off anyway.....

Actually the M2 is far more robust from a magnetic interference perspective, because the FC can detect and correct for a magnetically distorted takeoff location - it resets the IMU yaw to match the magnetic yaw after takeoff. However, it seems to have an IMU quirk that sometimes leads to uncorrected problems with IMU1 - something that did not afflict the Mavic Pro.

 

[Gryphon962]

...
However, it seems to have an IMU quirk that sometimes leads to uncorrected problems with IMU1 - something that did not afflict the Mavic Pro.

I've asked Budwalker about this: none of the data we see from the MP1 has fields covering IMU(1) yet it almost certainly has a (1) as well as a (0).

 

[sar104]

I've asked Budwalker about this: none of the data we see from the MP1 has fields covering IMU(1) yet it almost certainly has a (1) as well as a (0).

Yes - I talked to him about that earlier this week. But whether it has two separate IMUs or not, the Mavic Pro didn't suffer from this particular issue.

 

[CrouchyUK]

Has anybody that knows about these things managed to get DJI to admit there may be a problem with the M2P- they must monitor YT and social media?

 

[sar104]

Has anybody that knows about these things managed to get DJI to admit there may be a problem with the M2P- they must monitor YT and social media?

That event was analyzed here:

90 + kph Mavic pro 2 flyaway

Hi All, A friend had a flyaway and the drone moved according to most of what we can determine over 90 KPH . DJI says wind gust . Which was on a day with surface winds about 10 KPH. Anybody able to help out here here is link to dat file it is big 2. + GB unless a txt may be better ...

mavicpilots.com

His explanation for the speed excursion is approximately correct. I hadn't heard the DJI explanation of a "miscalculation" in IMU1 due to processor overload, but that is one of the two hypotheses that I've discussed with @BudWalker.

@Rubistorm – it would have been useful if you had reported that outcome back here.

 

[CrouchyUK]

That event was analyzed here:

90 + kph Mavic pro 2 flyaway

Hi All, A friend had a flyaway and the drone moved according to most of what we can determine over 90 KPH . DJI says wind gust . Which was on a day with surface winds about 10 KPH. Anybody able to help out here here is link to dat file it is big 2. + GB unless a txt may be better ...

mavicpilots.com

His explanation for the speed excursion is approximately correct. I hadn't heard the DJI explanation of a "miscalculation" in IMU1 due to processor overload, but that is one of the two hypotheses that I've discussed with @BudWalker.

@Rubistorm – it would have been useful if you had reported that outcome back here.

I think yours and a few others input and help was mention in the YT comments, so I was aware it perhaps had been discussed on here. Thread mentions a "friend" so not sure on the communication trail- but yes I would hope that any assistance is acknowledged and feedback supplied- seems polite! I have now watched the previous 2 vids this guy put up and....

What struck me about this case is how similar it is from the pilots perspective it was to my own fly-away? Over water. Little or no wind. Low/no speed of the drone for an extended period before the incident. Even the doubt as to when the drone changed to RTH mode. I have read of theories that this is a computational/programming error- maybe when the drone is making little or no movements some calculation rounding gets out of hand? What surprises me is that DJI techs that look at the dat files cannot quickly say aha! They designed and programmed the blummin' thing....

What is SLIGHTLY encouraging is that he has so far had no repeat of this behaviour. I may get the confidence back to get mine back up in the air!

 

[sar104]

I think yours and a few others input and help was mention in the YT comments, so I was aware it perhaps had been discussed on here. Thread mentions a "friend" so not sure on the communication trail- but yes I would hope that any assistance is acknowledged and feedback supplied- seems polite! I have now watched the previous 2 vids this guy put up and....

What struck me about this case is how similar it is from the pilots perspective it was to my own fly-away? Over water. Little or no wind. Low/no speed of the drone for an extended period before the incident. Even the doubt as to when the drone changed to RTH mode. I have read of theories that this is a computational/programming error- maybe when the drone is making little or no movements some calculation rounding gets out of hand? What surprises me is that DJI techs that look at the dat files cannot quickly say aha! They designed and programmed the blummin' thing....

What is SLIGHTLY encouraging is that he has so far had no repeat of this behaviour. I may get the confidence back to get mine back up in the air!

There have now been several incidents looking just like this. The hypotheses were hardware failure on IMU1 or processor overload/failure. While DJI can be annoyingly inconsistent in their communications, I'm inclined to take their comments as confirmation that it is processor overload. What I still don't understand is why the FC doesn't switch to IMU0 in these cases, since it continues to perform normally, based on the DAT file data.

 

[BudWalker]

I've asked Budwalker about this: none of the data we see from the MP1 has fields covering IMU(1) yet it almost certainly has a (1) as well as a (0).

Now that I'm back in front of my usual compute environment I took a look. The Mavic 1 does indeed have two accelerometers and two gyroscopes. But, it's different than the Mavic 2, and Mavic Air.

If CsvView/DatCon is told to present the DatDefined fields

then the raw data for the two accelerometers and two gyroscopes will be extracted from the .DAT.
and

But, different from the Mavic 2 and Mavic Air, there is only one IMU record. I used a tool I developed for other purposes to look at my stash of Mavic 1 .DATs and all of them have just IMU(0). I suspect that, like the magnetometer data, that one of the two accelerometers and one of the two gyros are being used by the FC to populate the sensor data fields and computed fields in that IMU record. That's different from the Mavic 2 and Mavic Air where there are two IMU records. Maybe the Mavic 1 can switch accelerometers and gyros like it can switch magnetometers. I haven't checked this.

Or maybe the Mavic 1 FC first combines the two accelerometers and combines the two gyros and then uses those results for the computations that produce the other fields in the IMU record.

This line of investigation was started by @Gryphon962 's attempt to check the health of both IMUs on the Mavic. I gotta admit I was surprised to learn of the 2nd set of IMU sensors. So was @sar104. But, I'm starting to think that the problems with the IMU(1) for the Mavic 2 and Mavic Air are caused by a different set of FC algorithms being used for IMU(0) and IMU(1). It's not a HW issue.

 

[sar104]

Now that I'm back in front of my usual compute environment I took a look. The Mavic 1 does indeed have two accelerometers and two gyroscopes. But, it's different than the Mavic 2, and Mavic Air.

If CsvView/DatCon is told to present the DatDefined fields
View attachment 84137
then the raw data for the two accelerometers and two gyroscopes will be extracted from the .DAT.
View attachment 84138 and View attachment 84139

But, different from the Mavic 2 and Mavic Air, there is only one IMU record. I used a tool I developed for other purposes to look at my stash of Mavic 1 .DATs and all of them have just IMU(0). I suspect that, like the magnetometer data, that one of the two accelerometers and one of the two gyros are being used by the FC to populate the sensor data fields and computed fields in that IMU record. That's different from the Mavic 2 and Mavic Air where there are two IMU records. Maybe the Mavic 1 can switch accelerometers and gyros like it can switch magnetometers. I haven't checked this.

Or maybe the Mavic 1 FC first combines the two accelerometers and combines the two gyros and then uses those results for the computations that produce the other fields in the IMU record.

This line of investigation was started by @Gryphon962 's attempt to check the health of both IMUs on the Mavic. I gotta admit I was surprised to learn of the 2nd set of IMU sensors. So was @sar104. But, I'm starting to think that the problems with the IMU(1) for the Mavic 2 and Mavic Air are caused by a different set of FC algorithms being used for IMU(0) and IMU(1). It's not a HW issue.

Presumably it should be possible to compare the raw accelerometer and gyro data with the IMU data to see whether the MP FC is just using one source, or combining the two.

 

[CrouchyUK]

Well just to close out this incident I have now completed a further 3 flights with no problems at all- if a little nervous! Before the first flight I did a full IMU and compass calibration just to do “something” that might prevent another fly-away.

Thanks to all that responded and contributed- I certainly know a lot more about the M2P now- even if we might agree a definitive solution to these fly-always is still to be found....

 

[BudWalker]

Anybody still following this thread might want to take a look at
Incidents caused by an incorrect IMU(1):Yaw
where there is further analysis of this incident.