Positioning error present with WaterLinked UGPS system

Third Party Products Sonar and Acoustics
, ,
1

Hello Blue Robotics community!

I’d like to reach out and start a conversation about the accuracy and consistency of coordinates recorded by ROV-mounted acoustic GPS tracking systems.

@m.williams and I have been using WaterLinked’s Underwater GPS system, 100m range, with the antenna and U1 locator for the past year or so as part of our ROV research conducting kelp forest surveys (you can learn more about our ongoing work here on the BR forums and here on GitHub).

To the best of my knowledge, we are using the hardware correctly. That is to say, we set the distance between the antenna and the topside GPS in the UGPS GUI (at 192.168.2.94), and we set the compass heading as well as the depth of the acoustic antenna (1m beneath the sea surface). The acoustic transmitter is mounted vertically on our BlueROV2 to maximize signal propagation. We typically operate on channel 5 (156 - 187 KHz). We’ve kept the topside hub’s software updated and currently run the latest 3.3.1 (400881892.d0af300). A network bridge enables coordinates to populate in our QGC .csv telemetry file.

There are two primary types of erroneous readings we experience with our UGPS system:

1. At times, the GPS location appears to oscillate between two attractors, with one being the correct position of the topside hub, and the other being just west of (in this example) . . . Africa (see the 1st image). These MASSIVE jumps in position have been observed both (1) with only the topside hub powered on (i.e., no U1 transmitter in the water), and also (2) with the U1 transmitter in the water.

2. Additionally, we appear to consistently have a large amount of error (or uncertainty?) associated with the ROV’s position (2nd & 3rd image). See the 2nd figure – these are the tracks from one of x4 ROV “transects”, where the ROV was flown straight (following a compass heading) for about 60m (the x4 transects are delineated by the x4 different colors in the 3rd figure). As you can see, what should be x4 approximately straight lines are x4 highly zig-zagged tracks. We plan to perform formal spatial analyses, thus accuracy in ROV position really does matter to us.

large_error
large_error1296×931 70.7 KB

60m_straight_transect
60m_straight_transect1318×1600 64.8 KB

x4_straight_transects
x4_straight_transects1150×1040 45.8 KB

Specific questions and points of consideration:

- Are these two (presumably distinct? but perhaps not . . . ) behaviors characteristic of UGPS system performance based on other people’s experience using the same hardware? Note that the error 2. is fairly consistent, whereas 1. is more sporadic and intermittent.

- I’m aware that additionally incorporating a DVL would likely improve the accuracy and precision of the ROV’s predicted position. This is an option we are considering.

- We consistently observe a fair amount of antenna movement in the water in response to swell, vessel movement, etc. – could slight variation in antenna positioning affect the predicted ROV position to the extent that it produces the error noted above the latter two figures above?

- Following the above point, we do have the x4 individual D1 receivers (an alternative to the antenna), and we’ll try those out on a vessel this week (May 15) to see if they improve performance.

- Have others obtained better performance from other GPS systems?

Note that we contacted WaterLinked May 8th about these issues, and we await a response.

Lastly, for what it’s worth, we’re working with several other entities within the state of Washington who are evaluating the potential of obtaining a BlueROV2 and customizing it just like ours (e.g., the Port of Seattle has already done this . . . they now have an identically customized BlueROV2). This is desirable, as the more eyes/cameras we have on the seafloor conducting benthic surveys, the better we can track population and ecological health and inform conservation and management. However, at this time I am uncertain whether or not to recommend the WaterLinked UGPS system to our collaborators, and we’re actively evaluating other systems such as the Cerulean ROV locator bundle Mark III.

Note too that we’re working closely with @clyde on this project – Clyde, please feel free to chime in with any of your observations and thoughts!

I know this was a long post, so thanks to all that made it through.

Zach

1 Like
2

Hi @zhrandell,

Sorry to hear you’re having issues with your system.

