search

Field-Robotics-Lab / nps_uw_multibeam_sonar

Multibeam sonar plugin with NVIDIA Cuda library
Apache License 2.0
35 stars 20 forks source link

Make "fidelity" knob independent of nBeams? #30

Closed lauralindzey closed 2 years ago

lauralindzey commented 2 years ago

This is a follow-up to #4.

We're currently working on a project using this simulator to generate bag files that will be used repeatedly in evaluating sonar reconstruction approaches. As such, we don't really care about running in real time, and instead wanted to get the "best" data possible, with small step sizes for the integral through the elevation angle. We are doing this by setting raySkips to 0.

I think I see where this design came from: since the depth camera that the plugin is based on has square pixels, so the number of vertical pixels is fully determined by horizontal/vertical fields of view and the number of horizontal beams. Then, you just downsample the vertical beams (with the raySkips parameter) to get the desired fidelity/speed tradeoff.

However, it's not possible to get more detail than raySkips = 0. And, it's a bit counterintuitive that changing the horizontal resolution also changes the apparent fidelity of the reconstruction. (As demonstrated in images below.)

It would be nice to have an independent knob that lets the user trade off time for step size, in both directions. (Maybe this could be implemented with a horizontal raySkips under the hood, automatically choosing which dimension of the depth camera to decimate?)

woensug-choi commented 2 years ago

I am working on https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/pull/19 to change to GPURay-based sonar. This will resolve the dependency problem of https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/issues/4. The PR can provide freedom to elevation direction but not in the horizontal direction...

I do agree with the idea of having a fidelity knob independent of nBeams. I didn't expect you would need more resolution in the horizontal direction too. I shall add that after https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/pull/19 is completed.

https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/blob/65fdef8b0abe6eea5b6c850d3f7393b223eee142/models/blueview_p900_nps_multibeam_ray/model.sdf#L51-L68

woensug-choi commented 2 years ago

Btw, why do the brightness are different in your captures? Maybe there's a bug with division corresponding to nBeams?

lauralindzey commented 2 years ago

OK, yay! #19 sounds like a great improvement -- ping me when it's ready for us to try using.

I didn't expect you would need more resolution in the horizontal direction too. I shall add that after #19 is completed

Oh -- we don't need more resolution in the horizontal direction, since our sonar only has 512 beams. I was only changing nBeams to look at the impact it had on the vertical/elevation direction, to see if in there was a vertical resolution at which we stopped seeing the arc artifacts.

Btw, why do the brightness are different in your captures? Maybe there's a bug with division corresponding to nBeams?

No idea ... I didn't look into it at all, though I definitely noticed it =) All I changed between the three images was the nBeams parameter -- everything else was identical.

woensug-choi commented 2 years ago

https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/pull/31 is ready!

Vertical Sampling would be a "Fidelity" knob. https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/blob/3034c08e44cb156015448b37e95ab99358cca7db/models/blueview_p900_nps_multibeam_ray/model.sdf#L53