Integration of Wayfinder DVL onto BlueROV (still troubleshooting)

Have found time to work on this issue again. Wanted to document my progress to see if anyone else is struggling. Using Companion software 0.0.20 and ArduSub version 4.1.0. Currently have a Wayfinder DVL interfaced with the BlueROV Raspberry Pi. BlueROV2 is sitting on a bench out of the water. Have been following the integration guide found here: Integration – Teledyne RDI
I have downloaded and installed the DVL python drivers found here: TM software Portal.

Have found that the guide cannot be followed verbatim. First difference was step 21. Found that ‘~/mavproxy.params’ is actually ‘~/mavproxy.param’ (no ‘s’). Next, in step 21, need to add ‘–out tcpin:’. Adding the line without adding the --out prior to the address will break your connection to Qgroundcontrol.

Step 22 has you “add” the integration script. Not sure what it wants me to add the script too… startup script? mavproxy.param?

It turns out that there are several integration scripts. The one I have been running can be found buried in the /integration/blueROV folder called ‘’. When running this script, I was able to get it to the main_loop() function. However, an if statement is expecting a message type of ‘ATTITUDE’ and it’s receiving a message type of ‘GLOBAL_POSITION_INT’ instead (gives status of ‘unknown’). Example of output (I added some print statements to the source code so I could see what was happening):
message.get_type(): GLOBAL_POSITION_INT/n
GLOBAL_POSITION_INT {time_boot_ms : 3626408, lat : 0, lon : 0, alt : 0, relative_alt : -23, vx : 1, vy : 1, vz : -3, hdg : 20217}

message.get_type(): GLOBAL_POSITION_INT/n
GLOBAL_POSITION_INT {time_boot_ms : 3626508, lat : 0, lon : 0, alt : 0, relative_alt : -22, vx : 1, vy : 1, vz : -3, hdg : 20217}

message.get_type(): GLOBAL_POSITION_INT/n
GLOBAL_POSITION_INT {time_boot_ms : 3626608, lat : 0, lon : 0, alt : 0, relative_alt : -21, vx : 1, vy : 0, vz : -4, hdg : 20217}

Interesting that it’s a GLOBAL_POSITION_INT message. I would have though that it would have been a VISION_POSITION_DELTA message as described in this post: ROV Position Hold and Non-GPS Navigation! - Blog - ArduPilot Discourse
No idea if it’s properly configured in accordance with step 22…

Maybe the DVL needs to be wet in order to transmit the correct messages?

Step 24 is also different (parameter configuration). Some of the parameters do not align with what’s found in Qgroundcontrol. I’ve set them as best as I can.

Anyone know of a way that I can verify that the sensor is being read in Qgroundcontrol? I’m getting to the point where I feel like I just need to throw it into a pool and see what happens.

Have made some progress. Moved over to BlueOS. Not sure if that made a different from the original Companion version. Created two endpoints (pirate mode): TCP server and TCP Client. Both at port 14777. Not sure if I need both client and server but it seems to work…

Changed parameters are as follows:
EK3_SRC1_POSXY = ExternalNav (6)
EK3_SRC1_VELXY = ExternalNav (6)
EK3_SRC1_POSZ = Baro (1)

Modified to have spoofed x,y,z velocities in the wayfinderDataCallback function:
dataObj.vel_x = 1.0
dataObj.vel_y = 1.0
dataObj.vel_z = -0.0
dataObj.vel_err = 0.005

Running the script now, I can see that I have a VISION_POSITION_DELTA from the modified python script:

It shows up under System 255 on the MAVLink Inspector.

Next I ran the script also included in the Wayfinder-master/integration/blueROV folder. This set the home position of my vehicle. Arming the vehicle and running the modified script allowed me to see the vehicle move around on QGroundControl:

So I know that the script works with QGC and the Teledyne software says that my DVL is healthy.

Up to this point, all of my tests have had the DVL operating on the vehicle on a bench. The next step is to get the DVL wet and see if I can get some real velocities from the device.

1 Like

Hi @andygrayia,

Great to see you’ve managed to make some headway here!
Hopefully it works well with the actual DVL in water :slight_smile:

@Nathan_R07, I’m not sure if you’re working together, but if not it may be helpful to refer to the steps here :slight_smile:

Been able to progress here. I’ve been able to log some data by replacing the tcp:localhost:14777 by a UDP connection which allows communication between the companion and DVL. Still don’t know what prevented this to work with TCP though.

I also moved over to BlueOS which is way more convenient. I managed to integrate it and get some data in a single day ! I still have a few questions :
@EliotBR I noticed there was a Log Browser tab on the BlueOS Frontend, but found myself unable to download data from there and when trying to play them (by clicking the little play button), it opened a new tab but happened to appear empty, I was wondering if something doesn’t work or if it is normal as maybe not all functionalities are available yet ?

@andygrayia Did you manage to find the GLOBAL_POSITION_INT the vehicle logs ? I’m not sure where it’s supposed to be written. I saw the parameter through the MAVLink inspector, but once I put the ROV underwater and ran a quick test, I can’t find where it’s been saved

Thank you both for you help :slight_smile:

Hi @Nathan_R07,

Sorry for the delay on this. I’ve had half a response written for a while but then lost the post and just happened to come across it again in my TODOs.

The BlueOS Log Browser service is for dataflash (.bin) logs saved by the autopilot firmware. Getting Navigator logs works well, but getting them from a Pixhawk is currently a work in progress - it may work for new logs to be sent to BlueOS (in the latest beta version) if you set LOG_BACKEND_TYPE to MAVLink, and LOG_DISARMED to 0, but that hasn’t been extensively tested and may have some issues.

The play button should open the selected log in the UAV Log VIewer (which has been locally built into BlueOS), but that only works for valid logs (there are currently some empty ones being spuriously generated, and they don’t have any viewable data - they show up as having a size of 0.0 kB).

@Nathan_R07 Haven’t looked specifically at the logs for that variable. We had a successful test in a pool late last month. The vehicle appeared to maintain it’s position when disturbed (we pulled it around and it maneuvered approximately where it was previously). So I think we have it working. We saved the recorded logs and one of my co-workers has it on his “to-do” list to look at the file. I’ll ask about the Global_position_int when he gets started on it (currently on the backburner).