Ardusub 4.1.0 working with waterlinked uw gps?

[coanderson]

I’ll let this thread know what I hear back from waterlinked support. Thanks for your help!!

[coanderson]

Hi all! Update from my help ticket with Waterlinked Support (thanks Esten!)

"

Why your system sends a “1” and the Demo sends a “3”

When you connected to demo.waterlinked.com, the BlueOS extension has a specific line of code that detects the demo URL and automatically forces the MAVLink fix_type to 3.

However, when you use your own local Topside box, the extension pulls the fix_quality straight from your Garmin’s NMEA $GPGGA string.

1. In the NMEA protocol, a fix_quality of 1 means you have a valid, standard GPS fix.

2. The BlueOS extension mistakenly takes that NMEA 1 and assigns it directly to the MAVLink fix_type.

3. As you correctly read, in the MAVLink protocol, a fix_type of 1 specifically means “No Fix”.

Because ArduSub sees fix_type: 1, it interprets it as an invalid location and refuses to display the ROV in QGroundControl, regardless of the fact that your Garmin actually has a great lock with 12 satellites.

Solution 1: Edit the Python Script (Recommended)

To resolve this, we need to force the BlueOS extension to send ArduSub a 3 instead of a 1 when using your Garmin. The most straightforward and persistent way to do this is to make a quick edit to the extension’s Python script directly on your BlueROV.

1. Access your BlueOS web interface.

2. Open the File Browser (or connect via SSH).

3. Navigate to the extension’s files and open: blueos-ugps-extension/app/mavlink2resthelper.py

4. Scroll to around line 218. You will see this section:

   Python

           # use (onboard) GPS fixtype as default
           else:
               fix_type = global_locator_position['fix_quality']
   
   

5. Change that specific line to force a 3D fix (3):

   Python

           # use (onboard) GPS fixtype as default
           else:
               fix_type = 3
   
   

6. Save the file and restart the Water Linked UGPS extension from the BlueOS Extension Manager.

Solution 2: Pass the --ignore-gps argument (More Tricky)

The extension does actually have a built-in --ignore-gps command-line argument that handles this exact bug. However, applying it is quite tricky in this environment.

Because BlueOS runs extensions as background Docker containers managed entirely by the BlueOS Extension Manager, there is no simple GUI text box to pass custom arguments. If you prefer this route over editing the Python file, you would need to SSH into the ROV (or use the BlueOS Terminal), stop the extension via the manager, and manually spin up the Docker container via the command line with --ignore-gps appended to the execution command. The downside is that the BlueOS Extension Manager may flag the extension as “Offline” (since it didn’t start the container itself), and you will likely have to repeat this manual process whenever the ROV is rebooted.

Important Note for Bench-Testing

If you are testing the ROV on dry land where there is no acoustic fix, the extension will deliberately drop the fix_type to 0 because it detects the U1 locator is out of the water. If you want to bench test the map integration dry, you will need to manually pass the --ignore-acoustic argument (using the tricky Docker method above) or temporarily comment out the position_valid check just a few lines below the Python edit you made above.

Once this fix is applied, ArduSub will register a valid 3D lock from your Garmin, and your BlueROV should immediately pop up on the QGroundControl map!

"

[EliotBR (Eliot)]

@coanderson

6. Save the file and restart the Water Linked UGPS extension from the BlueOS Extension Manager.

Docker containers are started fresh from the underlying image, so this won’t work unless you docker commit the container to the image between applying your changes and restarting the container or your vehicle.

That said, the proposed code flaw does at least make some sense, so I’ve made a custom branch you can test that with if you’d like:

1. Disable the existing UGPS Extension
2. Click the + button to add a custom Extension
   • Extension Identifier: esalexander.wl-ugps
   • Extension Name: “WL UGPS fix test”
   • Docker image: esalexander/blueos-ugps-extension
   • Docker tag: external-GPS-test
   • Settings:

     {
       "NetworkMode": "host",
       "Env": [
         "UGPS_HOST=http://192.168.2.94",
         "MAVLINK_HOST=http://192.168.2.2:6040",
         "QGC_IP=192.168.2.1",
         "EXTRA_ARGS="
       ]
     }
     

Alternatively it may be possible to add ignore-gps to the EXTRA_ARGS in the settings, but I haven’t looked at the requirements for doing so.

@coanderson

If you are testing the ROV on dry land where there is no acoustic fix, the extension will deliberately drop the fix_type to 0 because it detects the U1 locator is out of the water.

Just confirming, you are testing with the sonar transducers in the water, right?

[coanderson]

Just confirming, you are testing with the sonar transducers in the water, right?

Yes

That said, the proposed code flaw does at least make some sense, so I’ve made a custom branch you can test that with if you’d like:

I wish I could test this now, but we’ve packed away our ROV to ship it for an upcoming deployment. Hoping everything will work after I change the WL UGPS python code when I get the system set up again. I will be sure to commit the changes via docker commit – I am assuming that I do this in the blueROV’s command line (correct me if I am wrong) – and ROV restart.

[tony-white]

Hi @coanderson -

Unfortunately I’m skeptical of their fix being relevant - it feels a bit like an AI hallucination response to me… Please let us know how it goes, and share .BIN logs from your deployment if possible.

[coanderson]

it feels a bit like an AI hallucination response to me…

Oh… awkward, and ugh! I hope it works. I’ll ask if they’ve solved this problem before

[coanderson]

It seems like they have confidence that this solution will work, as this (hardcoding fix_type=3) is how they get the demo.waterlinked page to feed gps positions that the ROV will trust. Sounds like they are going to update the extension to handle problems like this better in the future!

@Water Linked

I also double-checked the code, and it looks like the part you need to change is actually located around line 227 (not 218). The catch with applying this fix is that it basically tells the system you have a valid signal all the time, which might not always be true. (This is the same logic we use for our demo site). You might want to add a better validation check there for your own setup until we can release an official fix in the code.

While I can’t be 100% sure this will completely solve your integration issue—especially since we don’t currently have the exact equipment to test it ourselves—based on the data you provided and discussions with my colleagues, it should work.

[EliotBR (Eliot)]

@coanderson

Hoping everything will work after I change the WL UGPS python code when I get the system set up again. I will be sure to commit the changes via docker commit – I am assuming that I do this in the blueROV’s command line (correct me if I am wrong) – and ROV restart.

I would recommend installing and testing my modified version of the Extension rather than permanently adjusting your own version. That way you don’t end up with your supposedly normal one in a limbo state where it doesn’t actually correspond to a release.

Of course up to you if you’d prefer to adjust things yourself, particularly if my version fails to fix the issue for you

@Water Linked

The catch with applying this fix is that it basically tells the system you have a valid signal all the time, which might not always be true. … You might want to add a better validation check there for your own setup until we can release an official fix in the code.

The fix I’m proposing does a meaningful translation from NMEA to MAVLink for at least a few different fix types. Agreed that just blindly setting the fix type to a valid 3D fix is likely a bad idea.

[coanderson]

Thanks Eliot! Sorry, I never responded to your suggestion. I plan to try your branch out before the WL solution. Thank you so much for doing that! Unfortunately I won’t be able to test anything for another month and a half because our system is shipped out now