WaterLinked DVL A50 integration not working

[yuki (Yuki Kihara)]

We have alredy integrated DVL driver, but cannot display dvl position data in QGC.
Also we cannnot switch GUIDED mode.

I think causes of that is we cannot Enable odometry support.

VISO_TYPE 1

We search VISO_TYPE paramter in QGC>Parameters, but we cannot find it.

[EliotBR (Eliot)]

@yuki

I think causes of that is we cannot Enable odometry support.

VISO_TYPE 1

We search VISO_TYPE paramter in QGC>Parameters, but we cannot find it.

Which version of ArduSub are you using? The DVL integration requires using the “Beta” release (4.1.0) - it won’t work on the “Stable” release (4.0.3).

@yuki

Also we cannnot switch GUIDED mode.

I searched our docs for “Guided Mode” and the first result is this page, which has a note that says

@ardusub.com - Tuning Setup Page

Guided and Auto modes are currently unsupported and some features are disabled in QGC.

There’s some further brief commentary on that here. Regardless, modes that require a position estimate understandably can’t be switched into without active position measurements, so you’ll need to fix the DVL connection/integration issue first.

[yuki (Yuki Kihara)]

I can find VISO_TYPE parameter by upgrade Ardusub to “beta” 4.1.0.
But I have a problem that “depth pressure sensor is not connected” error.

I connect Bar30 pressure sensor to Pixhawk 12C same as in that link.

[EliotBR (Eliot)]

@yuki

But I have a problem that “depth pressure sensor is not connected” error .

ArduSub beta recently had a couple of updates that apparently messed up a default parameter for the depth sensor. The issue should be fixed if you

@williangalvani

try settting BARO_PROBE_EXT to 768 and then reboot.

You will also need to set EK3_SRC1_POSXY and EK3_SRC1_VELXY to 6 (although I’m unsure if that’s just if you’re using BlueOS Beta instead of Companion).

[yuki (Yuki Kihara)]

Thankes! I solve it by settting BARO_PROBE_EXT.
However, I connot find EKF3_GPS_TYPE parameter and PSC_POSY paramter max 2.0 (recommend 2.5).

[EliotBR (Eliot)]

@yuki

I connot find EKF3_GPS_TYPE parameter

I’ve just looked into this a bit more. As I understand it, the new ArduSub Beta uses EK3_SRC1_POSXY and EK3_SRC1_VELXY instead of EKF3_GPS_TYPE.

@yuki

and PSC_POSY paramter max 2.0 (recommend 2.5).

I believe you’re after the PSC_POSXY_P parameter.

[yuki (Yuki Kihara)]

@EliotBR

I believe you’re after the PSC_POSXY_P parameter.

Sorry, I describe it wrongly.
PSC_POSXY_P parameter is recommended 2.5, but its maximum is 2.0.

[EliotBR (Eliot)]

@yuki

PSC_POSXY_P parameter is recommended 2.5, but its maximum is 2.0.

Right, I’ve just confirmed that in QGC, so it seems our recommendation hasn’t been updated to match the new firmware.

I’ve put a comment about that in my documentation update pull request, but I don’t know what the new recommended value is so we’ll need to wait for the software team to be online tomorrow.

[yuki (Yuki Kihara)]

@EliotBR

I’ve put a comment about that in my documentation update pull request, but I don’t know what the new recommended value is so we’ll need to wait for the software team to be online tomorrow.

Thanks, I’ ll be wait for it.

By the way, is QGC EFK data(LOCAL_POSITION_NED) an integration of DVL velocity data and ROV IMU data or DVL dead reckoning data , when integrate DVL?

[EliotBR (Eliot)]

@yuki

By the way, is QGC EFK data( LOCAL_POSITION_NED ) an integration of DVL velocity data and ROV IMU data or DVL dead reckoning data , when integrate DVL?

At this stage the DVL’s dead reckoning message isn’t used in the DVL integration - the position reported in QGC is calculated by ArduSub’s EKF3, which does its own dead reckoning by combining the autopilot’s IMU values with the DVL’s velocity measurements.

[EliotBR (Eliot)]

@EliotBR

I’ve put a comment about that in my documentation update pull request, but I don’t know what the new recommended value is so we’ll need to wait for the software team to be online tomorrow.

Apologies for the delay on this. You should be able to just use 2.0

