Performance of third-party compass/AHRS within BlueROV2?

Third Party Products Hardware
1

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:

AP_EXTERNAL_AHRS_VECTORNAV_ENABLED
AP_EXTERNAL_AHRS_MICROSTRAIN5_ENABLED
AP_EXTERNAL_AHRS_INERTIAL_LABS_ENABLED

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!

Zach

3 Likes
2

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

Regards,
Cody

3 Likes
3

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!
Zach

4

Hi Folks,

While I was flying the ROV, I captured compass data, showing the disagreement of the two compasses.

The ROV was barely moving at the time.

I know the log files are better, but but I don’t have them.

Any feedback from BlueRobotics on how to test or fix compass data would be appreciated.
e.g. is there a way to use compass learn by inputting Long Lat or do I need USBL?
And is compass learn the same as the MAGFit tool?

chrome_eYSVwruUt9
h

5

Any feedback from BlueRobotics on how to test or fix compass data would be appreciated.

I can’t speak for BR, but I have found that getting a good compass calibration is important and non-trivial. I have had the best luck doing calibrations in QGC on dry land far away from ferrous metal. In particular, getting the ROV to move through all poses makes for a better calibration.

I have tried magfit from log data a number of times and the results can be good or terrible. I suspect that the terrible calibrations stem from the lack of roll and pitch in the dataset… so the algorithm is overfitting. I suppose this can be improved by rolling and pitching the sub while flying, but I have not tried this.

is compass learn the same as the MAGFit tool?

It is a different tool, with different code. You start compass learn by setting the COMPASS_LEARN parameter to 3. You will need an EKF origin so that the software can look up the earth fields from a table and do 3d fusion of the mag fields in the EKF. (The fallback is 1d yaw fusion, which compass learn does not support.)

I have not tried compass learn. It may suffer from the same overfitting as magfit unless you roll and pitch the sub.

is there a way to use compass learn by inputting Long Lat or do I need USBL?

ArduSub 4.5 beta 2 has 2 new parameters: ORIGIN_LAT and ORIGIN_LON. You can set these to your start location. ArduSub will use these parameters (if non-zero) when the sub is armed and there is no origin from a GPS or USBL.

2 Likes
6

Thanks for the insights Clyde,

We do sometimes calibrate the Compass on a dockside, and I am always a little suspicious that steel under the concrete could be causing issues. I’ll try to calibrate at home.

Also great insight on ArduSub 4.5, I haven’t made the leap yet. Out of interest how do you find it? Have you come across any strange behaviour or has it been generally working as you expect?

Also to the Blue Robotics dev team, Blue OS new features are looking great. That compass view is very useful, it gives me a way to follow just the mags if I think EKF is getting heading wrong, and turn one the noisiest mag if there’s a difference. Great work!

1 Like
7

Re: ArduSub 4.5 BETA, we have been running it on 3 ROVs for some months now, and it is performing well. I don’t know of any regressions… if you find some, please report back!

The new SURFTRAK mode works well for low and slow surveys, but it needs to be configured to deal with sonar delays. We are using these settings for both the A50 DVL and the Ping1 rangefinders:

PSC_JERK_Z 8.0
PILOT_ACCEL_Z 500
# Results in KPa = 1.6 and KPv = 0.8, see AP_Math
2 Likes