I just recently purchased a DVL A50, planning to integrate with ArduSub 4.5. I know there is already plenty of resource online, but all are catered towards BlueOS. I am using a Jetson Orin Nano (Ubuntu 20.04) with Pixhawk 6C. As far as I read online, the steps involved in the integration are:
Use Waterlinked GUI to install new drivers, calibrate sensor and set static IP to be on the same network as the Jetson
Test if everything works will in the GUI first (no integration with QGC yet)
Somehow forward the data from DVL in the form of VISION_POSITION_DELTA to the autopilot.
I found this repo BlueOS-Water-Linked-DVL which does that for BlueOS. However, if I am not using BlueOS, how can I use this repo (or other methods) to integrate DVL with ArduSub?
Hi @Luc001 -
Using BlueOS is expected for use of the DVL A50, but you may be able to make it work by running the software in that extension. It is receiving the DVL messages over ethernet and forwarding them in the correct format to the autopilot process - you would direct this to the comm port your Pixhawk is using.
Is there a reason you’re avoiding BlueOS? It is possible to use BlueOS alongside ROS…
Hi @tony-white
We are already using the Jetson Orin board for other complex autonomous code, so we do not desire having another RPi board just to install and run BlueOS. If only BlueOS is a library that we can install plug-and-play on other systems as well.
I assume the software extension that you mention is this BlueOS-Water-Linked-DVL. I will experiment with tweeking this repo to make it work.
I am so sorry for the late reply, totally missed this message. It is the first time I see docs, looks amazing.
Nevertheless, I think it may not be suitable for our application bcz we are using pymavlink with ros noetic for AUV competitions, and we already use the pymavlink tutorial to write the ros package for our pixhawk. I have found the DVL-ROS driver and figured that I can use the message published by dvl topic and send it to pixhawk via one of the mavlink message format.
But here I have a question. In the BlueOS extension, it seems that the DVL data can be sent via one of the following message formats: “VISION_POSITION_DELTA”, “VISION_POSITION_ESTIMATE” and “VISION_SPEED_ESTIMATE”. Is there a message format that is the most ideal? My assumption is that position_estimate is best because it uses all sensors inside the dvl (imu, gyro, mag and dvl itself) to fuse with dead reckoning by the pixhawk.
ardusub.com in general hasn’t been updated in quite a while - we’re working on integrating ArduSub docs with the general ArduPilot ones, and doing a major update in the process.
The DVL BlueOS Extension source sets these parameters, if that’s of interest, although if you run the Extension as a docker container on your device then it should handle that for you, as long as it’s able to connect to the autopilot
From your link, it seems that vision position delta is best. To clarify, the “angle_delta” can be obtained from the change in orientation of dead reckoning message, while the position delta can be computed by taking v * dt, as written in the BlueOS extension code.
For your suggestion of running the extension in Docker, does it mean that the extension will be connected to one port of the pixhawk, while my pymavlink script will connect to the other port? Bcz usually the pixhawk exposes two ports “/dev/ttyACM0” and “/dev/ttyACM1”?
Unfortunately it’s not that straightforward - you generally need a MAVLink router of some kind to make multiple MAVLink connections to a single device (BlueOS offers a few different options, which can be installed independently if you don’t want to use BlueOS).
There’s some extra complexity because the Water Linked DVL Extension expects to be running together with BlueOS, so it also makes use of the MAVLink2REST service which BlueOS uses to provide a web API to MAVLink, instead of the Extension needing a dedicated MAVLink Endpoint from a router. That makes extra sense when multiple services/Extensions want to connect via a REST interface, but is effectively just extra steps/configuration for a stripped back setup that’s using only a single Extension without BlueOS involved.
This is new to me but something really worth exploring! So far I ve been using pymavlink on one single port; any additional sensors are integrated via ros topics. It has worked so far, but I am not sure what’s the potential drawbacks in the long term. For the current case with DVL, I most likely will take reference from the BlueOS DVL extension and implement it in our own repo using VISION_POSITION_DELTA_SEND command.
Effects of this largely depend on the sensor type(s), and how much / whether they’re integrated with the autopilot. If the autopilot doesn’t need them for control then it doesn’t need to receive those values at all. If you’re using them as part of its internal control algorithms then it may be preferable to connect them directly to the flight controller board, but if there aren’t existing drivers for them in ArduPilot then a higher level communication protocol is the most straightforward approach, although it may require writing some integration code to send those messages (like for the DVL).
If it’s affecting the dead reckoning then it’s not exactly “not in use”, is it? You can disable the DVL while the vehicle is in air, or if there are times where you don’t need a position or velocity estimate, but otherwise it should be running.
I’m a little unsure what you mean by this. There’s some potentially relevant discussion about the autopilot’s internal GPS origin, which can only be set once per boot, as well as a process for updating the current position estimate if you have some external correcting factor (e.g. from a GPS unit, or if the DVL’s dead reckoning seems more trustworthy than the autopilot’s).
That is one option, but it’s in the local reference system, which then requires manually correcting with the GPS_GLOBAL_ORIGIN if you want it in a global reference frame. It may be simpler to consume the GLOBAL_POSITION_INT messages if you want a global position
I imagine that I only want to turn on the dead reckoning when the vehicle is armed (i.e. ready to go), at which point I will reset the ekf origin so that the dead reckoning take reference from this starting point every time the vehicle is deployed again. When it is not armed, dead reckoning will be turned off.
From the threads that you sent, it seems that I should send GLOBAL_VISION_POSITION_ESTIMATE (or VISION_POSITION_ESTIMATE, I am not sure which one), with a reset counter so that the ekf jumps to this position. Could you guide me to some example code for this? The documentation is a bit vague about how the reset_counter should be used.
For obtaining the current position of the vehicle, I am more interested in where it is relatively to the original “starting point” set above, and not so much the lat and lon, as the vehicle will likely be deployed in a pool with no gps. In that case, what do you suggest to obtain the vehicle’s xyz position (in meters)?
Here’s the relevant part of the DVL Extension (noting that it uses MAVLink2REST, so may have a slightly different interface to other APIs / libraries.
There’s some relevant discussion, but basically, keep track of the value, and when you want to provide a “known” position to force the vehicle’s state tracking to reset to, increment the reset_counter value.
In that case your original suggestion of LOCAL_POSITION_NED seems appropriate
After reading some other thread, it seems that I don’t need to reset the home position every time the vehicle is armed. Though I still need to send the GPS_GLOBAL_ORIGIN at the start in order for the EKF to start working.
I will experiment with the DVL and see how it goes! Thank you so much @EliotBR !
Hi @EliotBR , just to check with you, could there be any possible mistake here? I think mavlink message requires angles in radians, but the attitude data received from json message will be in degrees.
You’re correct that the DVL’s attitude data needs conversion before being sent over MAVLink, but that is actually being handled already, elsewhere in the repository:
I agree that this is implemented somewhat confusingly, which I remember having mentioned before internally, so it’s not just you who’s been mislead by thinking that the self.mav object would be a raw wrapper around the MAVLink specification of the message types it includes
Thank you for your reply! It is slightly confusing yes haha.
May I check if there are any modes that would allow depth hold, poshold and be able to manual control it as well? As I understand, GUIDED is for waypoints control but it does not necessary hold it position when being pushed around, while POSHOLD is just to hold position but cannot use MANUAL_CONTROL.
Hi @Luc001 -
When in position hold mode, the vehicle responds to user joystick input normally - but when releasing control, the ROV works to automatically maintain position…
It is slightly confusing yes haha.