ROS 2 Lyrical Luth · Lesson 30 of 86

Simulated LiDAR

The gpu_lidar sensor, its parameters and bridging LaserScan to ROS 2.

Estimated time · 60–90 min

Learning goals

What you will understand

Explain simulated lidar in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

A simulated lidar casts rays into the world and reports distances. In SDF it is a sensor of type gpu_lidar with the number of samples, angle range, distance range and update rate. It publishes a Gazebo LaserScan that must be bridged to sensor_msgs/msg/LaserScan.

Use realistic numbers: 360 samples over 360 degrees at 10 Hz with a 0.12–10 m range is typical. Set the frame id to the lidar link so TF can place the data, and check the result in RViz2 with the LaserScan display.

Guided lesson

Work through these steps

1.
Source the ROS 2 Lyrical environment in a fresh terminal.
2.
Read the simulated lidar example and identify what each line does.
3.
Build only the affected package, source the workspace overlay, and run the example.
4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

<sensor name="lidar" type="gpu_lidar">
<!-- A GPU ray sensor. -->
  <update_rate>10</update_rate>
<!-- Ten scans per second. -->
  <topic>scan</topic>
<!-- Gazebo topic name. -->
  <lidar><scan><horizontal><samples>360</samples><min_angle>-3.14159</min_angle><max_angle>3.14159</max_angle></horizontal></scan>
<!-- 360 rays over a full circle. -->
  <range><min>0.12</min><max>10.0</max></range></lidar>
<!-- Measurable distance from 0.12 m to 10 m. -->
  <always_on>true</always_on>
<!-- Keep the sensor running. -->
</sensor>
<!-- End of the sensor. -->

What the example is doing

1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Sensor view

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

# TODO: bridge /scan from Gazebo (gz.msgs.LaserScan) to ROS 2 (sensor_msgs/msg/LaserScan)
# Check the rate: ros2 topic hz /scan

Expected output

average rate: 10.0

Stuck? Show the full solution (try it yourself first)

ros2 run ros_gz_bridge parameter_bridge /scan@sensor_msgs/msg/LaserScan[gz.msgs.LaserScan
# Check the rate: ros2 topic hz /scan

Expected result

How you know it worked

ROS_DISTRO is lyrical in every terminal used for the exercise.
The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Add a 360-sample lidar to your robot, bridge /scan to ROS 2 with ros_gz_bridge, view it in RViz2 with Fixed Frame base_link, and confirm ros2 topic hz /scan reports about 10 Hz.

Before you continue

ROS_DISTRO reports lyrical in every terminal you used
The example builds and runs without errors
You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.