I haven’t personally used the Water Linked UGPS, but from what you’ve presented in your post:

  1. What software are you running on your vehicle?
    • In particular, which ArduSub version are you using, and are you using the old Companion Software or BlueOS with the UGPS Extension?
  2. The unexpected “attractor” position looks to be at/near (0,0) latitude, longitude, which is where many GPS system software issues end up
    • perhaps your system does not have the GPS origin specified (although that still wouldn’t explain the jumping between two main locations), or
    • maybe there’s some kind of issue with reported positions switching between a local and global reference (e.g. due to some bug in the integration software), and/or
    • maybe there’s a bug in ArduSub’s position input handling

The zigzags don’t seem like a problem that’s worth focusing on until there’s a stable and consistent reference, because if the uncertainty is huge due to the flip-flopping reference then it’s not surprising if the local positions show up with large amounts of drift.

1 Like
3

Hi!
Some additional tip.
Point 1, big jumping to Lat/Long 0/0
I would say this is due to Waterlinked built in GPS.
If you are stationary, put in the topside positional manually in Waterlinkeds UI.
If you are moving, ie in a boat, use a separate GPS compass to get correct position an heading to the system.
Point 2, smal local jumps.
When diving, check http://192.168.2.94/#/diagnostic
There, check signal levels, and system errors
Also when getting back to surface, check the U1 receivers green LED on top.
That should still be green.
Also, before launching ROV, wait to the green LED is on, could take minutes.

The closer you are to beeing on top of ROV, the better positioning.
Usually +/- 1 meter, with jumps +/- 5 meters more seldom.
The later you might get rid of by also using a DVL

2 Likes
4

There is a pretty good demo simulation online for Waterlinked UW GPS.
Here are som hints how the signals and settings should appear:
https://demo.waterlinked.com/#/diagnostic

5

Hello guys, thank you both for your responses! I’m sorry about the delay – I wasn’t on-site Tuesday and thus couldn’t check the software versions until today.

@EliotBR, we have two BlueROV2s:

• a R2 with Pixhawk running Companion Version 0.0.31, as well as ArduSub Version 4.1.1.
• a R4 with Navigator and BlueOS 1.1.0-beta 19 (7e8351bb), and Autopilot Firmware version 4.1.1 (BETA). Note that we used (in pirate mode) the blueos-ugps-extension v1.0.4.

The long jumps have most recently been observed on the R4 when using the relatively new blueos-ugps-extension.

The finer-scale error has been consistently exhibited by the R2 running Companion. We haven’t run the R4 enough times yet to determine whether it also regularly exhibits the fine-scale error.

Is there any information we could provide you all regarding the performance of the relatively new blueos-ugps-extension??

@Boko, I can confirm that all the LEDs are illuminated properly. We’ll take a close look at the diagnostic page when the run the ROV next week. I think what I’ll do next is screen-record the diagnostic page so that we can go back and review it against the recorded GPS tracks. When the ROV is in the water I can’t always tell whether or not the fine-scale error is being exhibited . . . it is most apparent when reviewing the GPS tracks afterwards.

6

I’ll second @Boko on this, but add that having a GPS compass (such as this) will likely solve both the large and small jumps. The internal GPS and IMU in the WaterLinked topside do not aid much/at all when the vessel is at sea and in motion, and the errors in the topside’s orientation propagate into large underwater positional errors exactly like what you have shown. We’ve also reinforced the UGPS antenna to make the whole system flex less, but unfortunately there is no way to account for pitch and roll.

The Waterlinked DVL A50 is a very useful addition (though its internal IMU also seems to drift almost instantly).

1 Like
7

Thank you, @AndyM!

I’m starting to get the sense that the WL UGPS by itself may not be sufficient to consistently produce tracks of the quality we desire, and that some combination of external GPS/compass information fed to the topside GPS hub, and/or a DVL, may be necessary.

For what it’s worth, we ran the ROV yesterday off of Pier 59, the main pier at the Seattle Aquarium, using the x4 D1 receivers (instead of the antenna). Note that the x4 receivers were affixed to a diver ramp that we can raise and lower via a davit. Unlike a vessel, the davit/ramp is quite stationary in the water . . . the tide floods and ebbs, but the davit/ramp remain motionless. Of course there may be some movement of the x4 receivers in the water, though we used 2lbs diver weights on each receiver to mitigate this as much as possible.