[Jnyberg (Julien Nyberg - SeaView Systems)]

I have my DVL configured to IP Address: 192.168.2.95. And on dashboard I am getting a valid velocity reading.

But when I go to waterlinked driver set up it tries to connect but then says unable to.

…

…

I am curious if that message saying “Trying to talk to dvl at http://192.168.2.95/api/v1/about” is the message I am suppose to see. I ask because when I try to go to that page it sends me to a page of what looks like code

And it doesn’t seem like it goes to the DVL IP address itself. But don’t quite understand how they communicate with each other so I wasn’t sure if this is an issue or not.

[valeri2a (Valeriia Okhmak)]

I have the same problem with BlueOS integration and seems that it is something wrong with the driver.

[EliotBR (Eliot)]

I don’t believe that’s an issue we were aware of, but the DVL extension is currently being rewritten to add some extra functionality and improve the interface, so this issue should be resolved with the release of that new version. It should be available within the next couple of weeks

[Jnyberg (Julien Nyberg - SeaView Systems)]

Thanks for update on that! What is the most recent configuration of the OS and Ardusub is that the DVL works with? Maybe running into connection issues due to versions. Currently using BlueOS version 1.0.1 and Ardusub firmware 4.1.0.

[EliotBR (Eliot)]

I spoke with @williangalvani about this, and was told that there were some recent mavlink2rest and water-linked API changes that are causing the issues here. The updated DVL extension should support the latest BlueOS and DVL firmware versions, as well as the api for older DVL firmware versions.

You can beta test it via the following instructions:

@williangalvani

EDIT: modified to automatically find the container name, and stop it

# first, make sure to get rid of the older version
red-pill
# find the name of the DVL container, and stop and remove it
export OLD=$(docker container ls --format='{{.Names}}' | grep -i dvl)
docker container stop $OLD
docker container rm $OLD
# pull the new image and start the new docker
docker pull williangalvani/blueos-dvl:latest
docker run -d --net=host -v /root/.config/blueos:/root/.config --name=BlueOS-Water-Linked-DVL --restart=unless-stopped williangalvani/blueos-dvl:latest

@Jnyberg

What is the most recent configuration of the OS and Ardusub is that the DVL works with? Maybe running into connection issues due to versions.

It’s a bit unclear, but it looks like the mavlink2rest API might have changed on the 1/March, in which case the latest version before that would be 1.0.0-beta13. That’s from before the first stable release, so is likely not advisable to go back to. If that is the case it at least makes some sense, because the idea was that once BlueOS was stable the core APIs should stop having breaking changes wherever possible.

I’m also unsure whether it’s possible to access older water-linked DVL firmwares, so if you’re already on the latest one then you may need to use the latest DVL extension, or wait until it’s released in stable form.

[Jnyberg (Julien Nyberg - SeaView Systems)]

@EliotBR since I have newest stable versions of both BlueOS and DVL, I went ahead and followed the steps by @williangalvani. But in my listing I could not find the two names to delete. Instead it was another one for the DVL. So I tried to delete that one instead but was told that I had to stop running the container to do so.
But I do not know how to do so, whether I do that through the terminal or not. I tried looking for it through task manager but could not find it. By running rest of code I have newest image now but can’t start new docker since I still have old docker installed. Here is the process I did via terminal:

[williangalvani]

Hi @Jnyberg

I’m sorry, I missed a step! do
docker container stop BlueOS-Water-Linked-DVL
and then
docker rm BlueOS-Water-Linked-DVL.

@EliotBR

EDIT: This step has been added to the instructions comment.

[Jnyberg (Julien Nyberg - SeaView Systems)]

Thank you so much @williangalvani @EliotBR you are lifesavers!! Yes I assumed missing one command just didn’t know code for it but going through those lines of code did the trick. Got DVL connected to BlueOS and then was able to get position hold to work right after! This is seriously great work by you guys.

Now as a follow up I am just wondering what exactly was the change we just did between when I originally ran the DVL extension to when I restarted the new docker. And also is that the process I will have to do for future reference. Like is the code I ran from github page (GitHub - bluerobotics/BlueOS-Water-Linked-DVL) different from one you gave above and always going to give me trouble? Or is it updated to the new docker now? Just wondering if every time I run the code I need to go through the process we did above.