CodeTheRobot

Ubuntu Linux for Robotics · Lesson 62 of 96

Simulated sensors

Lidar, camera and IMU sensors in Gazebo, bridging them and viewing the data.

Estimated time · 60–90 min

Learning goals

What you will understand

  • Explain simulated sensors in your own words
  • Use it in a small workstation example
  • Verify the result instead of assuming it worked

Understand the idea first

The mental model

Simulated sensors are SDF elements: gpu_lidar (rays), camera (images) and imu (angular velocity and acceleration). Each publishes on a Gazebo topic; bridge it to ROS 2 with ros_gz_bridge using the pattern /topic@ros_type[gz_type (the bracket direction points from Gazebo to ROS).

Set realistic rates, ranges and noise so your software meets imperfect data. Verify each sensor from the terminal: ros2 topic hz for the rate and RViz2 or rqt_image_view for the data. Frame ids must match links in your URDF.

Guided lesson

Work through these steps

  1. 1.

    Open a terminal and record the current state before changing anything.

  2. 2.

    Read the simulated sensors commands and predict what each one does.

  3. 3.

    Run the commands one at a time and compare each output with your prediction.

  4. 4.

    Write the commands that worked in a setup note you can repeat later.

Worked example

Read it before you run it

ros2 run ros_gz_bridge parameter_bridge /scan@sensor_msgs/msg/LaserScan[gz.msgs.LaserScan
# Bridge the lidar.
ros2 run ros_gz_bridge parameter_bridge /camera/image@sensor_msgs/msg/Image[gz.msgs.Image
# Bridge the camera image.
ros2 run ros_gz_bridge parameter_bridge /imu@sensor_msgs/msg/Imu[gz.msgs.IMU
# Bridge the IMU.
ros2 topic hz /scan
# Check the lidar rate.
ros2 run rqt_image_view rqt_image_view
# Look at the camera image.

What the example is doing

  1. 1.Lines without sudo only inspect or change files you own; sudo authorizes a system-wide change.
  2. 2.Read command output before moving to the next line. Stop if names, versions, disks, or paths differ from the lesson.
  3. 3.Comments beginning with # explain safety checks and are not executed by the shell.

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.

SENSOR VIEW

Demo for Simulated sensors. Expected result: average rate: 10.0

Practice code

Now type it yourself

Open a terminal, run the starter line by line (or save it as practice.sh and run bash practice.sh), and replace every TODO with your own command.

# TODO: bridge /scan from gz.msgs.LaserScan to sensor_msgs/msg/LaserScan

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 &
ros2 topic hz /scan

Expected result

How you know it worked

  • Each command completes without an unexplained error.
  • Your notes contain the command, the important output, and what it proves.

Practical exercise

Apply the lesson

Add a lidar, a camera and an IMU to your simulated robot, bridge all three, verify each rate with ros2 topic hz, and view each in RViz2 or rqt_image_view.

Before you continue

  • You recorded the starting state
  • Every command and output is understood
  • The change can be repeated from your notes

If something goes wrong

A command says permission denied.

Check ownership and permissions first. Do not add sudo unless the command changes a documented system location.

A command or package is not found.

Check spelling, Ubuntu version, enabled repositories, and whether the previous installation command succeeded.