Water Linked DVL extension failing to connect after reboot


I have been using a waterlinked DVL on a ROV recently and its up and working mostly fine.
There has been one significant issue however, is that between boots of the ROV, the DVL will lose coms to QGC (in blueOS, under status, it says cannot talk to dvl at, looking for it in the local network) in the blue OS firmware. I can speak to the DVL separately, so its still talking to it, but not to blueOS. I can get it working again by running the red-pill code found here → WaterLinked DVL A50 integration not working - #17 by Jnyberg, however I do have to do this for every boot to get it to communicate.

Is this a known issue and/or does anyone know how to fix it?

1 Like

Hi @Qlowe,

I’m not certain what’s going on here, but I suspect there may be an issue with an old DVL image still being around and starting up in the place of the latest one. You can try completely removing the old images by running

# completely remove (delete) old images
export OLD_IMAGES=$(docker image ls --format='{{.Repository}}' | grep -i dvl)
docker image rm $OLD_IMAGES

just before the

# pull the new image and start the new docker

section and see if that helps.

If that doesn’t resolve the issue then please run red-pill and then provide the output of docker ps -a and docker image ls, as well as the BlueOS version you’re running, and the hardware it’s running on (e.g. Raspberry Pi 3/4), so we can try to replicate and fix the problem :slight_smile:

Gave it a go, seems to fail to find things i don’t know if that’s an issue. Still fails to work after rebooting.

this is all on a raspberry pi 4

with a navigator board.

It’s also worth noting that i did manage to get it back up and running again after that boot but now i cannot go into position hold mode. ignore this, seems to be working fine. Failing on reboot is still an issue however.

My bad - the second command should have been docker image rm $OLD_IMAGES - I forgot the “image” part, so it just tries to remove the stopped dvl containers, which already happened in the step before. I’ve edited the comment to show the correct command, so would be good if you can try again with that :slight_smile:

Tried this, however the problem still persists. It did seem to clean out the old install however, if that makes any difference compared to the last time. Could it be the DVL firmware or something like that which is in the wrong version compared to what’s supported by blueOS? its 2.2.1 if that helps.

Hi @Qlowe,
Can you share the output of docker logs blueos-dvl ?


sorry, try this instead:
docker logs BlueOS-Water-Linked-DVL

Also, can you try getting the latest version and check if it works? if you run docker image ls it should show to be less than 24h old

it spits out a lot of text and i can’t seem to get the text file to work correctly to share that, but essentially it does this, then keeps spitting out invalid reading. a little way down it tries to set the origin but gives an invalid reading:

as well before eventually just spamming:

this is the output from the docker image ls at the moment:

will update again shortly.

The “invalid reading” thing is expected. it the dvl data is being read but has low confidence, it is expected when out of the water.

Let`s see how the new one works. It was last updated 5h ago.

So i ran the update and it works as usual
before going to back to this post reboot

this is the output post update:

and the output from the previous command:

It actually seems to be running. it is weird that you get that in the browser instead of “running”.
Do you have your ROV in water? I noticed it is not saying it is ignoring bad data, which is weird if it is in water.

Is there anything unusual in your setup? are you runnning Ardusub 4.1.0?

The last test was done in water, the rest weren’t (mainly due to cooling in between updates and it was just easier for me to chuck the rov in the test tank for the last one). Currently I am using ardusub 4.1, though it is a custom branch for my thruster configuration which @qnguyen can inform you of exactly what was changed. I don’t think this should have a specific impact on the dvl though, since everything else is standard outside of that.

Is it not “Fusing odometry” ?
Can you share a tlog so I can take a look at what is going one?

Is your issue still that after reboots the dvl is not found? but it works normally if you restart the extension manually?

Yes, if I reinstall the extension, it works perfectly, until I reboot the ROV, which is where the extension stops working and I lose all connection to it in QGC.

Hi @williangalvani,

We have forked our latest Sub-4.1 from ardupilot github page and compiled it, everything was untouched except for AP_Motors6DOF.cpp file in the library to create our own custom frame for our ROVs. Aside from that, I believe we are up to date with our current version.

Sounds good.

So I can try to replicate the issue here, are you power-cycling the ROV? rebooting via mavlink? What is the exact procedure to replicate?

Is it not “Fusing odometry” ?
Can you share a tlog so I can take a look at what is going one?

Batteries on the ROV just finished charging so I will have a look at this in a bit.