Apologies for the delay on this. You should be able to just use 2.0
A post was merged into an existing topic: GPS data not used?
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.
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:
I’m sorry, I missed a step! do
docker container stop BlueOS-Water-Linked-DVL
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.
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.
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,
- Is the issue occurring consistently, or just sometimes?
- Does it help to set the position as the first thing you do when you turn on the vehicle, before it gets put in the water / moved around?
- If you try to arm the vehicle, do you get any additional information about the pre-arm check error?
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;
To manually download 2.1.0 for your DVL enter your DVLs CHIPID into this link;
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.
Hey Elliot! Does the DVL-A50 works with stable 4.1.0 ArduSub? Or do I have to use Beta? Thank you!
I’ve moved your comment here, because it’s more relevant to this topic than the original thread
ArduSub 4.1.0 stable should work fine (it’s actually the same as 4.1.0 beta at the moment). Note that as per Scotty’s comment above our old Companion software only supports the previous DVL firmware version. If you want to use the new one you’ll need to install BlueOS and its Water Linked DVL extension.
Ok, thank you very much!!
I would like to know if it is possible to do waypoint navigation with DVL.
And also, I activated the option to use the DVL as rangefinder, but I couldnt find what I must choose on QGroundControl to show the distance. How can I do it? Thanks