Compass error results to nonGPS

ekto · Apr 6, 2018

I've had Mavic Pro for couple of weeks. I've used it about two hours. From the beginning there has been something off with the compass. It doesn't fly straight, and it complains about compass errors on some flights. Sometimes it works fine. I have paid special attention to calibration, no metal objects, live in a middle of nowhere in the country side so no metal objects, nothing in pockets, no controller near by, etc. Calibrating have not helped.

Story

I have made two successful DroneDeploy automatic flights. Today I tried it again. Drone went up, went to first waypoint, but then it gave beeps and the RC said "check app". And sure enough it had lost compass. I pressed RTH, but nothing happen. And I've tested the RTH three times, I know to press long. No beeps, no nothing.

The drone was moving several meters a second, it was keeping the same speed and direction. It was already about 50 meters out, and I was losing sight of it. I did have the camera view, but it was pointing downwards, and the gimball did not response. When I pulled the left stick down, I did notice from the video view that it went downwards, but kept moving at same direction and speed.

This point I had lose sight of it. I then pulled it up and listened the sound of motors. I now had a good guess where it was. Then I moved the right stick in several direction and tried to listen where it was going. And then I was finally able to see it. And in that point I realized that it was the wind that was moving it. With the right stick and visual ques, I did get it to fly towards me, but it was also rotating at the same time, so it was hard. But I I did get it safely back.

Analysis

So I googled around, found a way to get the DAT-file, and installed DatCon and CsvView programs. The problem was with the compass. But what struck me was that the GPS drop off. Looking trough logs, it had 12 - 14 satellites and the LAT, LON, Height data is all there. And I also found from the TXT log, that it had recorded the home position, and it was correct. The log states next in the point where everyting went south:

67.102 : 7868 [L-FDI]ns req:fdi,0to0,reason:fusion.gps_yaw_err,result:fail for same index
67.765 : 7901 [L-FLYMODE][Ctrl<1>] REQ_RC_NORMAL ATTI_HOLD ctrl_gps_atti

Here is the CSV and the LOG, if someone want's to take a look:
Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-06_19-40-24.FLY046.csv
Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-06_19-40-24.FLY046.log.txt

Conclusions

So if you experience problems with compass, the one component that is most likely to get interference, you lose GPS hold and RTH. I had luck, since I heard where it was. And I had something like 10 hours of experience flying and cheap nonGPS drone, so I did know how the get it back even when it was facing the wrong way and rotating.

Question

1. How can I be sure that the problem is with the compass? And not some magic field, over where I live?

2. If the thing has good satellite positioning, and the compass has trouble, why would it ever drop of the GPS? The one thing that it could use to return home.

sar104 · Apr 6, 2018

ekto said:
I've had Mavic Pro for couple of weeks. I've used it about two hours. From the beginning there has been something off with the compass. It doesn't fly straight, and it complains about compass errors on some flights. Sometimes it works fine. I have paid special attention to calibration, no metal objects, live in a middle of nowhere in the country side so no metal objects, nothing in pockets, no controller near by, etc. Calibrating have not helped.

Story

I have made two successful DroneDeploy automatic flights. Today I tried it again. Drone went up, went to first waypoint, but then it gave beeps and the RC said "check app". And sure enough it had lost compass. I pressed RTH, but nothing happen. And I've tested the RTH three times, I know to press long. No beeps, no nothing.

The drone was moving several meters a second, it was keeping the same speed and direction. It was already about 50 meters out, and I was losing sight of it. I did have the camera view, but it was pointing downwards, and the gimball did not response. When I pulled the left stick down, I did notice from the video view that it went downwards, but kept moving at same direction and speed.

This point I had lose sight of it. I then pulled it up and listened the sound of motors. I now had a good guess where it was. Then I moved the right stick in several direction and tried to listen where it was going. And then I was finally able to see it. And in that point I realized that it was the wind that was moving it. With the right stick and visual ques, I did get it to fly towards me, but it was also rotating at the same time, so it was hard. But I I did get it safely back.

Analysis

So I googled around, found a way to get the DAT-file, and installed DatCon and CsvView programs. The problem was with the compass. But what struck me was that the GPS drop off. Looking trough logs, it had 12 - 14 satellites and the LAT, LON, Height data is all there. And I also found from the TXT log, that it had recorded the home position, and it was correct. The log states next in the point where everyting went south:

67.102 : 7868 [L-FDI]ns req:fdi,0to0,reason:fusion.gps_yaw_err,result:fail for same index
67.765 : 7901 [L-FLYMODE][Ctrl<1>] REQ_RC_NORMAL ATTI_HOLD ctrl_gps_atti

Here is the CSV and the LOG, if someone want's to take a look:
Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-06_19-40-24.FLY046.csv
Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-06_19-40-24.FLY046.log.txt

Conclusions

