Discretization of elevation angles visible as stripes

[woensug-choi]

@lauralindzey has spotted on beta user tests that the discretization of the elevation angles is visible as stripes as follows. This is due to the resolution of the rays. In default settings, 11 elevation rays produce the sonar image (114 rays taken from depth_camera vertical pixels and calculated with ten elevation ray skips to reduce computation costs). This brings a conceptual question for the plugin from the user's point-of-view.

• Leave as it is for the user to choose the image resolution.
  • Three handling parameters are already included in the plugin. (1) Horizontal/vertical field of view, (2) number of rays (vertical) and beams (horizontal), (3) ray skips for sonar calculation
• Make some kind of interpolation for the discretized data.
  • Still requires target resolution to interpolate it to. The range vector resolution, which depends on the sonar frequency and maximum distance, can be used. Meanwhile, it will increase computation costs to reduce the refresh rate.

In which situation can we justify the interpolation of the image?

[lauralindzey]

Hi @woensug-choi . I'm back to working with simulation again, apologies for the radio silence.

I spent a little bit of time trying to tweak the nRays and raySkips parameters in the plugin, but changing them from the default tended to just yield a blank image, or an equally stripy image.

Can you suggest parameters I should try that might give a better image, even at the cost of running (much) slower than real-time?

[woensug-choi]

Parameters to handle on run-time

• Camera pose (Pitch set to 0.3 for images below) https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/blob/8d8a65a767054ba63982709b5e348caec9394357/worlds/sonar_tank_blueview_p900_nps_multibeam.world#L35
• Camera FOV/Resolution
  • Horizontal FOV is set with an angle at horizontal_fov. Horizontal Resolution is set with width. Vertical FOV/Resolution is dependently calculated from Horizontal FOV/Resolution with height https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/blob/8d8a65a767054ba63982709b5e348caec9394357/models/blueview_p900_nps_multibeam/model.sdf#L38-L45
• Ray skips on sonar calculation https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/blob/8d8a65a767054ba63982709b5e348caec9394357/models/blueview_p900_nps_multibeam/model.sdf#L65

Results

Ray Skips	Camera resolution
width=512 / height=114 / raySkips=10	width=512 / height=228 / raySkips=10
width=512 / height=114 / raySkips=5	width=1024 / height=228 / raySkips=10
width=512 / height=114 / raySkips=0	width=1024 / height=228 / raySkips=5

• raySkips will change the resolution
• height should be changed with width to modify the resolution. Horizontal Resolution is set with width. Vertical FOV/Resolution is dependently calculated from Horizontal FOV/Resolution with height
• For resolution higher than the gazebo camera plugin is not available. Maybe it can be addressed with the next-gen GPU-ray-based sonar plugin.
• I've found a bug during the test. The vertical shadow zone at the little right from the center. It's been put up as another bug issue. https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/issues/7

@lauralindzey Hope this helps! Are you still going to do some experiments right? I am gathering available sonar data for V&V but they are much low frequency and long-ranged. https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/issues/5

[woensug-choi]

Elevation stripe is visible due to fixed ray-wise input data from the camera sensor (discretizes the rendering scene with pixels). As the source of the sonar signal is a point. The range resolution (the gap between elevation stripes) is dependent on the relative orientation of the sonar and objects in the scene. For seabed looking cases, if the sonar is near the seabed with a view field grazing the bottom, the gaps become visible. If the sonar is away from the bottom looking down, the gaps are neglectable.