Per @Boko’s suggestion, I screen-recorded the UGPS diagnostics page during this dive, and as you’ll see, I occasionally flip to the position view in the UGPS GUI. We flew the ROV via QGC on a different screen, and I recorded that as well. Below you’ll see a roughly 10-min clip of both recordings that @m.williams was kind enough to synchronize and stitch together for us.

Several observations are apparent:

  • There are consistent short instances where the GPS position is invalid (see, e.g., 0:24, 0:40).
  • There are numerous short instances where the received acoustic signals drop significantly across the entire distance range (see, e.g., 0:29, 0:46).
  • The above two points often (but not exclusively) occur concurrently.
  • Note the uncertainty in position (starting at 07:23) that gives way to pretty wild fluctuations in the estimated position (07:47). I flip back-and-forth between the diagnostics page and the position view . . . what’s surprising is that the diagnostics screen seems to be reporting that “all is well” during these pretty wild oscillations.

Finally, there is one big qualifier I need to note about Pier 59 – the pier pilings are full of magnetic metal, and it always throws off the topside GPS hub’s compass (you can see the arrow in the UGPS GUI is consistently 90 degrees off). This is not the case when we have the system deployed on a vessel. BUT, I want to emphasize that we see similar erroneous behavior in the diagnostic screen when the UGPS system is deployed on a vessel.

Thanks, all, for any insight you may have about the above observations from the diagnostic screen.

Zach

8

07:47 make me sad. I’m surprised to see such fluctuations on a stationary system. Did you try inputting the topside heading as a static value to rule out issues with the compass (‘WL GUI>Settings>Topside setup> Topside heading>Static’?). Switching the display to ‘Map position’ would also give the errors some more context (if connected to the internet).

Do you have the ability to measure sound velocity profiles? It is only possible to enter a single sound velocity in the ‘Settings’ tab (default 1475 m/s), but in stratified areas there’ll be a disparity in the speed of sound between where the locator is and where the topside receivers are, which would lead to positioning issues. We’ve definitely seen similar madness when operating near rivers and freshwater outflows.

Another potential issue with the Pier 59 set up is the seabed itself getting in the way- e.g. if there is no ‘line of sight’ between the locator and the receivers because the ROV is too far down slope. We’ve seen this when working on steep reefs- but then the error would be an invalid position rather than a 60m jump.

Andy

9

Good inputs from @AndyM !
Note that your map plotting without map is relative.
Ie acoustic SBL plotting only.
That means GPS position and heading is not used in that diagnostic plotting.
Rules out compass and positioning as problems for the jumpings on that plot.
You can increase the plotting time from 60 sec in the bottom part if you like.

Also you can make plotting of ROV and Masterbox positions as .GPX files if you like via Python

10

@EliotBR, @AndyM and @Boko huge thanks for the insights and support! This has been very helpful.

For our next dock test, we will do 2 things: (1) specify a static location and heading, and (2) log the acoustic data from the G2 and examine it. I think this will help us understand where the errors are coming from, and how we can change our operations to improve the results.

Beyond that, we are investigating the capabilities of the onboard sensors on the vessels we use, and we may install a GPS compass like the Simrad HS60 along with an Ethernet / NMEA 2000 gateway. This looks very promising, though it does seem to require some additional integration: we will need a program to receive heading and position information from the GPS compass via NMEA, and push this to the WL G2 /api/v1/external/master API. Perhaps this functionality will be added to the blueus-uspg-extension in the future.

Best,
Clyde

2 Likes
11

I expect Water Linked are more likely to see this suggestion / request if you submit it as an issue or PR on their UGPS extension repo. It might be worth linking to the BlueOS NMEA Injector source as a point of reference, since the feature sounds like it would be doing basically the same thing just with the Water Linked API as the output instead of MAVLink :slight_smile:

1 Like
12

One more thing to check in Waterlinked diagnostic/advanced:
Check that “input depth” is the same as in QGC
If not, something in BR does not send corrrect depth.