So if you experience problems with compass, the one component that is most likely to get interference, you lose GPS hold and RTH. I had luck, since I heard where it was. And I had something like 10 hours of experience flying and cheap nonGPS drone, so I did know how the get it back even when it was facing the wrong way and rotating.

Question

1. How can I be sure that the problem is with the compass? And not some magic field, over where I live?

2. If the thing has good satellite positioning, and the compass has trouble, why would it ever drop of the GPS? The one thing that it could use to return home.

Without yet having looked at the DAT file data, I can answer your question about the effect of the compass error (fusion.gps_yaw_err) and why it then ignores the GPS location data.

The compass error arises when the IMU rate gyro data (primary yaw diagnostic) disagree with the magnetometer data to such an extent that the sensor fusion scheme is unable to reconcile them. At that point the FC is programmed to conclude that it cannot have any confidence in its yaw (heading). So even though it still knows exactly where it is and in which direction it is moving relative to the earth, from GPS, it has no idea in which direction, relative to the aircraft, to apply thrust to move in any given direction or hold position against drift. Its only viable option at that point is ATTI mode, in which it simply holds the aircraft level and maintains altitude.

As for what caused the problem - standby.

sar104 · Apr 6, 2018

I just realized that you only posted a processed CSV file of the DAT data, which only contains a subset of the data. I need the original DAT file, as will others here.

ekto · Apr 6, 2018

I tried to update the first post to include the DAT, but Forum-software thinks it's spam. Here's the link:
Dropbox - FLY046.DAT

It could actually try to move to different directions, and calculate from the responses, witch way it is, and how to return home. It could do this inside a 5 - 10 meter circle.

sar104 · Apr 6, 2018

I haven't checked the full DAT file yet, but it appears, from the csv file data, that you have a compass calibration issue, an IMU calibration issue, a bad compass or a bad. Have you done an IMU calibration?

The IMU yaw initializes, as expected, to the compass heading, and neither change during the initial ascent to 63 m. That suggests that there was no magnetic distortion at the takeoff point. However, when the first yaw maneuver occurs at 60 s then the magnetic yaw and IMU yaw disagree. That triggers GPS health to go to zero. GPS health is really a misnomer - it is more an indication of the confidence in ability to navigate. The reason is not clear - I'll need to look at some of the raw data in the full DAT file to see if it is possible to determine.

sar104 · Apr 6, 2018

ekto said:
I tried to update the first post to include the DAT, but Forum-software thinks it's spam. Here's the link:
Dropbox - FLY046.DAT

It could actually try to move to different directions, and calculate from the responses, witch way it is, and how to return home. It could do this inside a 5 - 10 meter circle.

Trial and error navigation is possible in theory. It would require an entirely new flight algorithm however.

ekto · Apr 7, 2018

sar104 said:
I haven't checked the full DAT file yet, but it appears, from the csv file data, that you have a compass calibration issue, an IMU calibration issue, a bad compass or a bad. Have you done an IMU calibration?

The IMU yaw initializes, as expected, to the compass heading, and neither change during the initial ascent to 63 m. That suggests that there was no magnetic distortion at the takeoff point. However, when the first yaw maneuver occurs at 60 s then the magnetic yaw and IMU yaw disagree. That triggers GPS health to go to zero. GPS health is really a misnomer - it is more an indication of the confidence in ability to navigate. The reason is not clear - I'll need to look at some of the raw data in the full DAT file to see if it is possible to determine.

View attachment 35221

The drone went up and navigated to the first waypoint. Then it turned around and that’s when everything failed. It just happened to be oriented in a such way, that it was pointing to first waypoint while ascending, so there were no turning right after it reach set altitude. Or so I remember.

IMU has been calibrated, but I did it inside, over a wooden table. I was careful and watched an instruction video first.

ekto · Apr 7, 2018

sar104 said:
Trial and error navigation is possible in theory. It would require an entirely new flight algorithm however.

If we go some years back, most phones and other handheld navigation devices did not have compasses. If you were in a new city, you sometimes had to just walk to a direction, and see how that translates to the map device. Then you could figure your heading and understand which way you need to go.

Let’s say there would be a compass error, and the GPS had lock, and the MC had many meters of altitude. When RH would be initialised, the drone would enter this iterative process and would determine heading. Then it would keep the heading using gyros, something even cheap drones can do, and move only using the right stick. While moving, it could compare it's intended and experienced direction, and correct for wind and rotation.

This could be an advanced option. And DJI could step out from any responsibilities if you turn this on, explaining how the drone would be moving with out collision checking and compass.

ekto · Apr 8, 2018

So I did a new flight today. I was at my friends house, about 100km east from mine. I calibrated the compass and went off. I only did a short fly around to test the compass. I was going to do a DroneDeploy flight, but the flimsy iPhone cable that comes with the RC, it kept braking the connection.

