Consider adding more specific uncertainty fields to SonarRanges

[lauralindzey]

@valschmidt says:

Two fields that might be added are travel time uncertainty and beam pointing angle uncertainty. Admittedly most sonars do not report these values directly, but it is where all other uncertainty values are derived. I admit this is tough one. Reson reports depth uncertainty as a fraction of the depth measurement for the beam. Kongsberg reports uncertainty in x, y and z. When they are not otherwise provided, to a first approximation one can assume the beam pointing uncertainty is zero and calculate the range uncertainty as sigmaR = sin(beam_pointing_angle) * sigmaZ. But maybe this is too much to provide guidance for. In any event, it is really useful to provide an estimate of the uncertainty in the soundings if possible. I’m happy to talk more about this one if you want.

[CaptKrasno]

I would love to see this implemented but it is a tricky problem.

Here's a suggestion to get things started:

assume N is the number of beams in the return.

1. A length N vector with a 3x3 covariance matrix for each beam with each row/col corresponding to: [travel time, left/right of beam, fore/aft uncertainty].
2. I we assume the errors are independent we could have 3 vectors of length N for uncertainty in travel time, left/right of beam, fore/aft uncertainty]. Vectors can be of length 0 of data is not reported

In either case I'm suggesting we linearize the uncertainty in the neighborhood of the detection. That way we can have a covariance matrix that can play nicely with TF.

The units of these uncertainties will be seconds since we are working in time space. They could be easily converted to range space. The covariance matrices could then pass through a coordinate transformation to rotate them to the sensor frame to give uncertainties in x,y,and z.

Something to consider We need to think about how angular uncertainty is related to beamwidth.

• Is the beamwidth the angular uncertainty in the detection?
• Is the uncertainty the beamwidth + the uncertainty in angle?

@valschmidt I would love to hear your thoughts on this one.

[valschmidt]

This can get really complex. The process of getting from travel time and beam pointing uncertainty to sounding uncertainty is not as simple as propagation of the uncertainty through a rotation because of the refraction involved. [Also sometimes the transmitted signal has to be ray-traced separately from the receive signal, but I won't even go there.]

I wonder if this topic might deserve a REP to take the time to explain some of these details and some simplifying assumptions that can be made that will work for most people, as well as the conventions used by these messages. And then define the message definitions that make those assumptions.

The simplifying assumptions with regard to uncertainty I would suggest:

1. There is no refraction, or alternatively, the errors caused by refraction are neglected. For folks doing deep water mapping there is little to no sound speed variability (except maybe near vents) and this assumption is pretty valid.
2. The uncertainties in range and angle are small, such that standard, first order, linear, "propagation of variance" calculations are sufficient to propagate uncertainty, as is usually done in robotics.

Beam width can cause angular uncertainty in the detection when the range to an object varies over the size of the beam. This can be hard to quantify unless you know the object ahead of time. For the seafloor that is guaranteed to extend across the whole of the beam, it is given by

sigma = d [ 1 - cos (bw/2)]

where sigma is the 1-sigma depth uncertainty due to this effect, d is the depth to the detected seafloor detected at the edge of the beam (the worst case), and bw is the beam width of the beam. Typically the only beam width that is considered is the along-track beam width, because in the across track direction, detections are made using the split beam phase method which can resolve detections within the beam. Technically amplitude detections suffer from this uncertainty in both along-track and across-track directions, but it's usually neglected.

-Val

[CaptKrasno]

Thanks for the reply @valschmidt. Based on your experience do you have a suggestion for what messages the sensor should report. I think it's important that we keep the fields in the message as close to what's reported by the sensor as possible.

From your comments it looks like angular uncertainty is pretty negligible relative to beam width. 2 way travel time doesn't seem to be a big factor in the uncertainty according to your equation but it may be reported by the sonar.

Therefore I propose this:

• only report in the 2-way-travel-time uncertainty in the message.
• From there leave it to the MBESmsg to Pointcloud converter to handle the uncertainty analysis based on 2 way travel time and beam widths.

I think this method removes most assumptions from the message itself for data logging purposes.

What do you think?

-Kris