The DVL functionality is available in Companion 0.0.31 (it doesn’t require a git branch anymore - apologies that we apparently haven’t updated that documentation yet), which also includes a change that explicitly avoids sending data to the autopilot if the DVL is reporting it as invalid. Previously those values were sent through with a confidence of 0%, but the vehicle was consuming them anyway and using them as valid, which understandably isn’t very helpful. I would guess that change should at least stop the vehicle from running away in position hold (because it won’t let you engage position hold without a trusted position source).
For the missing parameters, ArduSub 4.1 is more recent than QGC 4.0.5, so QGC doesn’t know how to handle it properly, and it looks for old parameters that don’t exist in more recent ArduSub versions. QGC 4.1.4 should fix that, although QGC 4.2.0 was apparently released late December, so may be a better option to try first (because it’s more recent, so will have more bug fixes and some feature improvements).
On the compass spinning front, I’m not certain what the issue is there but in this comment it was mentioned that it seems isolated to QGC 4.0.5, so that may also be fixed by updating your QGC version.
Updated to QGC v4.2.0 - compass still spinning counter clockwise.
Updated Companion via the normal process on the system page of the Companion web interface (for various reasons, my clients aren’t able to flash the image - they would have to send the vehicle back to me).
*Companion 0.0.31 seems to have installed properly.
*Compass still spinning.
*EKF3 IMU1 stopped updating
*EKF3 IMU0 stopped updating
Position Hold mode not available.
Rebooted vehicle and restarted QGC.
*Compass was stable for a few minutes then started spinning.
*After subsequent reboots, the compass starts spinning as soon as there is a connection.
*Have recalibrated the compass a few times.
I’m unsure whether that will have worked correctly (the update process isn’t designed to handle an update from an arbitrary git branch), but assuming it’s not causing things to be obviously broken then it’s at least possible it managed to complete the changes it needed to.
As a heads-up, flashing an image will be necessary when upgrading to what is currently the BlueOS Beta, because it’s a ground-up rewrite and can’t be updated to from the previous software. Once that’s done however subsequent updates should be smoother, more robust, and also more granular, so definitely some wins there.
You may be able to just send a replacement SD card to your clients at that point, or perhaps it’ll be worth bringing in their vehicles and doing an electronics upgrade to a Raspberry Pi 4 at the same time or something (which is supported by the new software)
Not sure what’s going on there - I believe there have been some other compass spinning issues reported previously, but I’m waiting on a response from the software team on how to fix/avoid the issue so will have to get back to you.
Thanks @EliotBR .
I’ve installed Companion 1.0Beta5 but I can’t really resolve DVL issues until I get the compass to stop spinning.
Also, each time the system boots, the direction and speed of the spinning is random
Following up on this, @williangalvani has recommended trying the latest ArduSub beta firmware because it’s very recently been updated, and he hasn’t come across the compass drift issue on that version. It should be possible to update to from the Companion web interface System page, or via QGC if you directly connect your Pixhawk to the topside computer, or from the Autopilot/Firmware tab if you’re using the BlueOS Beta (select “Sub” for the vehicle, wait for the available firmwares to load, then Beta is the bottom option in the dropdown).
I installed Ardusub Beta - Compass stopped spinning but I got an ‘Depth Sensor is not connected’ alarm when I put the vehicle in Depth Hold Mode. I Reverted to STABLE-4.0.3 and got the depth back, but the compass is spinning again.
I haven’t looked into what’s required to get the DVL talking now. I figure there’s no point until the compass is sorted.
DVL has a good lock and I had rebooted the vehicle and DVL.
I rebooted the vehicle again to get a new, smaller log file to share and now it can’t connect to Ardusub (video and companion are working) Here is the last log 2022-02-01 09-56-17.tlog (2.7 MB)
before I rebooted.
Go to “Extensions / Extension Manager” (in the sidebar)
Install the BlueOS Water Linked DVL extension
Wait for “DVL A50” to appear in the Extensions section of the sidebar (it may take a little while to install and start up)
Access the DVL interface and set the current position
The vehicle’s position should now be shown in QGC
The ArduSub parameter setup on that integration page is still relevant, but in general the docs at ardusub.com are currently “stale”, and not being actively updated.
We’re in the process of transitioning the documentation to a new system (which the existing BlueOS docs are already using), while also creating proper documentation for ArduSub 4.1 and BlueOS 1.1-beta, so unfortunately there’s a flux period at the moment where there are two documentation locations, and the latest beta features (including the details and usage of the new extension system) do not yet have clear documentation available.
I understand that can be a source of confusion while the transition is ongoing, but (as something to forward to) the new system should allow us to more easily and clearly document features in different versions, and provide several other improvements that will make our documentation more consistently available and correct going forwards.
I believe that’s a known bug in BlueOS 1.0.1 (the latest stable), but it should be fixed in recent beta versions