You would need to check the flight log to see what was actually going on there - it sounds as if something else was happening.
Compass error demonstration
- Thread starter sar104
- Start date
You would need to check the flight log to see what was actually going on there - it sounds as if something else was happening.
g36pilot
Well-Known Member
My M2P's logs have no evidence of a Compass Error but numerous Compass Interference warnings that correspond with flight record timeline. One that one flight I'm thinking there was an anomaly in either the upload or record conversion. This was confirmed by uploading the records to Phantomhelp Log Viewer. No Compass Error was found.
May I know how does the M2 detect "Magnetic interference" ? Obviously the craft has no way to know where the correct north is . Does it detect the magnetic dip ?
Are you asking about the process by which it resets the yaw after takeoff to fix an incorrectly initialized yaw, or how it knows when to warn of magnetic interference?
That's when the measured magnetic field components fall outside a programmed threshold. Specifically it appears to be out of the range 1400 - 1600 on the Mavic 2:
Compass error demonstration
Pressing pause won't do anything in ATTI mode. Wow..i just know it..never used it before..i thought it do same trick in atti mode..thanks for enlight me up bro.
mavicpilots.com
I did an experiment with my Mini today on a beach where magnetic field distortion should be absent :
1) stick a small magnet to the nose of the craft to distort the local magnetic field before turning on the craft. The purpose is to create a yaw initilization error of about 110 degrees
2) remove the magnet after yaw initialization is completed ( video image shows up in the FLY app )
3) check on the map of the FLY app that the compass error stays ( arrow of the craft pointing to a very wrong direction )
4) move the craft to another position by hand ( motor off all the way )
5) check the compass error again on the FLY app.
Result : As long as the craft did not change in position, the error would stay but once the craft was moved, the error was reduced to zero in about 28 seconds. It appears that the flight controller is constantly checking whether the magnetic field is credible base on changes in GPS coordinates and make corrections along the way.
I have tried the same test indoor ( no GPS ) and the compass error stayed after the craft has been moved around.
I have repeated the test at another outdoor location. This time I have captured the screen of the FLY app showing the self-compass correction in action . The jerkiness of the video is because the gimbal was totally destroyed in a recent crash caused by compass error .
1) stick a small magnet to the nose of the craft to distort the local magnetic field before turning on the craft. The purpose is to create a yaw initilization error of about 110 degrees
2) remove the magnet after yaw initialization is completed ( video image shows up in the FLY app )
3) check on the map of the FLY app that the compass error stays ( arrow of the craft pointing to a very wrong direction )
4) move the craft to another position by hand ( motor off all the way )
5) check the compass error again on the FLY app.
Result : As long as the craft did not change in position, the error would stay but once the craft was moved, the error was reduced to zero in about 28 seconds. It appears that the flight controller is constantly checking whether the magnetic field is credible base on changes in GPS coordinates and make corrections along the way.
I have tried the same test indoor ( no GPS ) and the compass error stayed after the craft has been moved around.
I have repeated the test at another outdoor location. This time I have captured the screen of the FLY app showing the self-compass correction in action . The jerkiness of the video is because the gimbal was totally destroyed in a recent crash caused by compass error .
Last edited:
The sensor fusion algorithm will slowly correct the yaw after the interference is removed. I doubt that it was actually using position data for that process though. How far did you move it?
I moved it for about 15 meters. I haven't tried it extensive enough but it seems that without GPS ( indoor ), such self-correction does not happen.
Really interesting. I'm quite surprised by these findings. There have been several incident analyses based on the scenario where Yaw is compromised at batteryOn and remains so after being moved to a different location.
At first glance I thought the correction started when the accelerometers and gyros sensed the MM being handled. The correction started when you picked it up at to move it 23 meters.
But, a correction didn't happen when you handled the MM to remove the magnet at 28.6 secs. Also, a correction didn't happen when the MM was moved at 34 secs.
Today I did another test with my Mini. I attached a magnet to it's nose before powering on and keep the magnet in place. Then I moved it around and see if it can still correct the yaw error when it has no chance to see the correct magnetic field of the earth.
Amazingly, the Mini can accurately correct the yaw all by itself even under constant magnetic interference but there has to be GPS signals and the craft has got the chance to move around to sense it's orientation relative to the GPS grid.
So far I have been moving the craft by my hands with the motors off. I am very tempted to see how it will behave if it is allowed to take off and fly with yaw error.
screen capture of the FLY app :
.DAT file :
Amazingly, the Mini can accurately correct the yaw all by itself even under constant magnetic interference but there has to be GPS signals and the craft has got the chance to move around to sense it's orientation relative to the GPS grid.
So far I have been moving the craft by my hands with the motors off. I am very tempted to see how it will behave if it is allowed to take off and fly with yaw error.
screen capture of the FLY app :
.DAT file :
Last edited:
Where is the LikeX10 button when you need it?!?
Seems pretty clear that the FC was using GPS data to help determine the correct Yaw value. There is plenty of evidence that Yaw will be corrected by magYaw. But, in this case the FC seems to ignore magYaw and use the GPS data instead. I'll speculate that's because compassError was true.
Also, the correction seems to have started when the FC thought the MM had taken off at time 249 secs.
from the eventLog
249.398 : 12207 [L-TAKEOFF]alti: -15.346804 tors: -11.499166
BTW, I was trying to extend your previous findings but ran into a bit of a snag. I was trying to cause a Yaw/magYaw separation but without causing a compassError. A compassError gets triggered when the geoMagnetic field strength is outside the acceptable range. I was using a 4 inch steel rod to distort the filed. The overall field strength should be same since I wasn't using a magnet. So it should be possible to find a location for the steel rod where there was a Yaw/magYaw separation but no compassError.
I couldn't make that happen. I also found that once the compassError was triggered by moving the steel rod close, and then removing the steel rod didn't make the compassError go away. I'm thinking that the range for triggering a compassError must be wider than the range for un-triggering the compassError.
It does appear to be using GPS data, but that alone doesn't allow it to correct the yaw. GPS gives its movement in the earth FOR, but not the aircraft FOR, which it would need to estimate yaw. I wondered if perhaps it was using the IMU accelerometer data to estimate velocity in the aircraft FOR, but the noise appears to be too large - even with quite careful correction I cannot get meaningful aircraft FOR velocities from the accelerometers.
That leaves one other option - the VPS system. It may be that the optical sensors are providing the other piece of data - namely that the aircraft is moving directly forwards (and later backwards). That, combined with the GPS velocity data, are enough for it to deduce yaw.
That hypothesis could be tested by repeating this experiment in darkness, so that the VPS system is unable to operate.
Yeah, I had assumed that it had to be the accelerometers and gyros providing the velocity data in the aircraft FOR. I suppose the only other possibility is the VIO data. But, there was no VIO data in this .DAT. Typically, the VIO data exists if there is an actual flight, or maybe it's if the motors are started.
I agree, a test with a disabled vision system is needed.
By the way - as I mentioned back in post #60 it is possible to fool the compass without triggering a compass error, at least with the M2.
I tried that and a few other approaches. I'm thinking it's time for plan B - just gotta determine what plan B is...
I noticed in the test that when there is no GPS, the "Compass calibration required" message would not show up. Once a GPS fix is obtained, the message would appear. I have the feeling that it was checking whether the magnetic dip angle is within the range expected for the location to determine whether the magnetic field is credible.
It's quite possible that it checks the magnetic inclination, but the file that you posted the magnetic field strength was way out of spec, and that alone should trigger a warning:
Normal range, at least for the M2, is illustrated in the following graph from post #104:
Similar threads
DJI Drone Deals
New Threads
-
-
-
-
-
Downloading maps onto the RC2 is not working properly. anyone else?
- Started by MavicMike55
- Replies: 2
Forum statistics
