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?
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
If there is an established origin, it just sends the specified position to the autopilot as a new position estimate
Connecting a GPS to the autopilot and then using a Lua script 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
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
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
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
It converts NMEA messages from the GPS into GPS_INPUT MAVLink messages, that then get forwarded to the autopilot
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.
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.
), with the following PRs as potential fixes/improvements:
