Hi!
Before trying update to 4.1.0 (with companion), is waterlinked uw gps integration supposed to work
with 4.1.0?
Bo
Hi @Boko,
Yes, it should work fine to use ArduSub 4.1 with the Water Linked UGPS, when using it with our Companion software 
There’s also now an extension available for it via the Extension Manager in the latest BlueOS beta image. We haven’t properly tested the extension yet though, so you’re welcome to try it out if you want to but we can’t yet guarantee it will work as expected (please let us know any issues if you do end up trying it!).
By the way, sorry for the delay on this - I asked about it at the time and then forgot to get back to you before I went away.
Hi @EliotBR
I can confirm that Ardusub 4.1.0 integration works with Waterlinked, using Companion.
As before, no setup needed, Companion just starts sending depth and catching position.
I am going to set up a separate BlueOS system next year to be able to test there.
Checking to get a grip of what should be done.
From my point of view there are two things that must be done with BlueOS:
-
Sending UWGPS position to sub for getting position in QGC etc.
Is this still by sending NMEA GGA (via UDP) to 192.168.2.2:27000 ?
Easy done with python on topside computer, using WL examples:
GitHub - waterlinked/examples: Water Linked Underwater GPS API examples -
Depth of ROV must be sent to Waterlinked UW GPS
There are examples on Waterlinkeds swagger site:
Waterlinked API - Swagger UI
(Or using Python examples linked above)
I guess this should be written in Python, running on BlueOS? (or better topside?)
How to get depth parameter from Pixhawk?
Are there any info to start from, maybee in Companion code for WL?
Hi @Boko
The UGPS extension is almost done. It’s at the point where all it requires now is testing (and possibly debugging).
Get in touch when you setup the BlueOS system, and hopefully we have everything working by then.
If anyone wants to give it a try, the v1.0.1 UGPS should work (and testing is VERY welcome).
Good working, thanks!
I have a preliminary setup missing hardware.
Is there a way to simulate depth and temp without BAR30 connected to Pixhawk?
Manually trying to offset “ground press****” is not allowed from QGC.
Log from BlueOS extension now:
starting
ensuring we get VFR_HUD at 5 Hz
getting http://host.docker.internal/mavlink2rest/mavlink/vehicles/1/components/1/messages/VFR_HUD/status/time/frequency
frequency for VFR_HUD is 2.4285714626312256
ensuring we get SCALED_PRESSURE2 at 1 Hz
getting http://host.docker.internal/mavlink2rest/mavlink/vehicles/1/components/1/messages/SCALED_PRESSURE2/status/time/frequency
frequency for SCALED_PRESSURE2 is 0
scanning for Water Linked underwater GPS...
Running
.
getting http://host.docker.internal/mavlink2rest/mavlink/vehicles/1/components/1/messages/VFR_HUD/message/alt
getting http://host.docker.internal/mavlink2rest/mavlink/vehicles/1/components/1/messages/SCALED_PRESSURE2/message/temperature
Error: could not convert string to float: b'None'
I don’t believe so, unless you simulate a Bar30 with a microcontroller or something that’s connected to the I2C port.
It may be possible to simulate depth by sending it via VISION_POSITION_ESTIMATE MAVLink messages or something, but that doesn’t help with how to provide the temperature which (as shown in your error message) the BlueOS UGPS extension currently tries to extract from the autopilot’s SCALED_PRESSURE2 output messages.
Now running a testsystem only for workshop tests of BlueOS.
As pressure/temperature sensor 2 I run a I2C BMP280
That might be the problem that is not easy solved?
No position in QGC from WL system
WL system get temp and depth from BlueOS
BlueOS waterlinked extension works, log is OK
I get temperature and depth in QGC, but I can not calibrate pressure in QGC “Sensor not connected”
Offseting pressure (depth) in QGC is possible, but do not show on display or to WL
Blue OS 1.1.0 -Beta 12
Ardusub 4.1.0
Pixhawk 1 mRo (2.4.6 bought from BlueRobotics 2017)
Raspberry 3B
I2C BMP280
ESC’s, servos etc as standard
BMP280 is not one of the registered water-type pressure sensors, so ArduSub won’t accept it as a valid source of depth.
Hi!
Now got a little erratic BR BAR30 running.
Values is drifting, might be good for testing on land.
This is for testing only, so no hurry!
My purpose is to help testing BlueOS WL GPS Extension.
Blue OS 1.1.0 -Beta 13
Ardusub 4.1.0
Pixhawk 1 mRo (2.4.6 bought from BlueRobotics 2017)
Raspberry 3B
BAR30
In QGC temperarature jumps between correct 22 deg C and minus ~100,
Correct temperature is always correct received in Waterlinked, not drifting.
Depth is drifting a bit from sensor, is offseted 100 meters in QGC (to always give positive depth),
In QGC showing from 30 to 150 meters,
In Waterlinked received depth is 0 meters.
Offseting depth (pressure sensor) in parameters effect QGC, but not depth in Waterlinked.
(Working with companion, offseting depth shows in Waterlinked.)
ROV heading correct received in Waterlinked
Done a lot of restarts, deleted and added extension again, no difference
Extension log says running correct
Position of ROV correct in Waterlinked
No position showing up in QGC
(Lots of “EKF IMU1 forced reset” specially when offseting depth, if that is related)
On land Waterlinked always report locator position as “not valid”, but WL system show locator postion.
With Companion positioning works on land with status “not valid”
Hi @williangalvani and @EliotBR ,
I want to integrate the UGPS with QGC. I am running BlueOS 1.1.0 and Ardusub 4.1.
I have installed the extension:
But its not showing on the side bar:
Is there any documentation I can read or procedure I can follow?
The UGPS is setup with A1 locator and G2 antenna with external GPS are working:
Which message in Mavlink JSON can I check to see if its already there?
Cheers,
E.
The current version of the UGPS extension does not have its own UI page, so does not create a listing in the sidebar.
We’ve updated the readme with some usage instructions:
Assuming the UGPS is detected and working (which should be visible in the extension logs), the extension sends GPS_INPUT MAVLink messages to the autopilot, and I believe the autopilot will likely send corresponding GPS_RAW_INT messages to the topside, as well as regular GLOBAL_POSITION_INT messages with its filtered position estimates.
Hi there, Courtney here, but you can also call me confused.
I’ve been having major communication issues between WL UGPS (with U1 locator) and the BlueROV. The extension appears to be working – I’ve checked the logs and get responses like this:
2026-04-22 20:14:24.826 | DEBUG | ugps_connection:get:30 - Request url: http://192.168.2.94/api/v1/config/generic
2026-04-22 20:14:24.849 | DEBUG | ugps_connection:get:35 - Got response: {"antenna_enabled":true,"channel":5016,"compass":"external","environment":"reflective","external_pps_enabled":false,"gps":"external","imu_vehicle_enabled":false,"locator_type":"u1","range_max_x":0,"range_max_y":0,"range_max_z":0,"range_min_x":0,"range_min_y":0,"search_direction":179,"search_radius":27,"search_sector":360,"speed_of_sound":1500,"static_lat":63.442877,"static_lon":10.428286,"static_orientation":340}
2026-04-22 20:14:24.852 | INFO | __main__:run:48 - Forwarding depth, temperature and orientation from mavlink to ugps
2026-04-22 20:14:24.852 | DEBUG | mavlink2resthelper:get:35 - Request url: http://192.168.2.2:6040/mavlink/vehicles/1/components/1/messages/VFR_HUD/message/alt
2026-04-22 20:14:24.864 | DEBUG | mavlink2resthelper:get:40 - Got response: 0.0
2026-04-22 20:14:24.865 | DEBUG | mavlink2resthelper:get:35 - Request url: http://192.168.2.2:6040/mavlink/vehicles/1/components/1/messages/SCALED_PRESSURE2/message/temperature
2026-04-22 20:14:24.881 | DEBUG | mavlink2resthelper:get:40 - Got response: 2468
2026-04-22 20:14:24.883 | DEBUG | ugps_connection:put:52 - Request url: http://192.168.2.94/api/v1/external/depth json: {'depth': -0.0, 'temp': 24.68}
2026-04-22 20:14:24.903 | DEBUG | ugps_connection:put:57 - Got response: OK
2026-04-22 20:14:24.905 | DEBUG | mavlink2resthelper:get:35 - Request url: http://192.168.2.2:6040/mavlink/vehicles/1/components/1/messages/VFR_HUD/message/heading
2026-04-22 20:14:24.920 | DEBUG | mavlink2resthelper:get:40 - Got response: 55
2026-04-22 20:14:24.922 | DEBUG | ugps_connection:put:52 - Request url: http://192.168.2.94/api/v1/external/orientation json: {'orientation': 55.0}
2026-04-22 20:14:24.943 | DEBUG | ugps_connection:put:57 - Got response: OK
2026-04-22 20:14:24.944 | INFO | __main__:run:59 - Forwarding locator position from ugps to mavlink
2026-04-22 20:14:24.945 | DEBUG | ugps_connection:get:30 - Request url: http://192.168.2.94/api/v1/position/global
2026-04-22 20:14:24.961 | DEBUG | ugps_connection:get:35 - Got response: {"cog":0,"fix_quality":1,"hdop":0.8,"lat":32.86992916190212,"lon":-117.25074200839762,"numsats":12,"orientation":54,"sog":0}
2026-04-22 20:14:24.964 | DEBUG | ugps_connection:get:30 - Request url: http://192.168.2.94/api/v1/position/acoustic/filtered
2026-04-22 20:14:24.987 | DEBUG | ugps_connection:get:35 - Got response: {"position_valid":true,"receiver_distance":[11.520000457763672,10.368000030517578,6.047999858856201,6.047999858856201],"receiver_nsd":[-76.12323760986328,-65.97297668457031,-60.82737350463867,-77.41699981689453],"receiver_rssi":[-57.60606384277344,-60.51320266723633,-56.258609771728516,-51.85335922241211],"receiver_valid":[1,1,1,1],"std":1.3742225170135498,"x":-2.7188186645507812,"y":1.2100889682769775,"z":7.199999809265137}
2026-04-22 20:14:24.989 | DEBUG | mavlink2resthelper:send_gps_input:228 - fix_type=1 from Topside GPS.
2026-04-22 20:14:24.990 | DEBUG | mavlink2resthelper:post:100 - Request url: http://192.168.2.2:6040/mavlink json: {'header': {'system_id': 1, 'component_id': 220, 'sequence': 0}, 'message': {'type': 'GPS_INPUT', 'time_usec': 0, 'time_week_ms': 0, 'lat': 328699291, 'lon': -1172507421, 'alt': 0.0, 'hdop': 0.8, 'vdop': 1.3742225170135498, 'vn': 0.0, 've': 0.0, 'vd': 0.0, 'speed_accuracy': 0.0, 'horiz_accuracy': 1.3742225170135498, 'vert_accuracy': 0.0, 'ignore_flags': {'bits': 185}, 'time_week': 0, 'gps_id': 0, 'fix_type': 1, 'satellites_visible': 12, 'yaw': 5400}}
2026-04-22 20:14:25.001 | DEBUG | mavlink2resthelper:post:105 - Got response: OK
2026-04-22 20:14:25.003 | INFO | __main__:run:69 - Forwarding topside position from upgs to qgc
2026-04-22 20:14:25.003 | DEBUG | ugps_connection:get:30 - Request url: http://192.168.2.94/api/v1/position/master
2026-04-22 20:14:25.020 | DEBUG | ugps_connection:get:35 - Got response: {"cog":0,"fix_quality":1,"hdop":0.8,"lat":32.86994666666667,"lon":-117.25075999999999,"numsats":12,"orientation":331.9,"sog":0}
2026-04-22 20:14:25.022 | DEBUG | qgc_connection:send_topside_position:86 - Sending UDP $GPGGA,201425.02,3252.197,N,11715.046,W,3,12,0.80,0,M,0,M,00,0000*7d
2026-04-22 20:14:25.024 | DEBUG | qgc_connection:send_topside_position:86 - Sending UDP $GPRMC,201425.02,A,3252.197,N,11715.046,W,0.0,331.90,220426,,,A*7e
2026-04-22 20:14:25.024 | DEBUG | qgc_connection:send_topside_position:86 - Sending UDP $GPVTG,0.0,T,,M,0.0,N,0.0,K,A*0d
However, cockpit still tells me it does not have a gps fix, even though it says there are 12 satellites available! In the log above, you’ll see it also says that my gps has 12 sats in view. How can some of the information be ported, but not all of it? (In the screenshots below I’ve just zoomed in on the middle bottom of cockpit dashboard)
More info: I do not see GPS_INPUT in mavlink messages, which I think is supposed to be there if I am using the WL extension? I am using the program found here ( ugps-nmea-go/README.md at master · waterlinked/ugps-nmea-go · GitHub ) to forward the GPS serial messages to the waterlinked topside. Here is a screenshot of my config file for the GPS program:
Could the issue be that the gps program and the WL extension are both forwarding UDP messages to the same address? I thought this could be the issue so I had the gps program send the resulting GPS NMEA string to a random IP instead of what I think is the BlueROV (192.168.2.2:27000), but still no GPS fix in cockpit.
Also, not sure if this is related or not, but my BlueROV can no longer connect to QGroundControl, not sure how to get that up and running again/if this could be part of the problem.
Could it be the GPS string format? Can the BlueROV/blueOS read this many decimal points? “-117.25075999999999”
I would very much appreciate any help on this! I’ve been struggling. Thanks.
BlueROVUGPS Setup.pdf (5.6 MB)
Hi @coanderson,
Heh, good one, though sorry to hear about the issues you’re having 
Could you share some more about the software versions you’re using, and ideally also a system log (from the cog at the bottom of the BlueOS sidebar)?
Per the comment just above yours, have you looked for GPS_RAW_INT and GLOBAL_POSITION_INT messages?
GPS_INPUT gets sent to the autopilot, so may not show up in other tracking.
The satellite visibility is just taken from the topside GPS, so isn’t a meaningful indicator of whether the autopilot is being sent relevant position measurements with sufficient consistency and frequency for it to trust its estimate.
Note also that Cockpit can currently only show the vehicle position (e.g. it does not yet ingest NMEA data directly, or display the control station position more generally), and that’s only when the autopilot is confident enough in those position estimates to send them (which requires a low level of jumpiness and reasonably high update frequency of the input position measurements).
In what sense? No connection at all (e.g. no video and no telemetry)? Is that happening while Cockpit is open, or QGC just never works now? Possibly a firewall or other network configuration issue related to UDP connections, though that would be unlikely if you’ve successfully used QGC on that device before and haven’t changed the network details since then.
BlueOS v1.4.3. QGC v4.2.8, Ardupilot v4.5.7
System log file here: https://drive.google.com/file/d/18lgp71tXw8LCIbBTfOuoCg0mikEk57Cj/view?usp=sharing
I have an no dice with the lat lon in these messages
You mean the waterlinked topside, correct? If so, doesn’t this imply that the waterlinked topside is indeed able to communicate with the bluerov (which is the problem I am having).
I am only seeking the vehicle position here. I believe that I have correctly set up the waterlinked topside (with external GPS setup) and I think that the WL extension is working correctly because I am getting lines like this one in the WL UGPS extension log:
2026-04-22 20:14:25.020 | DEBUG | ugps_connection:get:35 - Got response: {"cog":0,"fix_quality":1,"hdop":0.8,"lat":32.86994666666667,"lon":-117.25075999999999,"numsats":12,"orientation":331.9,"sog":0}
Which is just straight up Lat lon, not NMEA. So I am just confused why cockpit cannot read these lat lon values in order to show me a vehicle position on the map (and log lat lon in the .BIN files)
When I open QGC, while Cockpit is not open, the top bar is purple and says “Disconnected”. QGC is not working at all for me. Changing my firewall settings does not change anything regarding the connectivity of the ROV to QGC
Another note: Waterlinked states that you have to use a network bridge to get the bluerov and the topside to talk to eachother. I am using the IP switch so these are physically connected, avoiding the network bridge. I don’t have an IT degree, so I am figuring all this networking stuff as I go. If I have assumed anything that is wrong, lmk. I will send a message to waterlinked support as well to see if they have anything to try in mind.
Hi @coanderson
This is a common misconception. Cockpit (and QGC) don’t simply read in NMEA from your position sensor! The vehicle autopilot receives position data, and if it is confident enough to use it, communicates to the GCS its position.
As for your QGC issues, your computer IP is not configured to be 192.168.2.1- for some reason you have this set to .2.90 in your diagram? Cockpit does not require this to connect, but QGC does!
So we can check your Autopilot parameters, can you please share a .BIN file from one of your attempted dives?
Cockpit does not yet have a way of showing your topside position like QGC does with the NMEA stream from WaterLinked. It should be able to show vehicle position however, if the vehicle knows where it is!
Ohhhhh my goodness: UPDATE
Still not working but I have a CLUE
so, I just had the ROV use “https://demo.waterlinked.com” for gps info rather than the topside “http://192.168.2.94” and the ROV accepts the position given by the demo page.
I downloaded each log file and found the difference:
DEMO:
2026-04-23 18:32:53.689 | DEBUG | ugps_connection:get:30 - Request url: https://demo.waterlinked.com/api/v1/position/acoustic/filtered
2026-04-23 18:32:54.359 | DEBUG | ugps_connection:get:35 - Got response: {"position_valid":true,"receiver_distance":[34.69238250787778,37.221994672099,36.55877443569368,34.07937924147028],"receiver_nsd":[-98.04370479853239,-83.04370479853239,-58.04370479853239,-48.04370479853239],"receiver_rssi":[-42.07911690817759,-52.07911690817759,-57.92088309182241,-67.9208830918224],"receiver_valid":[1,1,1,0],"std":0.4480220772955602,"x":-5.197792270443978,"y":34.45369001834514,"z":8.960441545911204}
2026-04-23 18:32:54.367 | DEBUG | mavlink2resthelper:send_gps_input:224 - fix_type=3 from Topside GPS. static=False args.ignore_gps=False
2026-04-23 18:32:54.371 | DEBUG | mavlink2resthelper:post:100 - Request url: http://192.168.2.2:6040/mavlink json: {'header': {'system_id': 1, 'component_id': 220, 'sequence': 0}, 'message': {'type': 'GPS_INPUT', 'time_usec': 0, 'time_week_ms': 0, 'lat': 634428585, 'lon': 104240980, 'alt': 0.0, 'hdop': 1, 'vdop': 0.4480220772955602, 'vn': 0.0, 've': 0.0, 'vd': 0.0, 'speed_accuracy': 0.0, 'horiz_accuracy': 0.4480220772955602, 'vert_accuracy': 0.0, 'ignore_flags': {'bits': 185}, 'time_week': 0, 'gps_id': 0, 'fix_type': 3, 'satellites_visible': 6, 'yaw': 0}}
2026-04-23 18:32:54.383 | DEBUG | mavlink2resthelper:post:105 - Got response: OK
2026-04-23 18:32:54.385 | INFO | __main__:run:69 - Forwarding topside position from upgs to qgc
2026-04-23 18:32:54.385 | DEBUG | ugps_connection:get:30 - Request url: https://demo.waterlinked.com/api/v1/position/master
2026-04-23 18:32:54.924 | DEBUG | ugps_connection:get:35 - Got response: {"cog":107,"fix_quality":1,"hdop":1.9,"lat":63.44268543395073,"lon":10.423509036075613,"numsats":3,"orientation":319.5630475596304,"sog":0}
With my UGPS setup:
2026-04-22 19:55:36.623 | DEBUG | ugps_connection:get:30 - Request url: http://192.168.2.94/api/v1/position/acoustic/filtered
2026-04-22 19:55:36.641 | DEBUG | ugps_connection:get:35 - Got response: {"position_valid":true,"receiver_distance":[10.800000190734863,9.984000205993652,6.960000038146973,6.9120001792907715],"receiver_nsd":[-70.25563049316406,-64.4768295288086,-57.494781494140625,-60.71305847167969],"receiver_rssi":[-52.13176727294922,-57.403785705566406,-58.59804916381836,-55.83323287963867],"receiver_valid":[1,1,1,1],"std":1.7719190120697021,"x":-3.5475504398345947,"y":-1.5784245729446411,"z":7.344000339508057}
2026-04-22 19:55:36.643 | DEBUG | mavlink2resthelper:send_gps_input:228 - fix_type=1 from Topside GPS.
2026-04-22 19:55:36.644 | DEBUG | mavlink2resthelper:post:100 - Request url: http://192.168.2.2:6040/mavlink json: {'header': {'system_id': 1, 'component_id': 220, 'sequence': 0}, 'message': {'type': 'GPS_INPUT', 'time_usec': 0, 'time_week_ms': 0, 'lat': 328698237, 'lon': -1172506409, 'alt': 0.0, 'hdop': 0.9, 'vdop': 1.7719190120697021, 'vn': 0.0, 've': 0.0, 'vd': 0.0, 'speed_accuracy': 0.0, 'horiz_accuracy': 1.7719190120697021, 'vert_accuracy': 0.0, 'ignore_flags': {'bits': 185}, 'time_week': 0, 'gps_id': 0, 'fix_type': 1, 'satellites_visible': 12, 'yaw': 29300}}
2026-04-22 19:55:36.663 | DEBUG | mavlink2resthelper:post:105 - Got response: OK
2026-04-22 19:55:36.665 | INFO | __main__:run:69 - Forwarding topside position from upgs to qgc
2026-04-22 19:55:36.665 | DEBUG | ugps_connection:get:30 - Request url: http://192.168.2.94/api/v1/position/master
2026-04-22 19:55:36.700 | DEBUG | ugps_connection:get:35 - Got response: {"cog":0,"fix_quality":1,"hdop":0.9,"lat":32.86985833333333,"lon":-117.25064833333333,"numsats":12,"orientation":332.3999999999999,"sog":0}
2026-04-22 19:55:36.703 | DEBUG | qgc_connection:send_topside_position:86 - Sending UDP $GPGGA,195536.70,3252.191,N,11715.039,W,3,12,0.90,0,M,0,M,00,0000*7a
TLDR: the difference is the GPS fix type is 3 in demo and 1 in my testing. GPS fix 3 means 3D fix, while GPS fix 1 means no fix. This indicates that in the demo scenario, the GPS has a valid 3D position, while in the non-demo scenario, the GPS does not have a valid position fix.
My new question (thank god it is not a networking question): how do i get my UGPS fix to be a 3 instead of a 1? In the WL UGPS site I get green checks all around, showing that the ugps system is working fine. Why doesn’t it have a 3d fix? (this may be a question for the Waterlinked folks)
Thanks!
This is incredibly helpful info. I always thought my computer was 2.1 but I checked yesterday and it was 2.90. I shrugged and went with it. Trying to change it now but windows not letting me, will try to get the hang of that. Thank you!
Hi @coanderson -
To get a GPS lock, go outside! A clear view of the sky for the topside box is required to get a lock…
You can reference the ROV setup instructions to configure your IP address.
QGC now working! Thanks @tony-white
For the UGPS I have been using an external garmin GPS and I send NMEA strings to the topside via this github program made by WL: ugps-nmea-go/README.md at master · waterlinked/ugps-nmea-go · GitHub
I have been doing all my testing outside with my garmin gps accurately displaying my position on its screen. The Lat/lon in the WL UGPS Extension’s log files (see my post from yesterday in this thread) are accurate. Just trying to figure out why it does not think it is accurate.
Hi @coanderson -
That seems like a non-standard approach to GPS input to the system, and thus a better question for WaterLinked support… Evidently the topside isn’t properly ingesting what you’re sending, so it doesn’t know where it is! Without a valid GPS lock, it can’t tell where the ROV is relative to it…