The dreaded compass error - two near identical flights - one with and one without - wondering what causes it

[Deleted member 94047]

Two flights from an identical take off spot and position yesterday. The first went without a hitch; in the second, the AC seems to have encountered a compass error. Looking at he logs, I see this in the DAT event stream

38.579 : 4485 [L-FDI]NS(0) FUSION(0): fault on , magn_heading_err_large
47.917 : 4953 [L-FDI][sensor_api_info] head(2,0,31,4).|
58.846 : 5500 [L-BATTERY]get_cell_voltage_callback_ack failed!||
63.656 : 5742 [L-FDI][FDI] ns atti(0) heading is outlier
63.656 : 5742 [L-FDI][FDI] ns atti(1) heading is outlier
63.674 : 5743 [L-FDI]NS(0) FUSION(0): fault on , disagree
63.674 : 5743 [L-FDI]NS(0) FUSION(1): fault on , disagree
63.674 : 5743 [L-FDI]fatal error: no ns with level < 4 !!!
63.875 : 5753 [L-FDI][sensor_api_info] head(2,0,31,4).|
65.230 : 5821 [L-FMU/LED]action changed. imu error:ns_abnormal(3)
67.983 : 5959 [L-FDI]NS(0) FUSION(0): fault off, disagree
67.983 : 5959 [L-FDI]NS(0) FUSION(1): fault off, disagree
68.023 : 5961 [L-FMU/LED]action changed. Normal Flash(0)
68.023 : 5961 [L-FMU/LED]type:0, normal flash action:
68.023 : 5961 [L-FMU/LED]c0:0,15;c1:0,3;c2:0,13;c3:2,3;c4:0,10;c5:0,3;c6:0,10;c7:0,3
71.373 : 6128 [L-NS][AHRS],qg obv buffer size[218/270]
71.373 : 6128 [L-NS][AHRS],pva obv buffer size[238/270]
73.189 : 6220 [L-FDI]NS(0) FUSION(0): fault off, magn_heading_err_large

Looking at the yaw v mag_yaw plots in CsView; this is the plot for the first flight

And here is the same graph for the second flight.


At one point during the second flight, yaw and mag_yaw were at complete opposites. Like I said, take off was from the same exact spot with a near identical initial heading for both flights as can be seen in these lines in the event stream log.

.020 : 10244 [L-IOC]Set CL. -90.4 Degree /first flight
.020 : 2552 [L-IOC]Set CL. -90.9 Degree /second flight

In the second flight, I noticed the AC was behaving strange soon after take off and I suspected this was a case of a compass error and rotated the AC a full 360 degrees and some more which seems to have fixed the issue. But I can't understand why the compass error occurred in one and didn't in the other.

Here are the DAT files for both if anyone wants to have a look.

 

[kndll]

Battery change between flights ? Sometimes a battery change can cause compass errors, usually due to a quick change and start up .

 

[Deleted member 94047]

Battery change between flights ? Sometimes a battery change can cause compass errors, usually due to a quick change and start up .

There was indeed a battery change and a quick start up. I haven't heard or read of this being a problem till now.

 

[kndll]

I've had it happen with my Phantom , it's rare , known as a hot swap battery problem , I've had compass errors for no reason at all and all it needed was to shut off , remove battery , reinstall battery and all is good .

 

[Deleted member 94047]

I've had it happen with my Phantom , it's rare , known as a hot swap battery problem , I've had compass errors for no reason at all and all it needed was to shut off , remove battery , reinstall battery and all is good .

First time I am hearing of this, thanks !

 

[sar104]

Two flights from an identical take off spot and position yesterday. The first went without a hitch; in the second, the AC seems to have encountered a compass error. Looking at he logs, I see this in the DAT event stream



Looking at the yaw v mag_yaw plots in CsView; this is the plot for the first flight
View attachment 89046
And here is the same graph for the second flight.

View attachment 89047
At one point during the second flight, yaw and mag_yaw were at complete opposites. Like I said, take off was from the same exact spot with a near identical initial heading for both flights as can be seen in these lines in the event stream log.


In the second flight, I noticed the AC was behaving strange soon after take off and I suspected this was a case of a compass error and rotated the AC a full 360 degrees and some more which seems to have fixed the issue. But I can't understand why the compass error occurred in one and didn't in the other.

Here are the DAT files for both if anyone wants to have a look.

This appears to have been an IMU computational error:



The rate gyros and magnetometers agree perfectly, but both the IMU0 and IMU1 fusion solutions are completely incorrect.

 

[Deleted member 94047]

Thanks sar. Any insights as to why?

 

[sar104]

Thanks sar. Any insights as to why?