The drone did the thing where when it slows down, it starts to wonder off to the left. It has done it multiple times before. When I looked the logs, there is one good straight flight, and the next one is not. Here's the logs: Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-08_14-02-42.FLY053.zip

I made a short video of my analysis, so you can just watch that.

Enable CC to see what I wrote

Is the behavior normal or not? Is there some other data I should look at? The text log did not have any entries during that time.

BudWalker · Apr 8, 2018

ekto said:
So I did a new flight today. I was at my friends house, about 100km east from mine. I calibrated the compass and went off. I only did a short fly around to test the compass. I was going to do a DroneDeploy flight, but the flimsy iPhone cable that comes with the RC, it kept braking the connection.

The drone did the thing where when it slows down, it starts to wonder off to the left. It has done it multiple times before. When I looked the logs, there is one good straight flight, and the next one is not. Here's the logs: Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-08_14-02-42.FLY053.zip

I made a short video of my analysis, so you can just watch that.

Enable CC to see what I wrote

Is the behavior normal or not? Is there some other data I should look at? The text log did not have any entries during that time.

I'll try to look at this today. But, I have 3 questions.
1. Where is the LikeX10 button?
2. Seems that you're using a more recent FW version. How did you get the .DAT?
3. Can I use your YouTube on CsvView Introduction

ekto · Apr 8, 2018

BudWalker said:
I'll try to look at this today. But, I have 3 questions.
1. Where is the LikeX10 button?
2. Seems that you're using a more recent FW version. How did you get the .DAT?
3. Can I use your YouTube on CsvView Introduction

I use the DJI assistant 2. I can download flight data when my drone is connected to my PC with usb cable. I extract the DAT with DatCon, and then view it using CsvView. And you can freely use the video, I’ll update the video license later today to free use.

BudWalker · Apr 8, 2018

ekto said:
I use the DJI assistant 2. I can download flight data when my drone is connected to my PC with usb cable. I extract the DAT with DatCon, and then view it using CsvView. And you can freely use the video, I’ll update the video license later today to free use.

You can also submit the .DAT to CsvView directly; i.e. you don't need to use DatCon to create a .csv.

BudWalker · Apr 8, 2018

ekto said:
So I did a new flight today. I was at my friends house, about 100km east from mine. I calibrated the compass and went off. I only did a short fly around to test the compass. I was going to do a DroneDeploy flight, but the flimsy iPhone cable that comes with the RC, it kept braking the connection.

The drone did the thing where when it slows down, it starts to wonder off to the left. It has done it multiple times before. When I looked the logs, there is one good straight flight, and the next one is not. Here's the logs: Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-08_14-02-42.FLY053.zip

I made a short video of my analysis, so you can just watch that.

Enable CC to see what I wrote

Is the behavior normal or not? Is there some other data I should look at? The text log did not have any entries during that time.

I sent you a PM asking for some additional info.

ekto · Apr 8, 2018

I made some more tests, it's all on the video:

Put captions on.

Here's that cropped CSV: Dropbox - 165 - 185.csv
And here is the whole DAT: Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-08_18-49-49.DAT

Could someone verify that their drone does not do that type of moves? Or is it normal?

And if you care to look all the different DAT-files sent, would you advice contacting DJI for servicing? Is there any solid data that says that some part is broken?

BudWalker · Apr 8, 2018

I looked at FLY043. What happened here was quite common about 9 months ago. This is the first I've seen since then. I had assumed there was a FW change that fixed this. Briefly, an abrupt pitch/roll change and/or flying close to the geoMagnetic poles seems to make a Mavic susceptible to this type of problem.

I agree with everything @sar104 said about this flight. I.e., there was a magYaw/Yaw separation which then caused the gpsHealth to drop to 0 followed by a switch to ATTI. Yaw depends on IMU data; e.g. by integrating the gyro data, etc. MagYaw is derived from just the magnetometer data followed by a correction for pitch and roll. They are computed differently but they should agree. When they don't agree it's an indication that Yaw can't be trusted. This is usually followed by declaring a compass error and/or a switch to ATTI.

But, looking at the underlying data there is no apparent reason for the magYaw/Yaw separation. There is a change in magYaw when there is no actual heading change. I noticed some situations where this seems to happen but could never develop a compelling theory. I tried a couple of ideas to predict when this would happen. This often occurs immediately following an abrupt pitch and/or roll change. That would suggest that roll and pitch values aren't always precise. But, I was never able to reliably predict the erroneous magYaw/Yaw separation.

There seems to be some correlation with the higher (and lower) latitudes where the geoMagnetic inclination is higher. This would make some sense because the range of values seen by the X and Y axis magnetometers will be smaller compared to a location further away from the magnetic poles. Therefore, the magYaw error bounds will be higher closer to the magnetic poles. E.g., if the Mavic were sitting at a pole the magYaw error bound would be a full 360° (effectively unbounded). To test this theory I used an interval arithmetic approach to compute the magYaw error bounds. But, here again I couldn't reliably predict the erroneous magYaw/Yaw separation.

