DJI Mavic, Air and Mini Drones
Friendly, Helpful & Knowledgeable Community
Join Us Now

Mavic 2 Pro with a mind of it's own!

xagoras

Well-Known Member
Joined
Sep 23, 2018
Messages
53
Reactions
23
Location
Greece
Hi guys. Been a while since I posted here, mainly because I had a trouble free experience with my M2P so far. Until a couple of days ago.

So, I'm on a beach flying my first battery, getting some pics and checking some near by beaches from above. Flew right down to around 20% battery, pressed RTH, it came and landed exactly where it was supposed to.

At this point, I should mention that conditions were ideal. Hardly any wind blowing.

I pop in the 2nd battery and take off. This time I'm thinking I should take some cool videos of the area. At some point during the flight, around 1km away from me, I try to take some photos but nothing happens. Keep pressing the button, but it wouldn't make the characteristic sound. It simply faded for a couple of seconds and then went orange again. So I'm checking to see if the pictures were saved, but no.

I think OK, let's bring it back to check out what's going on. On the way back I spot a speed boat and decide to race it (haha, vanity, I know!). I bring the drone back and decide to have another try with taking some photos and videos now that it's nearby and I can check it if something goes south. Again nothing happens. It just wouldn't take the picture or record the video.

I decide it's time to land it and check what is going on. I press the RTH again and it starts the procedure. I check it from the camera and notice that while it was descending it starts to move away from the landing pad, picking up speed. I realise that it's going to crash on a nearby slope and try to flight it back manually. For a few really nerve breaking seconds it keeps fighting, refusing to obey and tries to go somewhere else. Finally I manage to bring it back in front of me and land it manually on the pad.

There was no warning prior to the incident. It just decided to go land somewhere else. I should mention that I was flying without a downloaded map of the area, in case it's relevant. I went through the settings later and the only thing noticeable was that the second bar on the gyroscope was orange in stead of green.

Any thoughts why this happened? Here's the link to the fight:

DJI Flight Log Viewer - PhantomHelp.com
 
Unless I'm reading the log incorrectly, it seems that it had 17 sats locked all the way.
 
Unless I'm reading the log incorrectly, it seems that it had 17 sats locked all the way.
There are some issues but loss of GPS was not one of them.
The real mystery is why did the auto-landing from RTH start going away at 18:11.9 when it reached altitude 60 ft?
It ended up 90 ft away from home before you started bringing it back.
I should mention that I was flying without a downloaded map of the area, in case it's relevant.
It's not relevant.
The map is just a convenience and has no effect on flying.
 
There are some issues but loss of GPS was not one of them.
The real mystery is why did the auto-landing from RTH start going away at 18:11.9 when it reached altitude 60 ft?
It ended up 90 ft away from home before you started bringing it back.

It's not relevant.
The map is just a convenience and has no effect on flying.
Exactly. I'm not sure if it's visible, but it started doing a continuous right-left movement at 18:14. That's when I realised it was way off the landing spot.
 
Today, I did a firmware refresh, and calibrated everything. I then did some controlled take offs and landings on my roof. Just a couple of meters up in the air, let it hover there for a while and then back down.

It seemed to behave OK.

I could understand the drifting issue if it was related to the IMU, but what about the refusal to take pictures and videos?
 
Today, I did a firmware refresh, and calibrated everything. I then did some controlled take offs and landings on my roof. Just a couple of meters up in the air, let it hover there for a while and then back down.

It seemed to behave OK.

I could understand the drifting issue if it was related to the IMU, but what about the refusal to take pictures and videos?
Now it is taking pictures and videos okay? I sometimes come back to this as an old and old time programmer - computers occasionally act up. The drone/controller/device all are computers of one type or another.
 
  • Like
Reactions: Thomas B
Now it is taking pictures and videos okay? I sometimes come back to this as an old and old time programmer - computers occasionally act up. The drone/controller/device all are computers of one type or another.

Yes. I did some more testing today and it seems to work OK.
 
  • Like
Reactions: Thomas B
I could understand the drifting issue if it was related to the IMU
According to the logs, there was an IMU positioning error at autoland. There were a few control inputs but the error is the cause of the drift away presumably.

IMU ERROR.png
 
  • Like
Reactions: BudWalker and ff22
According to the logs, there was an IMU positioning error at autoland. There were a few control inputs but the error is the cause of the drift away presumably.

View attachment 79909

So in plain English, I should assume that now that I calibrated the IMU, it should be fixed?
 
So in plain English, I should assume that now that I calibrated the IMU, it should be fixed?
Probably not. There have been a lot of similar incidents lately. A few have been attributed to hardware problems, but for many there has been no compelling determination of cause.

