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.
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?
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.
Apologies for the delay on this. You should be able to just use 2.0 
I have my DVL configured to IP Address: 192.168.2.95. And on dashboard I am getting a valid velocity reading.
I have the same problem with BlueOS integration and seems that it is something wrong with the driver.
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
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.
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:
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.
@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:
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.
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.
The change we did stopped and removed the old container, pulled @williangalvani’s current work in progress image, and started it as a container. Willian’s image is expected to work, but will be getting some internal cleanup and minor robustness improvements before we release it officially.
If you’re wanting to install Willian’s version on multiple systems that already have a previous dvl extension installed you’ll need to follow that process on each system, but for new systems it should be fine to just do the first and last commands (e.g. red-pill and then
docker run -d --net=host -v /root/.config/blueos:/root/.config --name=BlueOS-Water-Linked-DVL --restart=unless-stopped williangalvani/blueos-dvl:latest
). Note the williangalvani/blueos-dvl:latest at the end, which tells you which image it’s using.
You shouldn’t need to pull a new image until either Willian adds changes to his to fix an issue, or we release a new stable one from the main bluerobotics/BlueOS-Water-Linked-DVL repository (which should be this week or next). The container should automatically restart itself when you turn on your vehicle, so you shouldn’t need to run code via the terminal unless you’re changing something.
Hi guys!
Thank you for the update @williangalvani, @EliotBR !
So as you can see from the screenshot it is - “Running”
But I am not able to set a "Set a current location ". In the QGC it shows me the location 0 0 and keeps mentioning that EKF is updating.
At the sensor tab it is saying few errors:
I think that I am missing something if you can prompt something about it i would highly appreciate. Thanks.
Hi @valeri2a,
One of the intended improvements with the updated extension is being able to specify the GPS position multiple times. I spoke with @williangalvani and we’re not certain what’s going wrong in this case, but we’ve got a couple of ideas that Willian’s planning to look into next week.
Out of interest,
Hello!
The issue occurred only once at the second reboot after driver installation. Firstly the GPS position was not tracked.
At the moment it is working and I am able to check the orientation and movements in the QGC.
I believe that the problem occurs as DVL gets heated in the air environment.
FYI - I was able to set the position for multiple times and it was showed in QGC.
Once the current location is changed in the driver page, QGC starts to talk about updating of EKF parameters.
Thanks for the extra information!
Hmm, was that just an autopilot reboot, or a whole vehicle power cycle?
I’m thinking if only the autopilot gets restarted then the DVL service may have issues with persistent information from the previous autopilot connection that could carry over into the new one and make it think it’s already been configured.
Glad to hear it!
Please note that the A50 and A125 software version should be rolled back to 2.1.0 when using Companion and for the time-being you also need to roll it back to 2.1.0 when using BlueOS.
BlueOS will be updated shortly to work with the latest DVL software (currently 2.2.1) however Companion will not be updated and you will always have to revert ot 2.1.0 when using Companion.
Refer to the manual software update process as detailed here;
https://waterlinked.github.io/dvl/sw-update/#offline-software-update
To manually download 2.1.0 for your DVL enter your DVLs CHIPID into this link;
https://update.waterlinked.com/api/v1/download/CHIPID/2.1.0
Hello!
I just want to notify you that DVL A50 software v. 2.2.1 is working with BlueOS 1.0.1 and shoved in the QGC as well. There might be some difficulties while initializing the current location, but the data is showed correctly, at least in the QGC.
Anyway, we will wait for the update. Thanks.
