define DVL/ADCP messages

[smaria]

Often, Doppler Velocity Log and Acoustic Doppler Current Profiler come as a single device. If I understand the current DVL msg correctly, it can be enriched with current profile data for each of the beams.

From the workshop notes:

• velocity
• reference frame (depth)
• range (#)
• # good beams
• # bins
• frame of beams wrt sensors
• internal beamframe
• sensor timestamp
• time delta?
• velocity covariance
• configured sound velocity

I don't think all of the notes are represented in the current msg proposal, but I am also not sure I understand all of the suggestions from the workshop.

[narcispr]

I have no experience with Acoustic Doppler Current Profiler devices. The current message was designed for DVL devices only and it is based on the UUVSimulator DVL message. However, if adding some extra fields it can be used also as ADCP it will be great!

[ivaughn]

Any thoughts on:

• watertrack vs. bottom track?
• Figure-of-merit for each beam? RDI has some per-beam correlation or SNR or something that's very handy when second-guessing the good beam detection

Personally, I'd vote for splitting DVL from ADCP. DVLs almost always report a single bottom track velocity; ADCPs report several velocities as a function of range. That's a non-trivial difference. I've seen ADCPs and DVLs used quite differently in practice-- with the possible exception of DVLs in water-track mode.

... but two opinions is hardly enough! C'mon everyone!

[smaria]

merging messages

The possibility of merging may be a misconception on my side. When coming up with this suggestion, I misread DVBeam.msg and thought it already included an array for each of the beams, allowing to put in the velocity data for each bin for a DVL in water-track mode, and thus close to ADCP data. To further understand the merging decision (or make some way towards defining the separate ADCP message type) I wonder:

• Which fields in the DVL message would not be used by an ADCP?
• Besides the profile array field I imagined, which fields are still missing for use as an ADCP?

water track vs. bottom track

As I understand it, the DVL can have no valid tracking, bottom tracking, or (exclusive!) water tracking, so it can be handled with constants as in the current message suggestion:

# Instrument reference data
uint8 VELOCITY_REFERENCE_UNKNOWN = 0
uint8 VELOCITY_REFERENCE_WATER = 1
uint8 VELOCITY_REFERENCE_BOTTOM = 2

uint8 velocity_reference

@ivaughn does this cover what you meant, or is there information missing?

missing fields in the current message

Going over the notes from the workshop and comparing them to the current message, I believe the following are covered in the current suggestion:

• velocity -> given per beam in the DVLBeam[]array, and in the velocity_reference field
  • range (#) -> given in the range field, and per beam in the DVLBeam[] array
  • velocity covariance -> given per beam in the DVLBeam[] array

For the following I have open questions:

• reference frame (depth)
• frame of beams wrt sensors
• internal beamframe Not sure what the difference between those three is. The frame of the overall direction of the sensor is given in the header, the frame for each individual beam is given in the entries in the DVLBeam[] array. I can't think of a third frame that needs to be given?

This information currently doesn't have a field in the message:

• number of good beams DVLBeam includes the option to set the range to a value smaller than zero for individual beams, to indicate an invalid range. However, I believe that is different information and there is merit in adding a field for this in the main message.
  • number of bins
  • sensor timestamp -> I assume this is distinct from the message timestamp which is included in the header
  • time delta? -> is there a use-case for this information, that could not simply rely on the sensor timestamp information?
  • configured sound velocity

[ivaughn]

As far as I know, RDI DVLs usually report a single value for water-track velocity, in part so they can upcharge us for ADCP capabilities. RDI systems can alternate bottom and watertrack pings, but that's not universal. Nortek DVLs claim to report bottom and watertrack velocities on each ping-- I haven't had a chance to try that out yet, ask again in 6 months.

Does the proposed message require RDI DVLs to operate in beam reference frame and then run a driver that does the beam frame to instrument frame conversion? The conversion is non-trivial, but presumably that's why we all want to run a single driver! The RDI format we're using can report either instrument-frame velocity (XYZ+Errors) OR beam velocities but not both-- although, again, many of the non-RDI DVLs appear willing to spend the extra 8 bytes.

As far as timestamp delta: we use the DVL clock as a monotonic clock with perfect ping synchronization for integrating velocities. The timestamp field should come from the computer's system clock which is subject to adjustments by NTP or in our case an external PPS from an OXCO clock. This is enough of an issue that Linux exposes a separate CLOCK_MONOTONIC in its timing API. See also: https://linux.die.net/man/3/clock_gettime. We use the DVL's internal clock instead to avoid any communications latencies. It's a good idea to include the DVL's internal clock in messages to help resolve issues synchronizing the vehicle clock to the instrument clock in post-processing. That's probably redundant with the timetamp delta. It's also worth asking if the internal clock more properly belongs in a hyper-detailed not-standardized message that gets logged for post-processing instead of this generic message. But we need a high-quality monotonic clock either way.

More generally, are we at all concerned about the performance requirements necessary to hit up TF for each beam? The PR2 had to compact its TF tree for performance reasons, just curious where that limiti is.

I concur on the need for number of good beams & configured sound velocity. What's the usecase for number of bins?

Should we add some sort of per-beam figure-of-merit? A correlation, SNR, something like that?

[smaria]

More generally, are we at all concerned about the performance requirements necessary to hit up TF for each beam? The PR2 had to compact its TF tree for performance reasons, just curious where that limiti is.

This is a more general question, I extracted it to #7

[narcispr]

Some comments about what you say:

• number of good beams: we can use the velocity_covariance field to know if the beam is ok or just have an extra field.
• number of bins: I don't know for an ADCP but I can see if this is going to be useful in a DVL.
• sensor timestamp: In the message header there is a time stamp. Does this field have to come from the PC or the DVL? Is it possible to receive the DVL internal time toguether with the measures? Can this be decided per driver not in the general message?
• time delta and configured sound velocity: Are these parameters changing to each measure? Maybe, like there are an Image and a CameraInfo messages we can have a DVL and a DVLInfo messages for these parameters (i.e., max range, water mass layer params, time per ensemble,...).
• tf per beam: I don't think that 4 more TFs will slow down the system. Another thing is for a multibeam (#7).

[dulanad]

Hi to anyone still subscribed to this after 11 months. Any chance the discussions in this package auto-magically resolved and created a standard underwater sensor package somewhere ? :) Or is this still in "active" discussion ?

[smaria]

No magic resolution yet ;)