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 192.168.2.95, 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?
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
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
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.
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:
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.
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.
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.
