udgcirs / marine_ros_conventions_discussion Goto Github PK

Currently, over 60 message ideas are waiting to become ROS messages. Before we start 60 separate discussions, maybe some ground rules should be defined. What do we aim for with the messages? What are general rules for ROS messages we should comply with?

Several message suggestions/abbreviations from the work shop are not clear (enough) to me:

• DO
• ADV  
• Surface time (is this how long the vehicle has been at the surface? suggested tags: comms, mission_
• Environment (this seems too broad, could be tagged mission, but what does it contain?)  
• Hydrophone channel (sure, hydrophone sounds like a great message type, but what does 'channel' imply? information about the SOFAR channel?)

This looks like copypasta from the line above (float32 range_max # maximum range value [m]). If I interpret the use of the variable correctly, this may better be described with
float32 range_increment # resolution of the discrete beam range measurements [m]

range_resolution might also be a more descriptive name:
float32 range_resolution # [m] or
float32 range_resolution # minimum difference between two discrete beam range measurements [m]

@ivaughn brought this up in #5, which I think is more of a general issue, worth clarifying and adding to the general message standards (#4):

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.

Can't hurt to put a license on from the start. Since we want wide use and adoption, I'd suggest BSD or MIT.

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.

Hi everyone,

have you already added marine_ros_conventions_discussion/sensor_msgs/DVL.msg to ROS sensor_msgs, i.e., is there a <sensor_msgs/DVL.h> available to use already?

Thanks,
Bojan.

This repository has no existing draft.

From the workshop notes:

standard (required)

• temperature (scalar)
• pressure -> sometimes missing, sometimes standalone msg
• conductivity or salinity (array...)

optional (derived)

• sound vel
• density
• depth

Other attached sensors (DO, Fluorometer) don't go in this msg.

I struggle to identify the difference between the two sonar messages. Both seem to be based on the laser scan messages from sensor_msgs.

Extra fields in ProfilingSonar:

• float32 range_resolution # [% of range error]
• float32 time_increment # For a mechanically scanning sonar (...)
• float32[] ranges # range data [m]
• float32[] intensities # intensity data [device-specific units]

Extra fields in Imaging Sonar:

• float32 elevation_angle # [Hz]
• float32 range_increment # maximum range value [m]
• SonarBeam[] beams # Imaging sonar data.

It appears two are slightly different implementations of the same concept:
range_resolution <-> range_increment
intensities <-> beams

With my current knowledge of sonar sensing I can not assign a sonar device clearly to either of these messages, and know of no argument why both are needed. As a merge of the two I would suggest https://github.com/smaria/marine_ros_conventions_discussion/blob/master/sensor_msgs/SonarScan.msg

It has become apparent in #2 that multibeam data cannot be dealt with by a single message format that fits all. We need to better understand which processing&use exist, where existing formats are best used, and which additional message types are needed.