@BudWalker and I have looked at a few logs where the sensor data all looked good but the IMU got it wrong. One hypothesis is just processor overload, but that's certainly not confirmed.

 

[Deleted member 94047]

Thanks, much appreciated.

 

[Capt KO]

So, if my drone doesn’t get a short nap between batteries it can have a brain (IMU) fart/hiccup? I get them regularly but not my birds, yet. Thanks for the warning though, always appreciated.

 

[Deleted member 94047]

So, if my drone doesn’t get a short nap between batteries it can have a brain (IMU) fart/hiccup? I get them regularly but not my birds, yet. Thanks for the warning though, always appreciated.

I am not sure the quick battery swap and subsequent takeoff is what caused the issue. But seeing that it is the only factor in play here, I guess we can assume it is? I don't know. I just bring whatever strange issues I encounter to the attention of the experts here; I am.like a test pilot in that regard

 

[sar104]

I am not sure the quick battery swap and subsequent takeoff is what caused the issue. But seeing that it is the only factor in play here, I guess we can assume it is? I don't know. I just bring whatever strange issues I encounter to the attention of the experts here; I am.like a test pilot in that regard

I would not make that assumption. Just because it is the only obvious factor doesn't mean that there were not other factors that we can't see.

 

[Deleted member 94047]

I would not make that assumption. Just because it is the only obvious factor doesn't mean that there were not other factors that we can't see.

I completely agree with you there. But may be giving the AC a short break of say 5 minutes is a good idea. But then again, I have on more than one occasion landed, swapped batteries, and taken off again very quickly - even quicker than I did in this flight (I swapped filters as well in this one) and I didn't have this issue. So yeah, I am just confused here.

 

[DanMan32]

Perhaps the delay is simply allowing the CPU to cool down where it can then operate at max speed. Many CPUs will slow down if they start to get too hot and perhaps that causes missed IMU data.

 

[Deleted member 94047]

Perhaps the delay is simply allowing the CPU to cool down where it can then operate at max speed. Many CPUs will slow down if they start to get too hot and perhaps that causes missed IMU data.

Perhaps, but we can't be certain about that. Like I said, I have made very quick successive flights before when shooting hyperlapses and have had no issues.

 

[BudWalker]

This appears to have been an IMU computational error:

View attachment 89107

The rate gyros and magnetometers agree perfectly, but both the IMU0 and IMU1 fusion solutions are completely incorrect.

The CCW rotation at 32 secs wasn't commanded via the control sticks. Also, the motor data shows the CCW rotation wasn't commanded by the FC. Is it possible that the Yaw fusion algorithm uses control stick data?

@Doppler do you have any idea why the MA rotated like it did?

 

[Deleted member 94047]

The CCW rotation at 32 secs wasn't commanded via the control sticks. Also, the motor data shows the CCW rotation wasn't commanded by the FC. Is it possible that the Yaw fusion algorithm uses control stick data?

@Doppler do you have any idea why the MA rotated like it did?

Sorry, i have no clue why. My eyes were on the mobile screen; I think I was ascending after a brief pause immediately after take off; and then I noticed the AC yawing to the left suddenly and violently. I interpreted it as a possible compass error issue and did a 180 or so rotation and then back. I left it to hover for a few seconds and after seeing that it was hovering fine, I continued with the flight and shot some pictures till the battery run low; came back and landed. I will attach a link to the video showing the sudden rotation - it is uploading at the moment.

Edit: The link is this: Streamable but the video won't be done uploading for a while; Sorry I have a very slow connection

 

[sar104]

The CCW rotation at 32 secs wasn't commanded via the control sticks. Also, the motor data shows the CCW rotation wasn't commanded by the FC. Is it possible that the Yaw fusion algorithm uses control stick data?

@Doppler do you have any idea why the MA rotated like it did?

It's interesting to look at the net motor angular velocity, which should correlate to rotation:



When the aircraft is stationary, the yaw maneuvers mostly correlate well with the net motor ω, less so during linear acceleration. Some don't though, including the 38 second CCW yaw, which occurred during an ω excursion in the wrong direction. That perhaps suggests an external influence.

 

[BudWalker]

It's interesting to look at the net motor angular velocity, which should correlate to rotation:

View attachment 89170

When the aircraft is stationary, the yaw maneuvers mostly correlate well with the net motor ω, less so during linear acceleration. Some don't though, including the 38 second CCW yaw, which occurred during an ω excursion in the wrong direction. That perhaps suggests an external influence.

Just to be clear. Isn't that 32 secs, not 38 secs?

 

[sar104]

Just to be clear. Isn't that 32 secs, not 38 secs?

Sorry - yes, 32 seconds.