Home        Store        Learn        Blog

Companion 0.0.28 features in DVL branch

I have been out testing it today, the rangefinder function do not work after the update. It get some errors in the dvl-service:

PosHold seems to work fine.

Here is a video from todays dive in Saltstraumen Northen Norway


That looks like an internal error with mavlink2rest - I’ve passed it on to the dev team and will get back to you as soon as I can. Apologies that there seems to be a new error here, I thought these things had been checked before it was released.

Beautiful footage, thanks for sharing :slight_smile:

1 Like

I’m told this is fixed now. Apparently a mavlink message got changed (unexpectedly) without us knowing about it, so one of the fields was missing and it wasn’t parsing correctly.

1 Like

Only error showing up now is : " Error fetching data for DVL: ‘vx’ "

Rangefinder is working. We have only tested it our tank this morning, so im gonna give you a feedback when we have been in Saltstraumen testing.

Thanks for the fast feedback @EliotBR

1 Like

Given it’s seemingly working then that’s likely not a problem, but I’ve passed it on to the software team in case it does need to be fixed. I’m unsure if it’s complaining that the DVL is not returning a sideways velocity, or if the DVL is requesting/wanting one from the ROV’s IMU and not getting it.

EDIT: Just had a quick look at the dvl code and it seems like that error message occurs if a message from the dvl doesn’t include the expected components. If the velocity and position are updating correctly then likely that’s just caused by unrelated messages, which ideally should be handled separately but shouldn’t make a functional difference to the performance, but if the position and velocity aren’t updating at all on the map then there are bigger issues at play.

Alright, cool. Hopefully it’s all working correctly now, but let me know if anything else comes up. I should at least have a response by tomorrow on whether the ‘vx’ error is a problem :slight_smile:

No worries - thanks for your fast confirmations and responses, with error messages included. It makes it much easier for problems to get fixed efficiently :slight_smile:

Here is the log.

Position hold is working, rangefinder is working. I tried to set new origin but i did not get an update on the map.

We are live from saltstraumen: Twitch

Good to hear! Pretty sure the error message is just from the current parser, which tries to treat every message like a velocity message. The Water Linked DVL API mentions a position report message that gets sent at 5Hz, which seems reasonably close to the error rate your log shows. I made an (untested) pull request to fix the issue here, but I’ll have to let the software team determine if that’s the right course of action.

I haven’t used the dvl setup before, so out of my depth with this one - have passed it on.

1 Like

Yes everything is working now, we are using the DVL on daily dives in Saltstraumen

We are also using UGPS G2 there to get position. But the new dead reckoning function in the DVL software is working great for navigating.

That PR is now merged, but it’s not yet ported into the current release because it’s non-essential, and likely better to include in the next meaningful release instead of polluting the 0.0.28 build with various versions that we can’t tell the difference between without checking code.

Unless you’re using your own custom code to set that up, the new dead reckoning message is currently not actually being used by ArduSub. ArduSub does its own dead reckoning using the velocity measurements fed in from the DVL, which is what our dvl branch is for. Amusingly the dead reckoning position messages are actually the cause of the “Error fetching data for DVL: ‘vx’” issue - previously there was only the velocity message type, so there was no reason to handle anything else, but now there are also regular position messages, and they weren’t being handled in a nice way in our dvl code.

That being said, we’re planning to do a comparison of the position outputs from [ArduSub+DVL velocities] vs the [DVL position] outputs, because it’s possible the ArduSub results could be made (even) more robust by taking in the DVL position estimates instead of measured velocities. Glad that it seems to be working well for now though in the current state :slight_smile:

1 Like

Thanks for the help. Awesome work you and your team are doing :smiley: Keep up the good work :+1:

1 Like

Well, I bit the bullet and updated by following following the dvl installation instructions. Now I have video, but no connection.

Odd - I just did the install via git and get the same companion ‘Version’ as you, and it connects fine to my autopilot. It also seems to have worked for Al and Willian, so this seems like an isolated issue.

A few questions:

  1. Does your Pixhawk still appear as a Detected Serial Device on the System page?
  2. Have you checked if the ROV connects to QGC?
  3. Were you using a non-standard network configuration that perhaps hasn’t transferred over fully when you updated? (e.g. check to see if the IPs and ports are set as expected)

Hey Eliot,

Yes, the PIxhawk does appear as a Detected Serial Device on the System page:

The ROV doesn’t connect to QGC, but there is video:

That all looks normal to me, except the not being able to connect. Are your companion and topside computer on the 192.168.2.x sub-net? Since the video is getting through you can check that by the IP address that’s in the gstreamer settings from the Camera page (and your companion IP address is the one you’re using to access the web interface).

Beyond that my best suggestion is going through the relevant troubleshooting steps (we’ve already covered some). I’ve flagged this with the software team already, since it seems unexpected given your system was working before the update.

Working through the troubleshooting steps :
Verify Autopilot USB Connection; I can connect to QGC with the USB cable connected directly to the laptop.

Check MAVProxy section; These are the results after entering the screen -r mavproxy command:

I reinstalled Ardusub by connecting the Pixhawk directly to the PC and using QGC’s firmware upgrade application.

I’m not sure what to try next, besides starting to replace hardware, but I’m pretty sure that’s not the problem.

Hi @gcelec ,

It looks like your update failed somehow. I have been seeing issues with pypi.org a lot more than I’d like too…

I recommend you either flash the new image, or try installing the missing dependencies:
As it is missing “future”, run sudo pip install future and reboot. Hopefully that is enough.


I flashed a new Companion image to the Pi micro SD card at now I have a vehicle connection.