# DVL A50 integration with GPS position **URL:** \ **Category:** BlueOS\ **Tags:** dvl, positioning\ **Created:** [June 10, 2024, 6:24pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114 "2024-06-10T18:24:52Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![dbhowmick](https://avatars.discourse-cdn.com/v4/letter/d/a4c791/32.png) [@dbhowmick](https://discuss.bluerobotics.com/u/dbhowmick)\ **Post date:** [June 10, 2024, 6:24pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/1 "2024-06-10T18:24:52Z")
Hey guys I am wondering what exactly is happening in the background when I click on the global map to set the position of the ROV when using the DVL. I want to use a real GPS reading to update that position instead of clicking on map. Is this a viable option? Regards ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [June 11, 2024, 2:00am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/2 "2024-06-11T02:00:13Z")
Hi @dbhowmick, > [@dbhowmick](#): > > I am wondering what exactly is happening in the background when I click on the global map to set the position of the ROV when using the DVL. [Here’s the relevant code function](https://github.com/bluerobotics/BlueOS-Water-Linked-DVL/blob/master/dvl-a50/dvl.py#L237) - it does two different things: 1. If the positioning system is not initialised it [sets the global origin for the vehicle’s position estimates](http://mavlink.io/en/messages/common#SET_GPS_GLOBAL_ORIGIN) - This allows the vehicle’s position estimate to maintain high precision by only storing small number offsets from the configured origin, instead of having to store large numbers that have small variations 2. If there is an established origin, it just sends the specified position to the autopilot as a new position estimate > [@dbhowmick](#): > > I want to use a real GPS reading to update that position instead of clicking on map. Is this a viable option? There’s been [some previous discussion about surface GPS integration](https://discuss.bluerobotics.com/t/surface-gps-trace/10823), but there hasn’t yet been a definitively established best/stable way of handling it. The options that come to mind are: 1. Connecting a GPS to the autopilot and then [using a Lua script](https://discuss.bluerobotics.com/t/gps-data-not-used/11307/13) to selectively enable it at the surface - The GPS connection could either be wired with a serial connection to the flight controller board, or using the BlueOS NMEA injector to provide positions from an NMEA GPS 2. Modifying ArduSub to have a “surface GPS” mode that handles that switching by itself - This could yield nice results, but could be somewhat complex to implement, and would require custom firmware builds until the feature gets merged into the main codebase 3. Connecting a GPS to your own BlueOS Extension (or modifying the Water Linked DVL extension to accept a GPS input), and using that to send its position estimates to the autopilot via visual odometry messages (like the existing “set position” functionality), thus pretending it’s part of the DVL - This would avoid needing to change parameters, but may also cause issues if the readings are inconsistent with the DVL, because the autopilot doesn’t know that there are actually two different devices involved ---
**Author:** ![dbhowmick](https://avatars.discourse-cdn.com/v4/letter/d/a4c791/32.png) [@dbhowmick](https://discuss.bluerobotics.com/u/dbhowmick)\ **Post date:** [June 13, 2024, 6:44pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/3 "2024-06-13T18:44:54Z")
we got it working by using the serial bridge to send the gps messages to UDP port and then a python script looks for quality 4 for RTK fix and if fix is found then it updates the origin as you told us how to do that! another question is how can I also get the rov to use this for navigation if fix is 4. I want the ROV to use the GPS for nav on the surface and DVL below surface. Any ideas? Also how does the nmea injector work, what parameters do i need to change to make it listen to GPS for nav instead of the DVL Regards ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [June 17, 2024, 1:53pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/4 "2024-06-17T13:53:51Z")
> [@dbhowmick](#): > > another question is how can I also get the rov to use this for navigation … I want the ROV to use the GPS for nav on the surface and DVL below surface. Any ideas? That’s what the whole second half of my previous comment was about - I’d suggest reviewing that, and checking the links I provided. > [@dbhowmick](#): > > Also how does the nmea injector work - [Documentation of the interface](https://blueos.cloud/docs/blueos/1.2/advanced-usage/#nmea-injector) - [Development documentation of the available services](https://blueos.cloud/docs/blueos/1.2/development/core/#services) - [Most relevant part of the source code](https://github.com/bluerobotics/BlueOS/blob/master/core/services/nmea_injector/nmea_injector/MavlinkNMEA.py#L69) - It converts NMEA messages from the GPS into [`GPS_INPUT`](http://mavlink.io/en/messages/common.html#GPS_INPUT) MAVLink messages, that then get forwarded to the autopilot > [@dbhowmick](#): > > what parameters do i need to change to make it listen to GPS for nav instead of the DVL The Lua script example I linked to approaches this by configuring two separate Extended Kalman filters (for fusing the sensor readings), which it then switches between\[1\] depending on whether the GPS signal should be used or ignored. In that example, 1. [`EK3_SRCn_VELXY`](https://docs.bluerobotics.com/ardusub-zola/software/autopilot/ArduSub-4.1/developers/parameters/#ek3-src1-velxy-velocity-horizontal-source) is consistently set to `ExternalNav (6)` - because the DVL’s velocity estimates are assumed to occur at a higher frequency and precision than the GPS’s updates, but 2. [`EK3_SRCn_POSXY`](https://docs.bluerobotics.com/ardusub-zola/software/autopilot/ArduSub-4.1/developers/parameters/#ek3-src1-posxy-position-horizontal-source-primary) is configured as 1. `GPS (3)` for `SRC1`, for use when the GPS signal is available and high quality, and 2. `ExternalNav (6)` for `SRC2`, for when the DVL should be used instead (because the GPS is unavailable / poor quality). * * * 1. I’m not sure this is possible from outside the autopilot (i.e. I don’t believe there’s a mechanism for this using MAVLink, so this approach requires custom firmware or a Lua script), although if you’re using `VISION_POSITION` messages for your GPS data instead of `GPS_INPUT` messages like option 3 from my original comment then I suppose there would be no switching that needs to occur, and the “switch” would just come from stopping sending the position estimates from the GPS. ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [February 1, 2025, 10:52pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/5 "2025-02-01T22:52:35Z")
> [@EliotBR](#): > > There’s been [some previous discussion about surface GPS integration](https://discuss.bluerobotics.com/t/surface-gps-trace/10823), but there hasn’t yet been a definitively established best/stable way of handling it. As we work through this exact challenge (getting Surface GPS + DVL to read location) I’d love an update on this thread. **For instance, is a Lua script still required at this point?** In our situation we have a uBlox M9N GNSS connected to the Navigator + Waterlinked A50 DVL. We have EK3\_SRC1\_POSXY = GPS and EK3\_SRC2\_POSXY=ExternalNav. It all sort of works, i.e. we can pull a track of lat, long. However, one thing we’ve noticed is the depth reading in Cockpit reads incorrectly… We have EK3\_SRC1\_POSZ = Baro but it’s getting some weird value when the GPS is enabled. Will do a bit more digging, but any update here appreciated! ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [February 2, 2025, 6:19pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/6 "2025-02-02T18:19:46Z")
> [@PeterM](#): > > As we work through this exact challenge (getting Surface GPS + DVL to read location) I’d love an update on this thread. **For instance, is a Lua script still required at this point?** Just a clarification on this piece: I ask because we aren’t switching between EK3 source sets and yet we’re getting meaningful lat, long recordings, even below the waterline with no GPS and when DVL obviously providing incremental positioning (inspite of EK3\_SRC1\_POSXY being set to GPS)… So a bit confused. Other than the bung depth readings we seem to have the behaviour we want. ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [February 3, 2025, 6:30am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/7 "2025-02-03T06:30:05Z")
Results of a bit more testing today. With GPS fitted to the Navigator (Serial 3 with GPS\_TYPE = Auto) and with the standard EK3 settings for DVL (see below), the GPS seems to set the current position automatically when GPS has lock. Hey presto! This kind of makes sense as the DVL is still doing it’s thing at the surface (if seafloor in range) so no real need to switch to GPS for controlling POSXY. We just need the GPS to provide the lat/long starting point for the DVL which it can merrily do until it fails, i.e goes underwater and looses a fix. The only problem is depth reading gets messed up. Still trying to work out where the mysterious number comes from (note EK3\_SRC1\_POSZ set to Baro). Any ideas @EliotBR ? ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/7/78f2e5124a620b5da7b5634870dcaa039f7f5e54.png) ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/d/d908566ec26514d27cfb7cc7329128864e099b5a.png) ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/a/a851eea7b2fb53b7a98d137f354000a46b1a7f8e.png) ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/2X/a/a55602f588f5e27a1cfc8f92983e33878726d36a.png) ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [February 3, 2025, 5:06pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/8 "2025-02-03T17:06:22Z")
> [@PeterM](#): > > is a Lua script still required at this point? Without a dedicated mode for it in ArduSub, I assume a Lua script would allow for the best available performance, because GPS units often give wild position estimates when they’re just below the water surface, which can throw things off before the switch to the DVL happens. > [@PeterM](#): > > Still trying to work out where the mysterious number comes from (note EK3\_SRC1\_POSZ set to Baro). I asked @williangalvani, and he mentioned that VELZ is apparently leaking (😕), with the following PRs as potential fixes/improvements: > [@williangalvani](#): > > - [AP\_NavEKF3: ignore VelZ of body odometry if SRCn\_VELZ is set to None by Williangalvani · Pull Request #28548 · ArduPilot/ardupilot · GitHub](https://github.com/ArduPilot/ardupilot/pull/28548) > - [AP\_NavEKF3: Allow extnav to work without vertical velocity by rishabsingh3003 · Pull Request #29213 · ArduPilot/ardupilot · GitHub](https://github.com/ArduPilot/ardupilot/pull/29213) ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [February 3, 2025, 8:45pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/9 "2025-02-03T20:45:32Z")
Thanks @EliotBR . Still a bit confused as to how or what is setting the lat/long from the GPS reading to the DVL A50 given GPS not included in the EK3\_SRC1\_\* settings at all. Might that be the Waterlinked plugin code? Whatever is setting the lat, long, I wonder if that could be beefed up to reject lat/long settings with low integrity (low nSat, poor HDOP)? @williangalvani : Happy to test any potential fixes to the “VELZ leak” if useful and it speeds up a fix. Robust logging of a depth reading pretty critical for us. ---
**Author:** ![williangalvani](https://avatars.discourse-cdn.com/v4/letter/w/6f9a4e/32.png) [@williangalvani](https://discuss.bluerobotics.com/u/williangalvani)\ **Post date:** [February 4, 2025, 11:38pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/10 "2025-02-04T23:38:49Z")
Another issue that is likely hurting us: > > > 1. If external navigation is used for position and/or speed together with GPS, t…hen external navigation measurement errors are overwritten by GPS reported errors. Is it ok? AFAIU, the external navigation \`if\`-s should come 1st. > https://github.com/ArduPilot/ardupilot/blob/cf7b01d73a08aa78899c2031371cc8bb467e5e3f/libraries/AP\_NavEKF3/AP\_NavEKF3\_PosVelFusion.cpp#L682 > https://github.com/ArduPilot/ardupilot/blob/cf7b01d73a08aa78899c2031371cc8bb467e5e3f/libraries/AP\_NavEKF3/AP\_NavEKF3\_PosVelFusion.cpp#L697 > > 2. Also, when compiting GPS velocity variances used for data checks, vertical velocity is treated identically to horizontal velocity. I.e., \`\_gpsHorizVelNoise\` & \`gpsNEVelVarAccScale\` are used instead of \`\_gpsVertVelNoise\` & \`gpsDVelVarAccScale\` for vertical velocity, as it's done for variances used for fusion. Also, description mentions only horizontal velocity. > https://github.com/ArduPilot/ardupilot/blob/cf7b01d73a08aa78899c2031371cc8bb467e5e3f/libraries/AP\_NavEKF3/AP\_NavEKF3\_PosVelFusion.cpp#L717 > Mentioned this here: https://github.com/ArduPilot/ardupilot/commit/e80fb8b3fa301fb3857d3306099da7a763be99ee#commitcomment-117061127 > > 3. \`CalculateVelInnovationsAndVariances\` also doesn't use \`\_gpsVertVelNoise\` & \`gpsDVelVarAccScale\` for vertical velocity > https://github.com/ArduPilot/ardupilot/blob/cf7b01d73a08aa78899c2031371cc8bb467e5e3f/libraries/AP\_NavEKF3/AP\_NavEKF3\_PosVelFusion.cpp#L496 > > 4. If there are ext.nav. messages to fuse but they are not configured to be used as velocity source, variances for ext.nav. are still used, though GPS velocities are actually fused > https://github.com/ArduPilot/ardupilot/blob/cf7b01d73a08aa78899c2031371cc8bb467e5e3f/libraries/AP\_NavEKF3/AP\_NavEKF3\_PosVelFusion.cpp#L687 > https://github.com/ArduPilot/ardupilot/blob/cf7b01d73a08aa78899c2031371cc8bb467e5e3f/libraries/AP\_NavEKF3/AP\_NavEKF3\_PosVelFusion.cpp#L712 > > The issues concern both EKF2 & 3. ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [February 10, 2025, 1:17am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/11 "2025-02-10T01:17:58Z")
> [@PeterM](#): > > The only problem is depth reading gets messed up. Still trying to work out where the mysterious number comes from (note EK3\_SRC1\_POSZ set to Baro). Quick follow-up on this. @samuel_reedy dug into it a bit more and has posted this to Github: > > > I’m seeking clarification on the behaviour of the Depth HUD and Depth Mini-widge…t after we’ve noticed a discrepancy when attaching a surface GPS to the BlueROV2. > > \- Without the GPS both Depth HUD and Depth Mini-widget read 0 at the surface. > \- With a surface GPS attached the DepthHUD appears to show 0 on the graticule but shows a large negative number on the surface (see screencapture). While Depth Mini-widget still shows 0. > > Closer examination of the code for the \[DepthHUD\](https://github.com/bluerobotics/cockpit/blob/master/src/components/widgets/DepthHUD.vue) and \[Depth Mini-Widget\](https://github.com/bluerobotics/cockpit/blob/master/src/components/mini-widgets/DepthIndicator.vue) shows both using the same value from altitude.msl but treating these differently: > > \- For the Depth Mini-Widget, the depth is set to 0 for values before 0.01. Meaning in a body of water above sea level, the depth always gets set to 0. > \- Whereas the Depth HUD does not have this same limitation and always displays the depth, even if the ROV is far above sea level. > > Can you clarify what the intention is here? Our assumption is that the depthHUD (due to its name) would always show depth below a waterline. So, whether that’s operating in the sea at sea level or up in a lake at an altitude above sea level, it would show depth below the waterline. Is that the correct intention? > > Wouldn’t Relative Altitude (e.g. GLOBAL \_POSITION\_INT.relative\_alt) be a better option? This is the \[altitude above Home\](https://mavlink.io/en/messages/common.html#GLOBAL\_POSITION\_INT). If we interpret Home as being on the surface of the water (i.e if set at start of a mission), isn’t that exactly what’s needed? Would that not better meet the need for displaying depth irrespective of the altitude of the body of water you’re deployed in? > > We found \[this Ardupilot documentation on interpretation of altitude\](https://ardupilot.org/copter/docs/common-understanding-altitude.html) but it doesn’t include the Sub use case. I’m assuming that Cockpit is currently a Sub-only implementation but with eye to make it more general purpose for drone use, right? In which case a separate AltitudeHUD widget would be required? > > Keen to get to the bottom of this as trying to get the surface GPS + DVL solution working smoothly - showing and logging correct depth values. So, understanding the direction here would be super useful. > > > !\[Image\](https://github.com/user-attachments/assets/9c31eedd-0e20-4f04-ac8a-f91f75d72b45) ---
**Author:** ![ryan354](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/ryan354/32/13476_2.png) [@ryan354](https://discuss.bluerobotics.com/u/ryan354)\ **Post date:** [July 21, 2025, 2:44am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/12 "2025-07-21T02:44:59Z")
Hi @EliotBR @PeterM @williangalvani @dbhowmick I just wanted to follow up on this topic, as I’m currently working on a similar system setup involving the DVL A50 and GPS. Could you please clarify whether a Lua script is still required in this case? Thanks in advance! ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [July 21, 2025, 8:43am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/13 "2025-07-21T08:43:23Z")
Hi @ryan354. We haven’t put a whole lot of time into this, but yes, as far as I know you do need actively swap source sets via a lua script. We took what @williangalvani put together and played around with adding some additional criteria (then got distracted by other prioritites). Here’s where we got to: > **[GitHub - Revive-Our-Gulf/dvl-gps-scripting: Lua Scripts for testing GPS/DVL switching](https://github.com/Revive-Our-Gulf/dvl-gps-scripting/)** > > Lua Scripts for testing GPS/DVL switching ---
**Author:** ![ryan354](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/ryan354/32/13476_2.png) [@ryan354](https://discuss.bluerobotics.com/u/ryan354)\ **Post date:** [July 22, 2025, 5:44am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/14 "2025-07-22T05:44:45Z")
> [@PeterM](#): > > Hi @ryan354. We haven’t put a whole lot of time into this, but yes, as far as I know you do need actively swap source sets via a lua script. We took what @williangalvani put together and played around with adding some additional criteria (then got distracted by other prioritites). Here’s where we got to: Thanks for the info! Got it — I’ll give that a try ---
**Author:** ![XYZEng](https://avatars.discourse-cdn.com/v4/letter/x/9de053/32.png) [@XYZEng](https://discuss.bluerobotics.com/u/XYZEng)\ **Post date:** [September 10, 2025, 4:47pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/15 "2025-09-10T16:47:14Z")
Hi @EliotBR and @williangalvani It seems the pull requests linked have been merged or closed. If this is considered to be working, could we get a brief description of what to do to set up an ROV for dead reckoning with a DVL and GPS? I know the waterlinked blueOS extension gives (DVL + GPS) option, is this option related to dead reckoning? Or is it purely for fusing USBL data with DVL? Are there any other parameters we have to set? And is the Lua script required? I’m hoping to do some testing of this on my next outing, any advice would be much appreciated. ---
**Author:** ![williangalvani](https://avatars.discourse-cdn.com/v4/letter/w/6f9a4e/32.png) [@williangalvani](https://discuss.bluerobotics.com/u/williangalvani)\ **Post date:** [September 17, 2025, 8:06pm UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/16 "2025-09-17T20:06:53Z")
I’m still working on it actively. On master no Lua script is required. there are still a couple of loose ends, mostly dealing with AUTO missions, though. - One issue is that the EKF origin (which its local position calculations are relative to) gets set from the GPS, which generally has an error of many meters. - [This PR](https://github.com/ArduPilot/ardupilot/pull/30891) should deal with that. - [This one](https://github.com/ArduPilot/ardupilot/pull/30291) validates the functionality with an auto-test. - [This one](https://github.com/ArduPilot/ardupilot/pull/30823) makes it so we can use “zero” as waypoint, as I expect most ROVs with GPS-only positioning will want to run missions at the surface. ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [March 2, 2026, 4:54am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/17 "2026-03-02T04:54:27Z")
Be curious to know how you got on @ryan354? We’re still struggling to get robust and reliable behaviour. Here’s a thought: If we are just using GPS on the surface before a dive then why are we bothering to have the GPS as an input to the EKF? - with all that complexity of source switch with a Lua script? Could we get away with just setting the DVL position, once only, from a stable GPS location once the ROV is deployed and floating on the surface, and DVL picks up a reliable seafloor lock (we’re coastal, \<50m)? What do you think @EliotBR and @williangalvani ? Here’s a great example of our current setup not quite working… You clearly see the rock we circumnavigated with the ROV. The DVL track is great, but shifted to the right, most likely because it got one noisy lat, long point of the GPS as it dived down, and before the lua script switch across to use DVL. Then when surfaced, it leaps back to the real location. If we weren’t source switching, we’d wait for a stable GPS and a seafloor lock on the DVL, set the starting lat/long of the DVL, then off we go. At the end of the dive we’d want to check GPS and compare to DVL and then reset the DVL lat/long - which would result in a smaller jump as you clear off the DVL cummulative error. ![Screenshot 2026-02-27 at 7.01.37 AM](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/3X/a/6/a6298ec13bddec93b55eea9a3c51931e69a44661.jpeg) Would love this problem to be solved and in the core platform. Would be such a win… ---
**Author:** ![EliotBR](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/eliotbr/32/6937_2.png) [@EliotBR](https://discuss.bluerobotics.com/u/EliotBR)\ **Post date:** [March 2, 2026, 6:23am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/18 "2026-03-02T06:23:20Z")
> [@PeterM](#): > > We’re still struggling to get robust and reliable behaviour. Which version are you testing with? The functionality PRs Willian linked to have been merged, but are currently only available in `master` (the daily “Dev” release, if downloading through BlueOS). If you’d prefer to test official releases instead of building from source, ArduPilot will soon start beta testing for its combined 4.7 release, which Sub is expected to be part of. > [@PeterM](#): > > If we are just using GPS on the surface before a dive then why are we bothering to have the GPS as an input to the EKF? DVLs (and any derivative value sensor) have continual position estimation drift caused by integration error, and may lose the seafloor at times, so I think the assumption is that many users with both a GPS and DVL will be at least occasionally resurfacing to correct (or regain) the positioning estimate. Needing to manually supply coordinates or trigger re-syncs then seems awkward, so it’s preferable for there to be programmed in functionality that accepts GPS inputs while the vehicle is at the surface, then ignores them while diving. > [@PeterM](#): > > Could we get away with just setting the DVL position, once only, from a stable GPS location once the ROV is deployed and floating on the surface, and DVL picks up a reliable seafloor lock (we’re coastal, \<50m)? If you’re not surfacing during your dives, have a continuous seafloor lock from your DVL, and have sufficiently short dive durations that error accumulation isn’t a concern, then you could indeed just send a single location from a stable position at the surface, and completely avoid feeding the GPS data into the EKF. If you’ve configured the GPS to be connected, but not included in any of the EKF sources, then you could trigger the position feed-in from a Lua script or Cockpit Action. > [@PeterM](#): > > most likely because it got one noisy lat, long point of the GPS as it dived down Have you checked for large jumps in the GPS position in the log? I’m curious if it was indeed a GPS issue, or caused by growing DVL error (which to some extent may be fixable in post). ---
**Author:** ![ryan354](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/ryan354/32/13476_2.png) [@ryan354](https://discuss.bluerobotics.com/u/ryan354)\ **Post date:** [March 5, 2026, 5:59am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/19 "2026-03-05T05:59:43Z")
I’m having the exact same issue with those ‘jumps’ during the transition. We’ve started using GPS for the initial position only. We wait for a stable lock on the surface, and then let the DVL handle navigation for the duration of the dive. It’s much more reliable, a consistent track rather than a jumpy one caused by noisy GPS inputs during submersion ![image](https://us1.discourse-cdn.com/flex019/uploads/bluerobotics/original/3X/3/5/35a8a25dcb15808ea8ef4c0d33325a4c2f4d4e61.jpeg) ---
**Author:** ![PeterM](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.bluerobotics.com/peterm/32/11879_2.png) [@PeterM](https://discuss.bluerobotics.com/u/PeterM)\ **Post date:** [March 11, 2026, 5:04am UTC](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114/20 "2026-03-11T05:04:31Z")
@ryan354 : So are you achieving loading of that initial position using a lua script? Or, some other method? You mind sharing a bit more technical detail? [Next page](https://discuss.bluerobotics.com/t/dvl-a50-integration-with-gps-position/17114.md?page=2)