More could be learned if you provided a .DAT. The one you want is FLY077.DAT. The MP .DAT is best but it can be problematical to retrieve

The tablet .DAT is easier to retrieve and is almost as good as the MP .DAT
 
Last edited:
  • Like
Reactions: GadgetGuy
Probably not. There have been a lot of similar incidents lately. A few have been attributed to hardware problems, but for many there has been no compelling determination of cause.

More could be learned if you provided a .DAT. The one you want is FLY077.DAT. The MP .DAT is best but it can be problematical to retrieve

The tablet .DAT is easier to retrieve and is almost as good as the MP .DAT
Where should I upload it?
 
For some reason it only shows the flights after the 17th August on the Assistant 2 under ''Flight Data''. The only file related to the flight is under the ''FAM'' tab. Will that do?
 
Here's what I managed to get related to that flight and the one prior to it, in case there is something there that I didn't notice. It's the .DAT from the phone. Couldn't get the ones from the AC, except from that FAM tab that is also in the folder.

If you could take a look and shed some light, would be really appreciated.

 
Here's what I managed to get related to that flight and the one prior to it, in case there is something there that I didn't notice. It's the .DAT from the phone. Couldn't get the ones from the AC, except from that FAM tab that is also in the folder.

If you could take a look and shed some light, would be really appreciated.


The immediate cause of the uncontrolled flight was a yaw error:

1089.755 : 60258 [L-FDI]NS(0) FUSION(1): fault on , magn_heading_err_large

But the problem seems to have arisen because IMU(1) had stopped reporting at 745 seconds, and when it resumed at 1084 seconds, even though IMU(1) yaw was completely wrong, the FC switched at 189 seconds from IMU(0) to IMU(1) and ended up with a yaw error of around 150°:

yaw.png
 
The immediate cause of the uncontrolled flight was a yaw error:

1089.755 : 60258 [L-FDI]NS(0) FUSION(1): fault on , magn_heading_err_large

But the problem seems to have arisen because IMU(1) had stopped reporting at 745 seconds, and when it resumed at 1084 seconds, even though IMU(1) yaw was completely wrong, the FC switched at 189 seconds from IMU(0) to IMU(1) and ended up with a yaw error of around 150°:

View attachment 80193
This is all speculation but it looks to me that switching IMUs is a complicated business and takes a while before it's completed.

1) The switch from IMU(0) started at 1084 when the calcs for IMU(1) were resumed. At 1089 the actual switch took place. Presumably it took 5 secs for the calcs to stabilize.
1089.695 : 60255 [L-FDI][SWITCH] req:2,0->1,result:6,serr:7,derr:15
1089.695 : 60255 [L-IMU]
state: drift
1089.695 : 60255 [L-FMU/DM]Busy Device Changed. Type:imu1_ext_ns, <ID:7 idx:0-->ID:15 idx:1>, change ti
1089.755 : 60258 [L-FDI]NS(0) FUSION(1): fault on , magn_heading_err_large

2) The switch resulted in the Yaw error that wasn't fixed until 1098 secs
1098.178 : 60680 [L-FDI]NS(0) FUSION(1): fault off, magn_heading_err_large

The fly away occurred in that 9 sec window [1089, 1098] and made for some exciting flying.​
 
This is all speculation but it looks to me that switching IMUs is a complicated business and takes a while before it's completed.

1) The switch from IMU(0) started at 1084 when the calcs for IMU(1) were resumed. At 1089 the actual switch took place. Presumably it took 5 secs for the calcs to stabilize.
1089.695 : 60255 [L-FDI][SWITCH] req:2,0->1,result:6,serr:7,derr:15
1089.695 : 60255 [L-IMU]
state: drift
1089.695 : 60255 [L-FMU/DM]Busy Device Changed. Type:imu1_ext_ns, <ID:7 idx:0-->ID:15 idx:1>, change ti
1089.755 : 60258 [L-FDI]NS(0) FUSION(1): fault on , magn_heading_err_large

2) The switch resulted in the Yaw error that wasn't fixed until 1098 secs
1098.178 : 60680 [L-FDI]NS(0) FUSION(1): fault off, magn_heading_err_large

The fly away occurred in that 9 sec window [1089, 1098] and made for some exciting flying.


Completely agree with that speculation.​
 
I've got to say that now I'm more confused than I was before. Is this a hardware problem? If so should I be contacting DJI with a warranty claim?
 
Lycus Tech Mavic Air 3 Case

DJI Drone Deals

New Threads

Forum statistics

Threads
131,269
Messages
1,561,468
Members
160,221
Latest member
jroy329