Inaccurate GPU Lidar

[amock]

Hi Gazebo Dev Team,

First of all, thank you for the great software project. I've been using Gazebo Classic for a long time and it helped me a lot. In Gazebo Classic, switching from the CPU ray plugin to the GPU ray plugin resulted in a slight decrease in lidar accuracy. This was particularly noticeable when the lidar hit surfaces at shallow angles, though in most cases, the accuracy remained sufficient for our needs. However, after migrating from Gazebo Classic, the new "gpu_lidar" plugin appeared to be even more approximate than before. In my use cases, where scans are expected to come from spinning devices, this level of inaccuracy became problematic.

Below is a detailed problem description with accompanying images:

Test 1: Gazebo Classic

Setup:

• Ubuntu 22
• ROS 2 humble
• Gazebo Classic Version: 11.10.2 (installed from official APT repositories)
• Tested code is here: https://github.com/amock/rmcl_examples . However, I changed the field of view, number of samples, and resolution to make it equal to test 2 & 3.

CPU Ray Plugin

XML:

<gazebo reference="velodyne">
<sensor type="ray" name="velodyne-vlp16">
    <pose>0 0 0 0 0 0</pose>
    <visualize>false</visualize>
    <update_rate>20</update_rate>
    <ray>
    <scan>
        <horizontal>
            <samples>128</samples>
            <resolution>1</resolution>
            <min_angle>${-M_PI}</min_angle>
            <max_angle>${M_PI}</max_angle>
            </horizontal>
        <vertical>
            <samples>32</samples>
            <resolution>1</resolution>
            <min_angle>${-M_PI / 16.0}</min_angle>
            <max_angle>${M_PI / 4.0}</max_angle>
        </vertical>
    </scan>
    <range>
        <min>0.3</min>
        <max>130.0</max>
        <resolution>0.001</resolution>
    </range>
    <noise>
        <type>gaussian</type>
        <mean>0.0</mean>
        <stddev>0.0</stddev>
    </noise>
    </ray>
    <plugin name="gazebo_ros_laser_controller" filename="libgazebo_ros_velodyne_laser.so">
        <ros>
            <namespace>/velodyne</namespace>
            <remapping>~/out:=points</remapping>
        </ros>
        <frame_name>velodyne</frame_name>
        <organize_cloud>true</organize_cloud>
        <min_range>0.9</min_range>
        <max_range>130.0</max_range>
        <gaussian_noise>0.008</gaussian_noise>
    </plugin>
</sensor>
</gazebo>

Results (left Rviz, right Gazebo):

GPU Ray

XML:

<gazebo reference="velodyne">
<sensor type="gpu_ray" name="velodyne-vlp16">
    <pose>0 0 0 0 0 0</pose>
    <visualize>false</visualize>
    <update_rate>20</update_rate>
    <ray>
    <scan>
        <horizontal>
            <samples>128</samples>
            <resolution>1</resolution>
            <min_angle>${-M_PI}</min_angle>
            <max_angle>${M_PI}</max_angle>
            </horizontal>
        <vertical>
            <samples>32</samples>
            <resolution>1</resolution>
            <min_angle>${-M_PI / 16.0}</min_angle>
            <max_angle>${M_PI / 4.0}</max_angle>
        </vertical>
    </scan>
    <range>
        <min>0.3</min>
        <max>130.0</max>
        <resolution>0.001</resolution>
    </range>
    <noise>
        <type>gaussian</type>
        <mean>0.0</mean>
        <stddev>0.0</stddev>
    </noise>
    </ray>
    <plugin name="gazebo_ros_laser_controller" filename="libgazebo_ros_velodyne_laser.so">
        <ros>
            <namespace>/velodyne</namespace>
            <remapping>~/out:=points</remapping>
        </ros>
        <frame_name>velodyne</frame_name>
        <organize_cloud>true</organize_cloud>
        <min_range>0.9</min_range>
        <max_range>130.0</max_range>
        <gaussian_noise>0.008</gaussian_noise>
    </plugin>
</sensor>
</gazebo>

Results (left Rviz, right Gazebo):

Note: Accuracy has slightly degraded compared to the CPU Ray. But it's still OK.

Test 2: Gazebo Fortress

Setup:

• Ubuntu 22
• ROS 2 humble
• Gazebo Fortress, from official APT repositories (Version see image)
• Code: https://github.com/naturerobots/mesh_navigation_tutorials/blob/main/mesh_navigation_tutorials_sim/urdf/ceres.urdf.xacro

GPU Raycaster:

<gazebo reference="laser3d">
    <sensor name="laser3d" type="gpu_lidar">
      <pose relative_to='laser3d'>0 0 0 0 0 0</pose>
      <topic>/model/robot/cloud</topic>
      <update_rate>10</update_rate>
      <ray>
        <scan>
          <horizontal>
              <samples>128</samples>
              <resolution>1</resolution>
              <min_angle>${-M_PI}</min_angle>
              <max_angle>${M_PI}</max_angle>
          </horizontal>
          <vertical>
              <samples>32</samples>
              <resolution>1</resolution>
              <min_angle>${-M_PI / 16.0}</min_angle>
              <max_angle>${M_PI / 4.0}</max_angle>
          </vertical>
        </scan>
        <range>
            <min>0.2</min>
            <max>100.0</max>
            <resolution>0.001</resolution>
        </range>
      </ray>
      <always_on>1</always_on>
      <visualize>true</visualize>
      <frame_id>laser3d</frame_id>
      <gz_frame_id>laser3d</gz_frame_id>
      <ign_frame_id>laser3d</ign_frame_id>
    </sensor>
 </gazebo>

