Heading Drift with BlueROV2 and Water Linked DVL A50: Improve the Compass, EKF, or Use a FOG?

Build/Make
1

Hello everyone,

We are operating a BlueROV2 equipped with a Water Linked DVL A50. The flight controller is a Navigator running ArduSub.

We are experiencing a gradual difference between the ROV’s actual heading and its estimated heading. As the heading error increases, the position track recorded using the DVL also appears to rotate.

The main symptoms are:

  • The estimated heading gradually changes even when the ROV is pointing in a constant direction.

  • A heading offset remains after turning the vehicle.

  • The complete DVL position track rotates as the heading error increases.

  • The heading error may change depending on thruster output or vehicle operating conditions.

We are considering the following possible causes:

  1. Magnetic interference from the T200 thrusters, ESCs, or power wiring

  2. Accuracy or installation-environment limitations of the Navigator magnetometer

  3. Time-dependent drift caused by IMU gyro bias

  4. The way ArduSub’s EKF fuses magnetometer, gyro, and DVL data

  5. The handling of heading and coordinate data between the Water Linked DVL A50 and ArduSub

We would appreciate advice on the following questions:

  1. In this configuration, is the heading used to calculate the DVL position track derived from the Navigator magnetometer and ArduSub EKF, or does the DVL A50 perform any independent heading estimation?

  2. What settings or sensor values should we examine to determine whether the heading drift originates from the Navigator magnetometer, gyro, EKF, or DVL integration?

  3. Can ArduSub’s EKF settings be adjusted to improve the fusion or weighting of magnetometer and gyro data?

  4. Can DVL velocity data be used to correct or constrain heading drift from the gyro or magnetometer?

  5. If we replace the magnetometer or install an external one, are there any products with proven use on the BlueROV2?

  6. When using an external magnetometer, what separation distance from the thrusters, ESCs, and power wiring is generally recommended?

  7. For this problem, would it be more appropriate to improve the compass installation or to modify the EKF and DVL integration logic?

  8. Would a FOG (fiber-optic gyroscope) or higher-grade AHRS be an effective way to reduce reliance on the magnetic compass?

  9. Are there any specific FOG, AHRS, or heading-sensor products that have been successfully used with the BlueROV2 or ArduSub?

  10. Can a FOG or external AHRS be connected directly to the Navigator/ArduSub system, or would we need a separate companion computer running a custom EKF to fuse the DVL, FOG, and other sensor data?

Our goal is to determine whether the most practical solution is to replace or relocate the magnetometer, improve the EKF logic, or introduce a FOG-based heading sensor.

Thank you in advance for your advice.

2

Hi @FIN_TKG -

In answer to your questions:

  1. The A50 DVL does have its own heading and orientation sensors, by default they are not used by the ArduSub EKF. See this thread.
  2. Definitely calibrate your gyro with the vehicle on the bench on land, with it closed up and “warm” for best results. You can only do this from the Vehicle Setup page in BlueOS.
  3. See thread linked in #1.
  4. See thread linked in #1.
  5. I’m not aware of any IMUs that would provide better performance, other users have definitely tried some. This may also be helpful.
  6. Maximizing seperation distance is advisable, but it is very difficult to do in the context of the vehicle! Generally a good compass calibration is enough!
  7. To improve your position, generally another localization method is used in conjunction with a DVL - expecting perfect position with no drift from a DVL alone is unrealistic… The WaterLinked UGPS or Cerulean Sonar Omnitrack would fix the issue quickly!
  8. Yes, but good luck finding an affordable FOG that would fit, even in an external enclosure! A driver to integrate into ArduSub would also be necessary, this would likely require re-compiling the firmware…
  9. Not that I’m aware of, outside of what you might find on this forum via the search tool!
  10. A seprate companion computer seems unlikely to be necessary…

In general, relying solely on a DVL for position seems to be the issue to me - they are great for position hold and short term relative location tracking, but inherently will always have issues with position estiamtes as they only supply a velocity estimate that is integrated !