GpuRay based Multibeam Sonar

[woensug-choi]

Work in progress...

Related Issue : https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/issues/18 and https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar/issues/4

[woensug-choi]

Generic gpu_ray sensor does not provide correct vertical data

There were some discussions about this long ago. I hoped it was fixed. But it was not. Related links : https://answers.gazebosim.org//question/12068/how-can-simulation-multi-layervertical-using-gpu_ray-sensor/ Also, most of the issue links are broken making it difficult to understand the status. e.g. https://bitbucket.org/osrf/gazebo/issues/946/gpu-ray-sensor-vertical-ranges

My testing with generic gpu_ray showed strange point cloud data.

• With a single elevation ray it looks ok
• But with multiple elevation rays, it gives a strange point cloud, where the points should be stacked vertically.

Using Velodyne's lidar sensor to create a point cloud

• The Velodyne Simulator which simulates the velodyne's lidar sensors uses modified gpu_ray, ray sensor to generate point cloud. https://bitbucket.org/DataspeedInc/velodyne_simulator/src/master/
• It is included in the dave installation since we are using the same plugin for our lidar sensor examples. https://github.com/Field-Robotics-Lab/dave/wiki/3D-Underwater-Lidar

Current results

• Now, point clouds are calculated with gpu_ray sensor which provides a parameter to control the number of vertical rays.
• However it's output is distorted, which needs more investigation.

Other notes

• It uses pcl library to manipulate pointcloud2 data.
• It seems the variational reflectivity implementation could be very difficult.

[woensug-choi]

Fixed distortion! Need clean up and comparisons with previous depth_camera's results. It was due to different azimuthal angles since the rays by the gpu_ray are sent at each vertex of scene capture, where for the depth_camera the ray were pixel centers.

[woensug-choi]

Current status

• Initial migration to gpu_ray based multibeam sonar plugin has been done
  • It uses the same cuda source code.
  • The Velodyne Simulator which simulates the velodyne's lidar sensors uses modified gpu_ray, ray sensor to generate point cloud. https://bitbucket.org/DataspeedInc/velodyne_simulator/src/master/ (The library is already included in the dave for lidar sensor)

Limitations

• Variational reflectivity is not included. (GetScene function caused the ray sensor to crash)

Todo

• [x] Incident angle effect is not included. (Obtaining normal vector from the point cloud using PCL library could reduce refresh rate and accuracy)
• [x] The Matlab script and CSV data saving needs an update for new azimuth angle calculations

[woensug-choi]

For normal calculation, the previous calculation function methods does work on the depth image created from point cloud too. Don't mind the orientation. As long as we are using cosine function to apply the incident angle effect, the sign of the normal vector does not matter.

• Camera based multibeam sonar normal image

• Ray based multibeam sonar normal image

[woensug-choi]

GPU Ray (Velodyne lidar) vs Raster (Depth camera)

• Can't compare intensity levels since the beam angles are different.
  • Both uses 512 beams, the GPU Ray version has equal beam angle spacings, but the raster version doesn't have equal beam angle spacings.
• Geometry is captured correctly. When combined as a figure below, it's seamless

[woensug-choi]

Number of rays

• Number of vertical rays can be defined at GPU Ray version.
• Calculation time depends on the number of rays. For 512 beams, using 500 vertical rays for each beam up to 10 m range would result in about 1.5 Hz refresh rate.
• Number of rays is important for the cases when the sonar is looking down grazing the bottom. In the case below (3 m above ground, 9 degrees looking down, and the Blueview P900 has FOV 90 degrees wide 20 degrees vertical), 228 vertical ray calculation shows insufficient resolution after about 4 meters range. On the other hand, the 500 vertical ray calculation shows sufficient resolution all the way to 10 meters.

Bug

• In the 500 vertical ray case, there's a black dimming arc shown near the 3 m range.

[woensug-choi]

To do:

• [x] Fix dimming arc bug
• [ ] Documentation (update wiki accordingly