Results (left RViz, right Gazebo):

Test 3: Gazebo Harmonic

• Ubuntu 24
• ROS 2 jazzy
• Gazebo Harmonic, from official APT repositories (Version see image)
• Code: Same as test 2

Same effects than in Gazebo Fortress:

Additional Tests

• Same effects for ros2 launch ros_gz_sim_demos gpu_lidar_bridge.launch.py
• Briefly tested under ROS 2 rolling. Problems remain.

Questions

1. Did I do something wrong while parameterizing the new "gpu_lidar" plugin?
2. Is this problem known?
3. What causes the GPU LiDAR to have lower accuracy compared to the Gazebo Classic version?
4. Unrelated to this issue: For Gazebo Harmonic, changing "gpu_lidar" to "lidar" was not working at all. Are the XML interfaces for "lidar" different then from a "gpu_lidar"?

Thanks for the help in advance
Alex

[iche033]

The implementation of gpu_lidar with the default render engine in gz-sim (ogre2) is slightly different from gazebo-classic. The <samples> parameter plays a more important role in the accuracy of the readings. If you increase this number, you should get more accurate results, but at the cost of higher resource usage.

Alternatively, you can also try switching the sensor system's render engine to ogre (in your world sdf file) and that uses the gpu lidar implementation from gazebo-classic, i.e.

    <plugin
      filename="gz-sim-sensors-system"
      name="gz::sim::systems::Sensors">
      <render_engine>ogre</render_engine>
    </plugin>

cpu based lidar isn't available in gz-sim yet. I think there's some interest in adding support for this. Some related work is started in #2514 but more needs to be done to make it a sensor.

[amock]

Thanks! Going back to ogre(1) actually resolved the issue for now. However, this doesn't seem like an ideal solution, as it appears that I can't switch the rendering engine for just this specific sensor - only for all sensors at once. Is that correct?

Suppose I have a very sparse lidar and want to simulate it accurately using the ogre2 implementation. Would that require increasing the number of rays, simulating the scanner, and then downsample afterward to get it sparse again?

Alternatively, would it be feasible to introduce a parameter that ensures a minimum accuracy level, even at the cost of increased runtime?

[iche033]

it appears that I can't switch the rendering engine for just this specific sensor - only for all sensors at once. Is that correct?

yes that's correct

Suppose I have a very sparse lidar and want to simulate it accurately using the ogre2 implementation. Would that require increasing the number of rays, simulating the scanner, and then downsample afterward to get it sparse again?

Alternatively, would it be feasible to introduce a parameter that ensures a minimum accuracy level, even at the cost of increased runtime?

yes that'll be the workaround. Ideally gazebo does all that for you. The <resolution> sdf tag is supposed to help with this but that's is not implemented yet in gazebo.

[matlabbe]

@iche033 thank you for the workarounds, changing to ogre (instead of ogre2) worked for my use case. This also answered my question here https://robotics.stackexchange.com/questions/113735/gazebo-gpu-lidar-seems-distorded-in-ignition-in-comparison-to-gazebo-classic (added for crossref)

[PerFrivik]

Thank you for the fix! Switching back to OGRE(1) fixes my issue :D, how did this pass any lidar checks? My before and after is basically a circle vs a square...

[andresgaluitcl]

Hello, I don't think switching to ogre(1) solves this issue, at least not in my case. To be more specific, it solves one issue and creates another. With Ogre2 I get this squarey quantization errors in the GPU lidar, but in Ogre1 rays go through the ground and result in points below it.

I'm using Gazebo Fortress, but have Gazebo Classic installed too, in case that's relevant.
I tested this on the example lidar world (gpu_lidar_sensor.sdf) and only changed the render_engine tag to ensure I was not adding something that breaks it.

Ogre2: jagged edges

Ogre1: it looks better from above, but in reality it's going through the ground

Another possible solution I found was using export LIBGL_ALWAYS_SOFTWARE=1, which combined with Ogre1 gives this result:

Which is the most accurate lidar point cloud from the available options, but slows the simulation significantly.

I also tried playing around with the samples and resolution tags from the lidar sdf (in a different world) and did not find a significant difference, other than using more samples results in more points in the point cloud.
If this issue can be solved by modifying the lidar sdf parameters, can someone explain which parameters and how?

Thanks

[EndlessLoops]

My tb3 robot is also used under jazzy, and the lidar data behind the robot is incomplete. Test environment: 20x20m area surrounded by a fence.

      <sensor name="hls_lfcd_lds" type="gpu_lidar">
        <use_sim_time>true</use_sim_time>
        <always_on>true</always_on>
        <visualize>true</visualize>
        <pose>-0.032 0 0.171 0 0 0</pose>
        <update_rate>10</update_rate>
        <topic>scan</topic>
        <gz_frame_id>/base_scan</gz_frame_id>
        <lidar>
          <scan>
            <horizontal>
              <samples>720</samples>
              <resolution>1.000000</resolution>
              <min_angle>0.000000</min_angle>
              <max_angle>6.280000</max_angle>
            </horizontal>
          </scan>
          <range>
            <min>0.120000</min>
            <max>30</max>
            <resolution>0.001</resolution>
          </range>
          <noise>
            <type>gaussian</type>
            <mean>0.0</mean>
            <stddev>0.01</stddev>
          </noise>
        </lidar>
      </sensor>