Performance of third-party compass/AHRS within BlueROV2?

Hello Blue Robotics community,

I want to reach out and see if anyone has experience integrating an external compass/AHRS (via the COMPASS_EXTERNAL parameter or via AP_EXTERNAL_AHRS… parameters) into the electronics enclosure of a BlueROV2. If so, I’m especially interested in learning about performance, specifically with respect to potentially improving yaw readings. By way of background, I’ve searched through the forums and found related conversations here and here, with the latter more focused on integration, whereas I’m more curious about the performance of third-party compass/AHRS sensors.

For context, we’re working with @clyde who has been investigating (among other things) fusing data streams from WaterLinked’s UGPS system (USBL) and DVL-A50, as well as all IMU and compass sensors on the Navigator. Our hope is to eventually move towards autonomous ROV operations to increase the standardization and efficiency of our kelp forest ROV video surveys (landing page for that work is here on GitHub).

In particular, Clyde has been digging into the Navigator’s x2 compasses, and has learned a lot (see, e.g., here), including that the x2 compasses in the Navigator can easily get confused, and that the disagreement between the two compasses can lead to erroneous yaw behavior when fusing data and attempting autonomous missions. Without more consistently reliable yaw metrics, it seems autonomous ROV missions may face significant challenges.

In considering a third-party compass/AHRS upgrade, I see Advanced Navigation (we use their GNSS Satellite Compass to provide topside GPS and compass data for our USBL system) has a compass, dubbed Orientus, linked here. I see as well that Movella also has an AHRS linked here. Note that I don’t believe ArduSub has support for these devices.

However, within ArduPilot it looks like support exists for several external AHRS devices such as for devices from VectorNav, MicroStrain, and InertialLabs (links are to the company, not specific components) via the following parameters:


So, I wanted to put this question out to the BR community: has anyone integrated a third-party compass/AHRS into the electronic enclosure? If so, how did the device behave? Is there anything about its performance that can you share?

Thank you very much!



Hi Zach,

I was notified for this post since I was the author of that second post you linked. I actually ended up not using a higher quality IMU, but instead we added a waterlinked DVL and then I added a BMM150 magnetometer to an external enclosure which I mounted on the back of the vehicle using a 3D printed bracket. I have seen significant increases in yaw accuracy, the yaw angle was essentially unusable for me with the internal magnetometer. Things such as running a load test on my Jetson Nano inside the enclosure to running any of the thrusters would significantly skew the yaw angle readings and the onboard gyro is not accurate enough to maintain the proper heading during these disturbances. Using the compass_external parameter was very easy and worked exactly as described. If you have any specific tests you are interested in that would quantify the accuracy of the setup I have, let me know and I may be able to include them in my testing over the coming weeks



Thank you very much, @cmarq, for your response! Your solution is interesting, and it sounds like it could be implemented without too much fuss or $.

If you’re up for it, would you be willing to share an image of the enclosure with your magnetometer? And likewise, if you’re willing to share, we’d love to see a BIN dataflash file (accessible in BlueOS) from any given flight when the magnetometer is used. Using both the DVL and the magnetometer on the flight would be great, if possible. Any flight where you rotate the ROV such that the yaw metrics have something interesting to record.

Please feel free to DM me if you’d prefer.

Thank you!