# Compass "drift" and roll alignment **URL:** \ **Category:** BlueOS\ **Tags:** positioning\ **Created:** [July 7, 2025, 12:34pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862 "2025-07-07T12:34:48Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Erlingns95](https://avatars.discourse-cdn.com/v4/letter/e/f04885/32.png) [@Erlingns95](https://discuss.bluerobotics.com/u/Erlingns95)\ **Post date:** [July 7, 2025, 12:34pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/1 "2025-07-07T12:34:48Z")
Hey guys! We are having some trouble with our attitude indicators. The compass is currently living its own life, drifting off whenever it feels like it. Sometimes it looks like it has been swapped out with the “seconds hand” of a clock. Not reliable, and without pattern. The pitch/roll indicator seems to work “as it should”, but it is tilted (or rolled) 90deg ccw. Anyone know what can cause this? The electronics enclosure looks the same as yours does online, with the navigator “hanging” on a wall rather than laying on a floor. We have thought about rolling the entire enclosure, but that would really mess up our camera view. Any software solutions? Using “roll 90” or “roll 270” in the “mounting rotation” (BlueOS–\> Vehicle Setup–\> Configure–\>Compass) does not seem to work. ![Screenshot 2025-07-07 at 14.16.03](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/3/34ee130191a9d00e0062e9941d40a5002c8f6c1d.png) We calibrated the unit today. I am reading about some issues being caused by nearby metals or magnets during calibrations, so we will try recalibrating outdoors tomorrow. Also wondering about this “fitness mGauss” indicator we got after calibrating. Not quite sure what to do with this information, but it does not look good. See photo. ![Screenshot 2025-07-07 at 13.01.19](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/2/220bf484b32b263b4c9b8cf464a9ac8d683e85ff.png) Any input is greatly appreciated, as we feel quite lost without our sense of direction. -Erling Nilsen ---
**Author:** ![tony-white](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/tony-white/32/13297_2.png) [@tony-white](https://discuss.bluerobotics.com/u/tony-white)\ **Post date:** [July 7, 2025, 6:20pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/2 "2025-07-07T18:20:56Z")
Hi @Erlingns95 - From context, I would guess you’re dealing with a BlueROV2? What revision is it? Does it use a Navigator or Pixhawk? It seems you haven’t loaded the correct default parameters for the ROV, since the AHRS orientation is not properly set. It would also seem your compass calibration is poor, given the behavior you’re seeing. Performing the calibration again, outside if possible should help. You can also complete the Gyroscope calibration from within BlueOS via the vehicle setup menu, with the vehicle completely static on land and warmed up, and this may help the EKF stability considerably. Have you modified the vehicle, and potentially routed any power wires close to the autopilot? ---
**Author:** ![Erlingns95](https://avatars.discourse-cdn.com/v4/letter/e/f04885/32.png) [@Erlingns95](https://discuss.bluerobotics.com/u/Erlingns95)\ **Post date:** [July 7, 2025, 7:07pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/3 "2025-07-07T19:07:31Z")
Hey buddy, not surprised to see you here:P We are working with a custom BlueROV2. Built using an original electronics enclosure, 5x T500 thrusters for mobility, and an extra T500 for some super secret stuff. 1 00% garage-built frame. I’d like to say R4, but cannot confirm 100%. Using RPi4 under a Navigator. You’re probably on the right track when mentioning default parameters, I really didn’t give that much thought. We did not load any standard parameters, as our frame and build is not 100% fitting any of them. No unnecessary cables near the Navigator, only the ones supplying it and leaving the AUX outputs. ---
**Author:** ![tony-white](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/tony-white/32/13297_2.png) [@tony-white](https://discuss.bluerobotics.com/u/tony-white)\ **Post date:** [July 7, 2025, 7:42pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/4 "2025-07-07T19:42:46Z")
Hi @Erlingns95 - Loading the default parameters for the standard or heavy ROV, and then adjusting the frame type is your best bet. This will get a lot of the tuning values at least close to values that should work for your custom vehicle, and generally help with your setup process! ---
**Author:** ![Erlingns95](https://avatars.discourse-cdn.com/v4/letter/e/f04885/32.png) [@Erlingns95](https://discuss.bluerobotics.com/u/Erlingns95)\ **Post date:** [July 20, 2025, 8:12pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/5 "2025-07-20T20:12:52Z")
Not having the best of luck here. Tried what you suggested, but the calibrations are never “good”. Best we’ve gotten is 11 & 12mGauss (fitness), but the compass never stays stable. I’ve got some photos of some automatic adjustments that might mess it up for us: ![Screenshot 2025-07-20 at 22.07.15](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/1/1edb1620b1556c78d51c41a37480ddd013b20252.jpeg) EKF3 is an internal compass, right? The "in-flight yaw alignment seems to shoot the compass arrow in a close to random direction. Is there a way to “not use” this compass? For example just using the AK09915? ---
**Author:** ![tony-white](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/tony-white/32/13297_2.png) [@tony-white](https://discuss.bluerobotics.com/u/tony-white)\ **Post date:** [July 21, 2025, 4:18am UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/6 "2025-07-21T04:18:19Z")
Hi @Erlingns95 - I would guess that your custom ROV is routing power wires far too close to the Navigator / Pi. If it’s possible to share pictures, or generally adjust the routing, that may help! It is possible to disable a compass, and re-order their priority - this is all done in BlueOS on the Vehicle Setup / [Compass page](https://blueos.cloud/docs/latest/usage/advanced/#compass). Calibrating your Gyro there, with the unit perfectly still & warmed up, is also a good idea for heading performance. ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [July 21, 2025, 6:42am UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/7 "2025-07-21T06:42:56Z")
> [@Erlingns95](#): > > EKF3 is an internal compass, right? Nope, [it’s a sensor fusion and state estimation algorithm](https://ardupilot.org/sub/docs/common-apm-navigation-extended-kalman-filter-overview.html) - i.e. it takes in measurements from various different sensors, and tries to estimate as much as it can about the current state (position, orientation, and their dynamics) of the vehicle. Those state estimates are predicted at potentially higher frequencies (and with smoother variations) than the sensors are providing, and factor in the consistency between different sensors to estimate the health/uncertainty. A warning about a ground mag anomaly means the compass is behaving inconsistently with the other vehicle sensors, which could be from a poor calibration, but generally indicates it is operating near some magnetic force that is overpowering the global earth magnetic field, so the compass readings are nonsensical. That could be from a large metallic structure near where you’re operating, but (as @tony-white suggested) is also commonly caused by having power or motor wires problematically close to the autopilot, or ferro-magnetic objects like batteries. If need be it is possible to try to [compensate for motor current effects](https://ardupilot.org/sub/docs/common-magfit.html), but it is preferable to keep sensors away from strong sources of electromagnetic noise wherever possible. ---
**Author:** ![sietse](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/sietse/32/16062_2.png) [@sietse](https://discuss.bluerobotics.com/u/sietse)\ **Post date:** [May 13, 2026, 10:00am UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/8 "2026-05-13T10:00:32Z")
Hey all! Recently, we had an ROV come in that appeared to have some compass drift. While the vehicle was in Position Hold mode, it started drifting to the right even though there was no joystick input. We also noticed that the compass heading in Cockpit remained at the same angle, even while the ROV was physically rotating. I checked the log files and am trying to understand the difference between AHR2.Yaw and XKF[0].Yaw. From what I can see, there appears to be some yaw drift in AHR2.Yaw, while XKF[0].Yaw remains stable and does not seem to drift. ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/3X/d/3/d33fa7cd4c3665950e7d18544e97dcd045b7532f.png) I’m trying to better understand how these two values are related, and how this kind of drift could occur. I’ve attached the exact .bin file for reference. [00000045.zip](https://discuss.bluerobotics.com/uploads/short-url/876KYbxAIRolq4S6hJoHNhQT2RD.zip) (15.9 MB) Thanks in advance! ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [May 14, 2026, 12:58am UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/9 "2026-05-14T00:58:01Z")
Without having looked at the logs yet - was the gyroscope calibrated with the vehicle on stable ground? An incorrect gyroscope offset can cause attitude estimate drifting. ---
**Author:** ![sietse](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/sietse/32/16062_2.png) [@sietse](https://discuss.bluerobotics.com/u/sietse)\ **Post date:** [May 14, 2026, 1:22pm UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/10 "2026-05-14T13:22:59Z")
Yes it was calibrated on stable ground. Although I’m not too sure on how leveled our client’s surface has been ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [May 15, 2026, 6:04am UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/11 "2026-05-15T06:04:40Z")
> [@sietse](#): > > I’m not too sure on how leveled our client’s surface has been Just to clarify, that was specifically a [gyroscope calibration](https://blueos.cloud/docs/latest/usage/advanced/#gyroscope), not levelling the vehicle’s horizon? Levelness shouldn’t be important for that - just stability (e.g. “don’t calibrate the gyroscope while on a boat” kind of thing). The log looks like the vehicle was rotating the same direction pretty much the whole dive. Was that actually happening, or was that all drift? The Z axis gyro bias (`XKF0[1].GZ`) is also changing quite consistently through the log, which seems like the EKF is gradually attempting to correct for an incorrect calibration. It may be helpful to use Cockpit’s [EKF Status](https://blueos.cloud/cockpit/docs/latest/usage/advanced/#ekf-status) mini-widget to see if an estimate isn’t great during operation. ---
**Author:** ![sietse](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/sietse/32/16062_2.png) [@sietse](https://discuss.bluerobotics.com/u/sietse)\ **Post date:** [May 18, 2026, 6:52am UTC](https://discuss.bluerobotics.com/t/compass-drift-and-roll-alignment/20862/12 "2026-05-18T06:52:05Z")
> [@EliotBR](#): > > Just to clarify, that was specifically a [gyroscope calibration](https://blueos.cloud/docs/latest/usage/advanced/#gyroscope), not levelling the vehicle’s horizon? Yes I believe so! It was calibrated on fixed land, so it should be alright. > [@EliotBR](#): > > The log looks like the vehicle was rotating the same direction pretty much the whole dive. Was that actually happening, or was that all drift? The client stated that the vehicle indeed was physically roitating in one direction (counter direction from what the compass drift was in eg manual mode) in Position Hold, Depth Hold and Stabilize mode. > [@EliotBR](#): > > which seems like the EKF is gradually attempting to correct for an incorrect calibration. This seems like a fair point from what our client’s experiencing! I’ll get back to him to calibrate the ROV properly once more. Thanks!