Wow..i just know it..never used it before..i thought it do same trick in atti mode..thanks for enlight me up bro.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.Pressing pause won't do anything in ATTI mode.
I was referring to the IMU_ATTI(0):Yaw-magYaw field. Thanks, all makes sense now.
Great read @sar104 , I have on my preflight checklist to go to Settings>Advanced Settings>Sensor State>Check IMU and Compass.
I've never had a disruption on my flights so no idea on how it looks when there a magnetic interference in place (other than expect a red line of some sort), would you be so kind to show us a screenshot of what it looks like when the magnet is near?
You didn't exactly say so but the green magnetometer interference range corresponds to the acceptable magMod range for the P3. And 1500 is the exact middle of that range. This makes it all the more likely that magnetic interference is just field strength.That was trickier to do than I expected since the magnetic interference level shown in the app doesn't appear to be recorded in the logs. I ended up having to synchronize a screen recording with the DAT file. Anyway, below is a graph showing the three orthogonal components of the magnetic field as detected by the magnetometers, as I manipulated the ambient magnetic field. The parameters displayed are the overall field strength, and the deduced magnetic yaw. Across the top is the compass status as shown in the app (example screens below), which can take the levels "Excellent" (green, 0 - 300), "Good" (yellow, 300 - 500), "Poor" (red, > 500) and "Abnormal" (unrelated to interference level). The aircraft was stationary and facing south (180°)
By inspection, at least in this test, it appears that the interference level is directly related to the magnetic field strength, with green being in the range 1200 - 1800 (unknown units) and zero interference at 1500.
View attachment 74309
Note that in the 150 - 160 seconds range the field strength is almost exactly nominal, and interference was in the green until something killed the solution and the aircraft reported abnormal compass data. It immediately went back to green when I removed the applied field.
Also note, for those of you who rely on the interference level to decide if there is magnetic interference, that for several periods the interference level was comfortably in the green but the measured yaw was significantly wrong - the same situation that I created in the previous flight test. You cannot rely on the interference level - the only reliable test is that the direction arrow is correctly aligned relative to north.
View attachment 74315
This is a green status with the value so small that you cannot see the color - I adjusted the applied field to give the aircraft an exactly nominal magnetic field strength (1500).
View attachment 74312
View attachment 74310
View attachment 74313
View attachment 74316
Abnormal compass data screen
You didn't exactly say so but the green magnetometer interference range corresponds to the acceptable magMod range for the P3. And 1500 is the exact middle of that range. This makes it all the more likely that magnetic interference is just field strength.
But, I'm curious about abnormal compass reading in the [150 - 160] secs interval. I was speculating that it was related to measured vs expected inclination.
When the compass is off its rockers and you are mid flight. the effect feels like the drone is attacked by a bird ad it goes to all directions wildly.
The controls are not resonding well either. To get the drone back and establish controll again:
Press the return home button, this will override the compass and the drone returns to normal flight and will return home, you can cancel the RTH and take manual control (which I prefer) to fly back.
if it happens again, perform the above steps again.
at least if you are into the more arcane aspects of flight control.
So what is the "safe" discrepancy then? Recently I noticed a read arrow difference of maybe 15 degrees from the actual drone direction, and having read enough crash stories here decided to move to another place (and did compass calibration for reasons I don't recall). That together aligned the arrow direction with the actual device direction, and the flight was successful, but the question still remains - is 5, 10 or 15 degrees ok or not really?No - I've never seen an aircraft recover from a 180° error, or even a 90° error for that matter. Much smaller discrepancies are sometimes resolved by the FC physically rotating the aircraft while keeping the IMU yaw value constant (i.e. ignoring the rate gyro data) until it agrees with the compass. Obviously it cannot do that while on the ground though.
So what is the "safe" discrepancy then? Recently I noticed a read arrow difference of maybe 15 degrees from the actual drone direction, and having read enough crash stories here decided to move to another place (and did compass calibration for reasons I don't recall). That together aligned the arrow direction with the actual device direction, and the flight was successful, but the question still remains - is 5, 10 or 15 degrees ok or not really?
Something i just noticed my landing pad has a metalWith compass errors arising from magnetic interference one of the major causes of problems, I thought it might be useful to show a controlled demonstration of how that works.
To recap, when the aircraft is powered up the compass (3-axis magnetometer) reading is used to initialized the IMU yaw value, after which the rate gyros are the primary source of rotation data that are used to update the IMU yaw value. The compass data are only used for low-gain (gradual) corrections for drift and bias in the rate gyro data. As a result, it's important that the IMU yaw is correctly initialized for the FC to know the direction that the aircraft is facing. If the yaw value is substantially incorrect then the FC will apply inappropriate corrections to try to hold position.
In this test, shown in the graph below, I used a small, rare-earth magnet to reverse the magnetic field at the M2P compass (it has only one), so that the compass measured the aircraft heading as north when it was really facing south. The magnet was just a few inches from the aircraft. On power up, the IMU yaw was incorrectly initialized at -46 seconds as approximately north, as expected. At -38 seconds I removed the magnet and, with the spurious magnetic field removed, the compass correctly changed to south. That would normally happen naturally as the aircraft took off and left the (small) area of magnetic interference.
At zero seconds I started the motors to generate a txt log file and establish which IMU was active. The txt OSD_yaw value is identical to the IMU1 yaw value, confirming IMU1 was active.
Note that although the compass and IMU yaw values disagree by around 180°, the IMU yaw value is held steady - that's because the rate gyros haven't detected any rotation. The aircraft reports a compass error but doesn't attempt to resolve the problem. At 33 seconds I rotated the aircraft to face north, as shown correctly by the compass. The rate gyros also detect the 180° rotation and, as a result change the yaw value by that amount to approximately south, even though it's now facing north.
View attachment 73554
As you might expect, this kind of discrepancy would cause serious problems in any of the P modes, such as P-GPS. If, for example, when the aircraft was facing south but the IMU yaw value was north, the aircraft started to drift south due to a north wind, the FC will attempt to bring it back north. But since the IMU thinks the aircraft is facing north, it will do that by applying forward thrust (negative pitch). Since the aircraft is really facing south, negative pitch will actually push it further south. The FC will respond with more negative pitch, leading to uncontrolled flight to the south.
I'm going to repeat this test with an actual takeoff, but that requires a large flat field so that I can switch the aircraft to ATTI mode once it starts to fly off without worrying about obstacles. I'll post the results of that later. In case anyone else is tempted to try this, do not attempt unless you have ATTI mode programmed as one of the mode switch positions for when the flight goes bad.
so has mine and every other folding spring type made,but it is fine wire and does not seem to effect the compass in the drone when you place it in the middle of the padSomething i just noticed my landing pad has a metal
Ring in it. Found it using a compass
Here's a screenshot of Compass Error experienced :07 after takeoff. This flight maxed out the ability to record the event. The job entailed two adjacent stack inspections with rooftop launches. Compass Interference was displayed on every roof launch. Compass calibrations were difficult to successfully perform w/so much metal nearby and did not remedy the Interference warning for takeoff. Interference warnings cleared with around 10' of altitude.At one particular spot also received Compass Error immediately followed by Compass Interference banners on the OSD approximately :07 into the flight. Flew in this condition for 4 minutes without any handling issues and finished the inspection. Exhaust stack steel and plant infrastructure most certainly caused the condition. Flight was two weeks ago with the latest firmware all around.Does anyone recall a Mavic 2 with a compass error? I've looked back over all the Mavic 2 events that I've examined from this forum, and I cannot find a single instance of a Mavic 2 exhibiting a compass error under any firmware version, so I suspect that this method was implemented right from the start. I wonder if that was also one of the reasons for going to a single compass. If that's the case then it is turning out to be a very robust solution to a relatively common problem.
Here's a screenshot of Compass Error experienced :07 after takeoff. This flight maxed out the ability to record the event. The job entailed two adjacent stack inspections with rooftop launches. Compass Interference was displayed on every roof launch. Compass calibrations were difficult to successfully perform w/so much metal nearby and did not remedy the Interference warning for takeoff. Interference warnings cleared with around 10' of altitude.At one particular spot also received Compass Error immediately followed by Compass Interference banners on the OSD approximately :07 into the flight. Flew in this condition for 4 minutes without any handling issues and finished the inspection. Exhaust stack steel and plant infrastructure most certainly caused the condition. Flight was two weeks ago with the latest firmware all around.
View attachment 74556
In the interest of accuracy in this thread I'm going to have to point out that this is incorrect. While the flight characteristics with significant compass and yaw errors can be a bit like that, pressing the RTH button has absolutely no effect, and does not override the compass. The flight problems are occurring because the FC is attempting to navigate or hold position based on an incorrect understanding of which direction it is facing, and instructing it to return home doesn't help. Furthermore, it would have to use the compass to return home anyway.
Controlled flight will only be restored if
I would not be surprised if all future models are programmed the same as the M2 on this issue, and it would be perfectly possible to change the firmware on older models to support IMU yaw reset after takeoff in the event of compass/IMU yaw disagreement.
- The FC resolves the compass error, which is what the tests reported here happens only with the Mavic 2, at least currently;
- The FC switches to ATTI mode, which often doesn't occur fast enough;
- The pilot manually selects ATTI mode.
We use essential cookies to make this site work, and optional cookies to enhance your experience.