Yeah it’s not really surprising that nobody can really agree on what to use when there’s no clear standard messages that would be a perfect fit. I don’t think those four things are typical, every dataset and vehicle always has its setup quirks. I’ve recently been involved in setting up the quadrotor MARS-LVIG dataset for VO and it very liberally mixes NED, ENU and FLU frames. It’s just something one has to deal with on per dataset basis.
I think part of the problem with message duplication is that gathering data is expensive and storage is relatively cheap, so nobody wants to throw away the raw part that might come in useful in the future. So for example, a MBES is conceptually an open and shut case for PC2, but what the sonar generates under the hood is a FLS-like image with maxima detection giving you the actual points. E.g.:
In this case if you want to do the usual hydrographic survey, you just need the points. For doing other kinds of more niche research or debugging the sensor, etc. you might also need the uncertainty for each beam, maybe cases where it failed to find a return, which is where the manufacturer specific custom messages tend to come in.
Conceptually a DVL produces two sources of data, the velocity (TwistStamped) or positional delta (Vector3Stamped), and the 3-6 beams which are less clearly defined. We’ve internally used anything from PC2 for the endpoints to Range lists, but if one is to stick to common_interfaces it’s not really possible to publish only one type.
Personally I’m still missing a message that’s essentially a tf registered CompressedImage for FLS/sidescan type imaging data. I’ve mainly been misusing the OccupancyGrid (realistically it’s the only option) for it since it also works in RViz with raw mode without any plugins and can be used to render sonar data overlaid over satelite imagery, lidar, stereo points, and other data. It’s not natively compressed though so sending it over a network isn’t ideal, and 8 bits per pixel throws away quite a bit of raw data (that’s already done at the Image stage I suppose). I’d really like to know what others are using in this regard, if they’re registering their imagery at all or just straight up only looking at Image data or SonarImageData with an adhoc renderer?
Hopefully one of the current options (perhaps marine_acoustic_msgs, or some other), becomes commonly accepted to cover most cases and gets actually added to common_interfaces, which would finally make it official and drive any sort of serious level of adoption.
P.S. Regarding the obviously completely autogenerated field guide, I suggest taking a peek at this topic.