Trying to integrate a DVL

Third Party Products
, ,
1

We are trying to integrate a DVL running on a Blue Robotics Navigator.

The DVL data is received by our own application running on the companion computer and forwarded to ArduSub via MAVLink2Rest.

Our goal is relatively simple:

  • GPS provides the absolute horizontal position while available.
  • The DVL provides horizontal velocity/odometry when submerged.
  • Ultimately we would like ArduSub/Cockpit to use the DVL for position hold and later for running search patterns.

At the moment we are testing ExternalNav integration.

Current EKF configuration:

  • AHRS_EKF_TYPE = 3
  • EK3_ENABLE = 1
  • EK3_SRC1_POSXY = GPS
  • EK3_SRC1_VELXY = ExternalNav
  • EK3_SRC1_POSZ = Baro
  • EK3_SRC1_VELZ = None
  • EK3_SRC1_YAW = Compass
  • EK3_SRC_OPTIONS = FuseAllVelocities
  • VISO_TYPE = MAVLink

We initially sent VISION_SPEED_ESTIMATE at approximately 5 Hz.

We then added VISION_POSITION_DELTA. The message is definitely present on the MAVLink bus and MAVLink2Rest shows valid data.

Example:

{
  "angle_delta": [
    0,
    0,
    0
  ],
  "confidence": 100,
  "position_delta": [
    -0.0006236645858734846,
    0,
    0
  ],
  "time_delta_usec": 311832,
  "time_usec": 41479512,
  "type": "VISION_POSITION_DELTA"
}

The position delta is calculated from the DVL body-frame velocities:

  • X = Forward velocity Ă— dt
  • Y = Right velocity Ă— dt
  • Z = Down velocity Ă— dt

The actual DVL measurement timestamp is used to calculate time_delta_usec, so duplicate samples are not integrated twice.

MAVLink2Rest confirms that VISION_SPEED_ESTIMATE and VISION_POSITION_DELTA are being transmitted. The ArduSub vehicle itself is system ID 1/component ID 1; our ExternalNav messages are transmitted from a separate MAVLink system/component.

However, EKF3 does not appear to consume/fuse the ExternalNav data. Moving the DVL produces the expected changes in VISION_POSITION_DELTA, but we do not see the corresponding effect in the EKF/local position.

Before we start implementing our own complete dead-reckoning solution outside ArduSub, we would like to understand whether we are missing something in the ArduSub/EKF3 configuration or in the MAVLink messages.

A few specific questions:

  1. Is VISION_POSITION_DELTA supported as an ExternalNav velocity/odometry source in current ArduSub/EKF3?
  2. Is EK3_SRC1_VELXY = ExternalNav sufficient for this, while keeping EK3_SRC1_POSXY = GPS?
  3. Does ArduSub require ODOMETRY or another MAVLink message instead of/in addition to VISION_POSITION_DELTA for DVL integration?
  4. Does the MAVLink source system/component ID matter for VisualOdom/ExternalNav messages?
  5. Are there specific EKF logs/innovations/status flags we should inspect to verify whether the ExternalNav measurements are being received but rejected by EKF3?
  6. Is there a recommended configuration for the common use case of GPS at the surface and DVL dead reckoning underwater?

The DVL itself is working correctly, has bottom lock, and produces stable Forward/Right/Down velocity measurements. We can also obtain North/East/Up velocity from it.

Any pointers on where to look next would be greatly appreciated.

2

Hi,

I’ve had some success using a GPS with Waterlinked’s DVL.
Try sending VISION_POSITION_DELTA messages at 10-20hz (@EliotBR remembered SPEED_ESTIMATE doesnt seem to work), when it works, the ekf will say “EK3 fusing odometry” and/or “EK3 started relative aiding”

Here’s the default parameters we set for waterlinked dvl:

Here’s a log of a successful flight with my gps+dvl config:

00000156-good-dvl-gps.BIN.params (22.0 KB)

00000156-good-dvl-gps.BIN (16.0 MB)
I also recommend tightening VISO_POS_M_NSE/VISO_VEL_M_NSE and possibly loosening EK3_POSNE_M_NSE

Let us know how it goes!

3

To clarify, I previously tried to enable using that message in the Water Linked DVL Extension, but the current state of discussion is that it’s unlikely to have good performance because the autopilot doesn’t ingest the covariance matrix (it should in development firmware releases, but that doesn’t include 4.7, which is the current stable/beta target).

As I understand it the autopilot ignores anything that is not in its MAVLink system, since that generally corresponds to things from other vehicles. I believe different component IDs should be fine, since they’re supposed to be representative of different components within a single system.

That said, the Water Linked DVL Extension apparently sends messages as system 255, targeted at component 0, which is normally the system used by a control station software, and target used for all components (which is probably not great, but likely adds robustness if there’s only one system involved) :man_shrugging:

4

Thank you, I am going to test. I tell you the results!