Maybe, it's just a tough problem and a combination of things can cause the erroneous magYaw/Yaw separation.

One thing I noticed is that the next flight FLY053.DAT you did a compass calibration before the flight. And, there were no erroneous magYaw/Yaw separations significant enough to cause the gpsHealth to drop to 0 and/or a switch to ATTI. Maybe that helped but I suspect you've done a compass calibrartion several times and the problem persists.

I'm still looking at FLY053

ekto · Apr 9, 2018

I just noticed that the dropbox upload was not complete. Now the latest DAT is there. In that full DAT, there are two cases where it drops to ATTI. So this is after my latest calibration. What comes to my norden location, there are hundreds of drone pilots in Finland, some live in the artic circle. I did not find anything unusual about Finlands location and using drones. GPS can sometimes get shadowed, but this was not the case here.

There is this one taller hill near where I live. It's 200 meters from the last test position. But it's more to the east, so it doesn't block satellites. But could it have affect to the compass, who knows. I imported the CSV-file to QGIS and was able to produce some map views. The drone is flying around 80 meters, the ground beneath is at 70 meters.

What I'll do is that I'll calibrate the IMU and other calibratable items, and go to a seperate, open field location. This way we can rule out my location. But that odd drift to the left, this has happend on any location.

ekto · Apr 9, 2018

I did investigate this magnetic theory a bit more. I found an aeromagnetic anomaly dataset for Finland, and process it on QGIS. I don't know how much these should affect Mavic's compass, but atleast the next test site can be selected to rule out any of these infulenses.

There seems to be something nearby. And when you look at the larger image, it looks like there is something larger going trough the test site.

BudWalker · Apr 9, 2018

ekto said:
So I did a new flight today. I was at my friends house, about 100km east from mine. I calibrated the compass and went off. I only did a short fly around to test the compass. I was going to do a DroneDeploy flight, but the flimsy iPhone cable that comes with the RC, it kept braking the connection.

The drone did the thing where when it slows down, it starts to wonder off to the left. It has done it multiple times before. When I looked the logs, there is one good straight flight, and the next one is not. Here's the logs: Dropbox - DJI_ASSISTANT_EXPORT_FILE_2018-04-08_14-02-42.FLY053.zip

I made a short video of my analysis, so you can just watch that.

Enable CC to see what I wrote

Is the behavior normal or not? Is there some other data I should look at? The text log did not have any entries during that time.

Maybe I'm missing it but I don't see much wrong with the first anomaly you described. In the YouTube at videoTime 46 secs (flightTime 63 secs) you make the comment that the Mavic isn't flying straight. Looks OK to me. There is a slight curvature at the beginning of the path back which is otherwise straight. The slight curvature is due to the fact that there was some overlap between the rudder commanded rotation and the elevator command.

The second anomaly is a little more interesting. Maybe @sar104 can work his magic on this. The incident occurred in the interval [72 , 74] while the AC was slowing down. It did veer to the left but there were no control inputs.

=====>

But, more interesting is the toilet bowling that happens right after this. In my experience this always means the FC is confused. But, I don't see any indications of this in the underlying data. Maybe @sar104 can work some of his magic on this.

I'll look at the next .DAT but first a couple of questions. 1) What app do you use to do the screen recordings? 2) Are you aware that you can get a GoogleMap key that will allow you to see the GM images in the GeoPlayer? Maybe the process of getting a key looks to be too much of a hassle?

sar104 · Apr 9, 2018

BudWalker said:
Maybe I'm missing it but I don't see much wrong with the first anomaly you described. In the YouTube at videoTime 46 secs (flightTime 63 secs) you make the comment that the Mavic isn't flying straight. Looks OK to me. There is a slight curvature at the beginning of the path back which is otherwise straight. The slight curvature is due to the fact that there was some overlap between the rudder commanded rotation and the elevator command.
View attachment 35410
View attachment 35411

The second anomaly is a little more interesting. Maybe @sar104 can work his magic on this. The incident occurred in the interval [72 , 74] while the AC was slowing down. It did veer to the left but there were no control inputs.
View attachment 35413 =====>View attachment 35412
But, more interesting is the toilet bowling that happens right after this. In my experience this always means the FC is confused. But, I don't see any indications of this in the underlying data. Maybe @sar104 can work some of his magic on this.

I'll look at the next .DAT but first a couple of questions. 1) What app do you use to do the screen recordings? 2) Are you aware that you can get a GoogleMap key that will allow you to see the GM images in the GeoPlayer? Maybe the process of getting a key looks to be too much of a hassle?