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
Hi @dbhowmick,
Hereās the relevant code function - it does two different things:
Thereās been some previous discussion about surface GPS integration, but there hasnāt yet been a definitively established best/stable way of handling it.
The options that come to mind are:
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
Thatās what the whole second half of my previous comment was about - Iād suggest reviewing that, and checking the links I provided.
GPS_INPUT MAVLink messages, that then get forwarded to the autopilotThe 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,
EK3_SRCn_VELXY is consistently set to ExternalNav (6)
EK3_SRCn_POSXY is configured as
GPS (3) for SRC1, for use when the GPS signal is available and high quality, andExternalNav (6) for SRC2, for when the DVL should be used instead (because the GPS is unavailable / poor quality).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. ā©ļø
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!
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.
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 ?
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.
I asked @williangalvani, and he mentioned that VELZ is apparently leaking (
), with the following PRs as potential fixes/improvements:
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.
Another issue that is likely hurting us:
Quick follow-up on this. @samuel_reedy dug into it a bit more and has posted this to Github:
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!
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
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.
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.
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.
Would love this problem to be solved and in the core platform. Would be such a winā¦
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.
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.
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.
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).
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
@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?
