ping_info: Array Geometry

[CaptKrasno]

I propose we add some data fields to ping_info describing the physical geometry of the receiver and transmitter for multi beam sonars. This geometry affects the shape of the pulses emitted-from and listened-to by the transmitter and receiver. The two types I have encountered are linear arrays and circular arrays.

linear arrays are found in most MBES for both TX and RX. They are just a line of transducers. They can steer their beam by controlling the timing of the pulse across each element.
implications for processing:

• Beam widths grow with obliquity
• Beam pattern is represented as a cone defined by the tx/rx angle

Circular/Barrel arrays are found in some MBES and FLS as both tx and rx arrays. They are defined by an array of elements equally spaced on the rim of a circle. these arrays do not "steer" the beam, rather they utilize a sub-section of the array orthogonal to the intended beam to control directionality. Norbit MBES are an example of this type of receive array. implications for processing:

• Beam widths are constant with obliquity
• Beam pattern is represented as a plane defined by the tx/rx angle

Both types of arrays have implications for sound speed errors as well.

I have two options for representing this variable geometry.

Option1:

# linear arrays are found in most MBES for both TX and RX
# implications for processing:  
#   - Beam widths grow with obliquity
#   - Beam pattern is represented as a cone defined by the tx/rx angle
uint8 ARRAY_GEOMETRY_LINEAR=0 

# Circular/Barrel arrays are found in some MBES and FLS as both tx and 
# rx arrays.   They are defined by an array of elements equally spaced
# on the rim of a circle
# implications for processing:  
#   - Beam widths are constant with obliquity
#   - Beam pattern is represented as a plane defined by the tx/rx angle
uint8 ARRAY_GEOMETRY_CIRCULAR=1

uint8 tx_geometry
uint8 rx_geometry

The problem here is that circular arrays are not purely circular and tend to steer towards the edges. So really, they are hybrid arrays.

Option 2:

# The steering angles represent how far off an effective linear array 
# the beam was steered.  This angle will define how conical the tx/rx
# pulse is.  
# For the linear portion of an array tx/rx_steering_angle = tx/rx_angle
# For the circular portion of an array tx/rx_sterring_angle = 0
uint8[] tx_steering_angles
uint8[] rx_steering_angles

Instead of trying to classify the geometry with an enum we just classify the critical element. That is, the steering angle.

• For a typical linear array tx/rx_steering_angles = tx/rx_angle indicating that the directionality of the beam was entirely created by beam steering. In this case the transmitted beam will be a cone.
• For a purely circular array tx/rx_steering_angles = 0 indicating that the beam was not steered at all to achieve directionality. Therefore the beam will be a plane.
• For a steered circular array tx/rx_steering_angles < tx/rx_angle near the outer beams when steering is used to achieve a wider swath than the purely circular geometry will allow.

Basically you can think of the steering angle as: How conical is the pulse in question.

I prefer option 2 because we can boil the geometry down to an equation rather than a switch case. Additionally, it is more general for hybrid arrays.

@rolker @valschmidt @lauralindzey I would love to hear your input.

[CaptKrasno]

It occurs to me that this may not be appropriate for ping_info since that is shared with the projected messages. maybe it's better to put this in the raw messages allong with tx/rx angles..

[rolker]

It's been a while since I've dug into the weeds of acoustic processing, but this seems reasonable to me. Option 2 seems good for the reasons you mention.

Will this be general enough the describe other unusual geometries that exist now or that may be developed in the future. For example, the Simrad ME70 uses a single 2d planar array for both transmit and receive. I think the math works out to be the same as for a Mills Cross so maybe not an issue in this case. What about a 2d array on a curved surface?

[CaptKrasno]

@rolker I would need to do a bit more research on 2d arrays. I suspect the same strategy would work. However. I think they are already incompatible with our raw sonar message in it's current form. Correct me if I'm wrong, but a 2d array should emit a more/less spherical pulse and then report the angle both from the x plane and from the y plane. We don't have data field for that.

Instead we assumed a more/less conventional multibeam where we assume that we are emmiting a (more/less) planar pulse and listening for a planar return. To get the ranges you need to find the overlap. I think this might be a fundamentally different datatype. 2d arrays may be better suited for the SonarRanges message that does not make such an assumption.

I think with 2d arrays we also don't need to be as worried about transmit and receive pulse shape as we do with multibeam. The 2d array resolves angles entirely at RX time so we don't need to consider how the beam patterns overlap changes as the receiver moves. I think it's safe to just report a 2 way travel time and beam direction as we do in Sonar Ranges.

[lauralindzey]

This is going a lot more into sonar details than I've had a reason to, so I'm not going to be able to comment on which representation you should go with. I agree with @CaptKrasno's second comment that this doesn't belong in PingInfo since it's only applicable to the messages that haven't yet been projected.

My main concern will be in making sure that the choices are well documented, don't overly complicate the messages for people who can afford to ignore these details, and that bag migration rules work =)

[lauralindzey]

@CaptKrasno -- I'm checking in on the marine_msgs repo ... even when canceled, the marine working group meetings provide a nice reminder to spend a bit of time on this =)

I haven't heard back from Vatan, so I'm planning to try a submission to rosdistro myself. Do you think Option 2 is solid enough that we should try to include it in v2 + the rosdistro merge request? Or do you want more time on this one?

If the fields are purely additions, rather than renamings, then we can update the released messages and only bump the version number from 2.0 -> 2.1 after release. If the changes are more invasive ... I'm still not sure how bumping major version numbers works with rosdistro.