search

apl-ocean-engineering / marine_msgs

Messages for DVLs, multibeams, and imaging sonars.
BSD 3-Clause "New" or "Revised" License
35 stars 21 forks source link

Should SonarImage.msg try to accommodate both MBES watercolumn data and Imaging Sonars? #17

Closed lauralindzey closed 2 years ago

lauralindzey commented 2 years ago

This question is being driven by the difference in convention between how the different systems think about coordinate systems (#9):

One option is to shoehorn imaging sonars into a message designed for MBES sonars, documenting the fields VERY carefully to try to avoid confusion.

Another option is to create separate messages. This would allow the ones meant for an Imaging Sonar to be simpler, as well as allowing each community's coordinate conventions to be used with those sensors (#8).

(We already know that a new message type will be needed for 3D imaging sonars)

CaptKrasno commented 2 years ago

the "imaging sonars" you mentioned are all FLSs. Fundamentally, they are MBES (occulus even calls itself a multibeam). The only difference is they have a wide TX beam (~20deg). They don't appear to be able to measure "elevation" in their returns only the direction of the TX beam.

I believe we should use the MBES message and MBES_watercolum messages for these types of sonars (i.e. FLS). They are a fundamentally a subset of MBES and they can be completely represented with the MBES messages.

lauralindzey commented 2 years ago

100% agree that the data could be represented with the MBES messages, filling out a subset of the fields. I'm curious whether they should be, based on how the data is used, and conflicting conventions in the communities using each. My bias is also towards messages that are as general as possible, and I suspect we'll stick with the general option, but that also has costs, so I wanted to pull it out as a discussion.

As I understand it, ROS developers are encouraged to define messages based on how the data is used, rather than based on the sensor type, so I want to be sure that there isn't actually a meaningful difference there.

The only difference is they have a wide TX beam (~20deg). They don't appear to be able to measure "elevation" in their returns only the direction of the TX beam.

Yup! Their beams are wide in transmit/elevation, and they can't do any out-of-plane beam steering. So, the relevant data is a subset of what you'd need for a MultibeamWatercolumn message.

I'm interested in reconstruction methods that handle that elevation ambiguity. Given that none of the instruments I work with ever have a non-zero TX beam angle, my code doesn't support using those fields to adjust beam direction. So, it seems misleading to subscribe to a message that includes it, knowing that I'll ignore TX angles and the reconstruction results would be invalid for somebody who was trying to run it using watercolumn data from a MBES.

lauralindzey commented 2 years ago

OK, after more thought and a discussion w/ @tfoote, the resounding consensus is that yes, one message should support both, if at all possible.