Ongoing DVL-A50 issues

I have a couple of BR2’s with DVL-A50’s as well as some I’ve fitted out for others. I’m not sure If it’s something I’m doing, but they all have ongoing issues:

  • Compass constantly spinning on boot up - sometimes X asix, sometimes Y axis. Sometimes rebooting fixes the problem, but it’s a pain have to remember to always check.
  • Vehicle runs away when put into position hold mode.
  • Error message 'Parameters are missing from firmware. You may be running a version of firmware QGC does not work correctly with or your firmware has a bug in it. Missing params: 1:COMPASS_PRIMARY

QGC version 4.0.5
Companion: revert-point-5-g6abbfbe
Ardusub Version 4.1.0

The PID’s and other parameters have been set as per DVL Integration · GitBook


Hi @gcelec,

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.

DVL Integration · GitBook hasn’t been updated.

  • 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.

Indeed - that should now be fixed :slight_smile:

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) :slight_smile:

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.


Make sure that BARO_EXT_BUS is set to 1.
Please let me know if that solves the issue.

Hi Willian,
Yes, BARO_EXT_BUS was set to 1. Still not getting any depth.


try settting BARO_PROBE_EXT to 768 and then reboot. I’ll check why that is not the default.

That worked. Now it can go into depth hold mode with Ardusub BETA.

As for the DVL, do I go to Available Services to see if it’s running?

Hi, we haven’t finished the thirdy-party product integration yet, so for now you need to ssh into the Raspberry PI (username: pi password: raspberry) and run this:

sudo docker run -d --net=host -v /root/.config/companion:/root/.config --name=companion-dvl-all-in-one --restart=unless-stopped williangalvani/companion-dvl:all-in-one

Thanks. Now the Waterlinked DVLA-50 at port 9001 is listed as an available service and the Status is Running at http://companion.local:9001/ but vehicle still can’t go into Position Hold mode.

The dvl driver adjusts most required parameters for it to work. It may require a reboot, though.

Is there a good lock in the dvl?

If there is a good lock but you can’t get into position hold after restart, please share a log so I can take a look at your parameters.

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.

You need to set these additional parameters (EK3_SRC1_***). I’ll update the code so others trying to use it don’t go through the same hassle.

1 Like

These are the parameters I changed:
EK3_SRC1_POSXY from 3 to 6
EK3_SRC1_VELXY from 3 to 6
Still can’t go into Position Hold.

Update: I can get Position Hold but the vehicle runs away. DVL’s Dead Reckoning show it drifting so the vehicle runs away in Position Hold mode.

Hi Willian,

I’m integrating another DVL A50. Has third-party integration been added to BlueOS yet? I’m just wondering how much of the information in this thread is still relevant or if this is a new way of integrating it.
The Ardusub integration page still guides you to for configuration.

Also, I’m trying to use the Web Terminal to install the DVL service, but I just get a spinning icon.

Hi @gcelec,

The DVL integration is expected to work, but still requires being installed as an extension.

You should be able to

  1. Turn on Pirate Mode
  2. Go to “Tools / Version Chooser”
  3. Update to the latest BlueOS beta release
  4. Go to “Extensions / Extension Manager” (in the sidebar)
  5. Install the BlueOS Water Linked DVL extension
  6. Wait for “DVL A50” to appear in the Extensions section of the sidebar (it may take a little while to install and start up)
  7. Access the DVL interface and set the current position
  8. 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 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 :slight_smile:

I have DVL connected and operating but can’t get position_hold mode to engage.

The following are the versions of software I have currently:

From GUI latest 1.0.2 is what is installed from extensions Software Version 2.2.1 (says new version available 2.4.0)

Navigator Firmware 4.1.1 beta
BlueOS 1.1.0 – beta 23
QGC 4.2.3

I was going to try and reload a different BlueOS but now the BlueOS software says that there are not WIFI networks available even though I am connected to internet on separate page in same browser. Rebooted computer, ROV etc several times and nothing works.

In addition I am having issues with stabilize and depth hold modes have become jerky and unstable. Double checked all recommended parameter / PID changes changes for DVL integration and all good.

If I was to start all over could you tell me all the Firmware / Software versions you recommend?

Since I can’t connect via BlueOS to internet do I need to flash a new SD Card?

1 Like