We have a blue robotics ROV and a Waterlinked UGPS and Waterlinked DVL . We want to update to BlueOS but are concerned about the current lack of a Waterlinked UGPS driver.
I know this is imminent but In the mean time we have noticed some issues with a potential conflict between the Bluerobotics UGPS and DVL drivers.
It seems from my best understanding that they both share the use of the VFR_HUD/alt message/variable. It seems that somehow if we turn off our DVL driver (if we dont want the DVL data to be sent to the ROV for some reason) then the depth sent to and thus received by us from our WL UGPS system shows nearly zero when it should be ~8m.
I imagine this may well have been considered and discounted for some reason that I haven’t thought of but I at least wanted to ask the question and see if anyone else has any thoughts
It’s a bit confusing but the vehicle actually uses VFR_HUD.alt as its pressure-based depth indication (just as a negative value). As far as I’m aware contributions to the vertical position from the DVL should be ignored by EK3_SRC1_POSZ being set to Baro (1), so I’m not sure why your UGPS system is acting unexpectedly.
I’ve asked internally whether there’s some kind of known explanation for what you’re seeing.
As a side note, using the Water Linked UGPS and DVL together is (as far as I’m aware) not yet actively supported, so it’s possible there are some issues with trying to do so.
Thank you for your reply and sorry for my slow one!
Specifically what we are seeing is that if we turn off the DVL driver , then we know longer get a depth for our A1 sent to the Waterlinked system via the UGPS driver.
Thanks very much for you asking colleagues
I can see in your reply to @Boko that the WL UGPS ‘driver’ for BlueOS is nearly up and running so I mean this issues may well just go away as we switch to BlueOS but do you know if consideration has been given to the DVL and UGPS ‘drivers’ or extensions working together? I’m happy to help in anyway I can with this too
The extensions in BlueOS should have no issues running at the same time - the potential issues are with how the ArduSub autopilot firmware handles the incoming data, and whether it’s successful at merging the data into a meaningful and stable position estimate. The alternatives would be it could end up less sure about the position if the data sources conflict, or it could end up just ignoring one of them (which isn’t a particularly useful behaviour if both sensors are available and working properly).
Hopefully it will be possible to configure ArduSub’s parameters to get the data to fuse nicely, which you’re welcome to try out if you want to. Likely there’ll be some tweaking required of (general) EK3 Parameters, EK3_SRC Parameters, GPS Parameters, and VISO Parameters. At a guess, the UGPS and DVL data should be combined if EK3_SRC1_POSXY is set to GPS, and EK3_SRC1_VELXY is set to ExternalNav, but I’m not sure how well that’s likely to work without additional parameter adjustments, and it may require the DVL extension to add support for direct velocity passthrough (which is not currently available).
Thanks very much for your reply. I feel like you’ve gotten perfectly to the bottom of my question. I am aware that Kalman filter sensor fusion can be a bit of an art especially when it comes to the uncertainty estimates.
I have been working on an offline version of a Kalman filter process that takes in:
Position from the the Waterlinked UGPS
Body frame velocities from the waterlinked DVL
Heading angle from the PIxhawk
So far with limited success but its early days.
But what you propose sounds like you think it should be perfectly possible for the Pixhawk to compute a live on board position solution from the DVL and UGPS data which would be our ideal solution
Is it possible to elaborate on what you mean here:
“DVL extension to add support for direct velocity passthrough (which is not currently available).”
As I thought the DVL could send velocity data to the Flight controller?
The DVL extension backend can send either VISION_POSITION_DELTA or VISION_SPEED_ESTIMATE MAVLink messages to the autopilot. Speed estimate messages make the most sense (since it’s what the DVL is actually measuring), but there’s an issue with the MAVLink2REST mechanism currently used in BlueOS that means those messages can’t be sent properly right now, so position delta messages are the only option that’s currently usable, and the speed estimate option is left as implemented but not “available” to use.
If we set EK3_SRC1_VELXY to ExternalNav (while sending VISION_POSITION_DELTAs) I expect it will either
Ignore it
in which case VISION_SPEED_ESTIMATE would be the only way for the values to have a chance of being used while a GPS source is also available
Internally convert the position delta estimates into speed estimates by dividing by the time since the previous one, and then use them
which should work, it’s just a bit silly to do (since it’s reversing the calculation work that the extension had to do to create the position deltas to start with), and may introduce some unnecessary error
I’d guess that EK3_SRCn_POS* parameters would make use of position deltas and position estimates, while EK3_SRCn_VEL* parameters would make use of speed estimates, since that involves the least amount of work for the autopilot, but I could definitely be wrong about that. It’s likely worth testing, or trying to find and understand the relevant code in the ArduPilot source.
But maybe not completely yet… I am looking at the code:
and I still cant completely convince myself what data is being used from the DVL. I am concerned because the more I look into the data at least from our a50 DVL the less I trust the onboard IMU. So I just wanted to check if you know wether the BlueOS DVL extension uses either the the orientation values from the DVL to compute position, or takes the dead reckoning positions computed internally by the DVL?
The DVL extension currently does not use the DVL’s dead reckoning estimates - it uses the DVL’s orientation and velocity measurements to estimate the changed position since the last message it sent to the autopilot, and sends that as a VISION_POSITION_DELTA message.
There is (unused/unreachable) code in the extension backend that refers to sending
VISION_SPEED_ESTIMATE to directly pass on the DVL’s velocity measurements
which is not exposed via the frontend, because the MAVLink2REST issue means it won’t work
VISION_POSITION_ESTIMATE to directly pass on the DVL’s dead reckoning estimates
which is not exposed via the frontend, because of an issue in ArduPilot’s VISION_POSITION_ESTIMATE handling, where it seemingly treats local positions as global ones
Thanks again for the taking the time , I think I am finally catching up …
I think for our use and my best understanding of Kalman filtering for Positon estimates and the reliability of the sensors. What I want to do is to send the following to the autopilots extended Kalman filter:
X , Y positions : WL UGPS positions
X, Y velocities : WL DVL velocities (In the body frame of the DVL and thus vehicle )
Orientation : Use the IMU values from the Pixhawk flight controller itself.
I’m hopeful that this is achievable with some small modifications to the existing Blue OS extension code (once the UGPS module becomes available) , although I guess:
“but there’s an issue with the MAVLink2REST mechanism currently used in BlueOS that means those messages can’t be sent properly right now,”
I brought this up, and that side of things should most likely be fixed by this PR.
As I mentioned above, it may already work with the existing form of the extension, but if there are issues with ArduSub not automatically converting the position_delta messages into usable velocities then the DVL extension frontend may need to be updated to allow using VISION_SPEED_ESTIMATE messages, and there may also be other aspects that need tuning or updating for the simultaneous integration of both sensors to work well.
