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.
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?
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.
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.
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.
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
As far as I’m aware that should work, but for long term positioning accuracy it may be necessary to have occasional corrections from an absolute positioning system (like a GPS at the surface).
I believe it should show up in QGC’s telemetry widget via the DistanceSensor / RotationPitch270 option. It may also work via the ApmSubInfo / RangefinderDistance option, but I’m not certain.
Worked as supposed, but the “Set initial position” does not work. Any tip on how to get it working?
It didn’t work for me, I added both parameters, but none showed any distance. Is there any way to test if the message is being sent? Or any parameter to set for the distance sensor get it from the DVL?
Thank you
Hi @fhmrocha . Can you share your RNGFND1_ params in QGC? A picture is enough. RNGFND1_TYPE should be set to MAVLink, and RNGFND1_ORIENT should be DOWN
Hi @williangalvani ! The RNGFND1_TYPE was set to 0, I set it to 10 (MavLink) and now it works.
Would it be enough to install a GPS (like ublox m8n) on the GPS connector of the Pixhawk? What kind of parameters would I need to set to get the position from the GPS on surface, and from the DVL when the ROV is underwater? Does de EKF already works like this?
That will likely require some tinkering to get working, and is in my to-do list. The final solution will probably be having a Lua script that switches ekf sources depending on depth/gps signal quality. Unfortunately I’m pretty busy with BlueOS and my development ROV has no spare penetrators right now to get the GPS in there.
Adding to Willian’s response, if you’re interested there’s some previous discussion about the current behaviour and the potential for surface GPS in this thread.
Hi !
After running “docker run -d --net=host -v /root/.config/blueos:/root/.config --name=BlueOS-Water-Linked-DVL --restart=unless-stopped williangalvani/blueos-dvl:latest”, the rov location can be found in QGC when rov location is fed through dvl-a50 gui. But when I try to run a waypoint mission, the QGC throws a warning: BAD NAV ALT 100.0 and the mission does not start!
Please suggest what is wrong with my approach to run the system with A50DVL!
I would recommend installing the DVL-A50 extension through the BlueOS extensions manager now, in recent stable versions of BlueOS. The command-line instructions were intended for before the extension manager existed.
I assume that’s a warning that you’ve tried to specify an altitude of 100.0 m for one or more of your mission waypoints, which an ROV or boat is unable to achieve (since boats are constrained to close to 0.0m of altitude, at the water surface, and ROVs go downwards from 0.0m into negative numbers representing the depth below the surface).
