Chapter 07 · Build a repeatable robot laboratory in Gazebo
Today in the field story
One problem, then the next
Mount lidar, camera, IMU, and encoders on named Rainy-Day Simulator Lab frames. For each, record message type, field meaning, unit, source stamp, expected rate, valid/invalid values, and known-pose observation. Keep CameraInfo beside images and reserve Gazebo truth for scoring; an algorithm must never receive privileged pose merely because the simulator makes it convenient.
- Why now
Fault injection is meaningful only after every nominal sensor contract is explicit.
- Ignore today
Ignore learned perception and sensor fusion.
- Unlocks next
A set of measurable streams whose noise, delay, and dropout can be distinguished.
Understand
Build the physical picture first
A simulated sensor is a measuring instrument with a viewpoint, clock, limits, and message contract—not a magic pipe that reveals the world.
Place each sensor on a named robot link with an explicit pose. Its data describes what that sensor could observe from that viewpoint, not the whole Gazebo world. A wall behind the lidar is occluded, a camera cannot see outside its field of view, and an encoder reports joint motion rather than floor travel. First verify the model pose and optical or measurement frame in RViz or the Gazebo scene. Then inspect topic type, frame ID, timestamp, unit, dimensions, update rate, and invalid-value rules before using the numbers.
A planar lidar usually becomes a ROS LaserScan. It contains an angle for the first beam, an angle increment, minimum and maximum usable range, and an ordered array of range values. Beam i points at angle_min + i × angle_increment in the scan frame. A range outside the sensor's contract may be represented as an infinite or invalid value; treating it as zero invents an obstacle at the sensor origin. Convert a valid beam to x and y only after confirming the angular convention and frame.
A colour camera normally publishes an Image plus CameraInfo. The image is a grid of pixel values; CameraInfo carries the calibration numbers needed to interpret pixels as rays. A depth camera adds an image or point-cloud quantity whose unit and invalid values must be checked. Camera optical frames use a conventional axis orientation that may differ from the robot base frame, so transforms matter. Large images also consume far more bandwidth than small IMU or encoder messages; a graph that works at low resolution may fail under production rate and size.
An IMU reports angular velocity and linear acceleration and may also report orientation depending on the modeled device and message. Acceleration can include gravity according to the chosen convention, so a stationary sensor does not automatically show three zeros. Encoders or simulated joint-state interfaces report joint position or velocity; wheel odometry then assumes geometry and contact. Compare every sensor with a controlled pose or motion and Gazebo truth, but remember that truth is an evaluation aid unavailable on a normal physical deployment.
Words you need
Name each idea precisely
- LaserScan
An ordered set of range measurements at known beam angles, with limits, frame, timestamp, and scan timing metadata.
Physical example:A 180-degree scan may contain hundreds of beams sweeping from the robot's right side through the front to its left side.
- CameraInfo
ROS camera calibration metadata used to relate image pixels to rays and account for the camera model.
Physical example:The focal-length and principal-point values explain which ray passes through a chosen image pixel.
- IMU
An inertial measurement unit that reports quantities such as angular velocity and linear acceleration, and sometimes orientation.
Physical example:A phone's IMU detects rotation and acceleration even when the camera sees a blank wall.
- Encoder
A sensor or simulated interface that measures a shaft or joint position, change, or speed.
Physical example:Wheel encoder counts can estimate rotation while a slippery floor prevents the expected body travel.
- frame_id
The named coordinate frame in which a stamped sensor message says its geometric data is expressed.
Physical example:A lidar range point begins in laser_frame and must be transformed before comparison with an obstacle in map.
Math, one line at a time
Work through today’s relationship
Prerequisite rescue · optionalSimulation time, real-time factor, and sensor noise
A simulator is useful only when time and uncertainty are measured honestly.
- RTF
- simulated elapsed time divided by real elapsed timeUnit: unitless
- μ
- average sensor valueUnit: sensor unit
- σ
- typical spread around the averageUnit: sensor unit
A run simulates 20 s but takes 25 s of wall time.
RTF = 20/25 = 0.8.
The simulator is slower than real time; compare timestamps in simulated time and report RTF with every performance result.
A test clock can be mocked in web software; robot sensor timestamps must still stay mutually consistent.
Ten simulated seconds take five real seconds. What is RTF?
10/5 = 2.0, so simulation runs twice as fast as real time.
At , distance traveled between samples is . Thus
These are sampling-distance checks, not claims about sensor accuracy.
Locate one valid lidar return
A scan starts at −90 degrees with 1-degree increments. Beam index 120 reports 2.0 m in laser_frame.
Calculate the beam angle: −90 degrees + 120 × 1 degree = 30 degrees.
Confirm 2.0 m is between range_min and range_max and is neither NaN nor infinity.
Calculate the forward component in the scan frame: x = 2.0 × cos 30 degrees ≈ 1.73 m.
Calculate the sideways component: y = 2.0 × sin 30 degrees = 1.00 m.
Keep the result labelled laser_frame and transform it at the scan timestamp before comparing it with base or map data.
The return is approximately (1.73 m, 1.00 m) in laser_frame under the declared angular convention.
A range array becomes geometry only after index, angle, validity, unit, frame, and timestamp are interpreted together.
Physical examples
Where this appears in real life
Car reversing camera and parking sensors
The camera shows texture in a cone behind the car, while ultrasonic sensors return a few distance estimates from different bumper positions.
Neither sensor sees the entire environment; mounting pose, field of view, occlusion, update rate, and invalid readings shape what the driver receives.
Phone on a desk
A stationary phone camera shows an unchanged image while the IMU still senses gravity and small noise; rotating the phone changes axis readings.
Keep the phone's local axes separate from the room axes, and do not expect stillness to make every acceleration component zero.
Hands-on exercise
Make the idea observable
Attach a lidar, RGB or depth camera, and IMU to the saved simulated robot; use one box and one wall at measured poses.
Draw each sensor frame and field of view, then verify the model mount and tf2 relationship before starting data inspection.
For every ROS topic, record message type, frame ID, stamp source, unit, dimensions, observed rate, QoS, and invalid-value convention.
Move the box to a known lidar beam and camera region; predict the range, beam index, image direction, and occlusion before reading messages.
Pause, step, rotate, and drive the world while comparing lidar, image, IMU, joint state, and Gazebo truth without changing multiple conditions at once.
Move the object outside range, behind an occluder, and beyond the camera field of view; record each sensor's valid absence or invalid output.
Each sensor fails or goes unobservable differently; a missing object is not the same as a missing message, invalid numeric value, wrong frame, or stale timestamp.
Your sensor-contract table and known-pose evidence let another engineer predict which messages change for visible, occluded, out-of-range, rotated, and paused cases.
Build today
Simulate a ros2_control differential-drive robot in Gazebo Harmonic with lidar, RGB-D camera, IMU, noise, bridges, and MCAP replay.
Evidence to save
DONE when a deterministic “Lidar scans, camera topics, IMU, and encoders” failure test reports expected versus actual behavior and passes after the documented fix.
Common mistakes
Catch the wrong mental model
Treating zero, infinity, NaN, and a missing message as the same lidar observation.
Apply the message's range and validity contract, and track transport freshness separately from measurement validity.
Assuming a simulated camera image already represents geometry in base_link.
Use CameraInfo to interpret pixels as rays and tf2 at the image timestamp to relate the optical frame to the robot.
Using Gazebo ground truth as an input to the robot algorithm.
Reserve truth for evaluation; feed the algorithm only the sensor and state interfaces that would exist on the real system.
Job connection
How this becomes employable evidence
Commission a simulated multi-sensor payload by proving mounting transforms, message contracts, known-pose outputs, invalid values, rates, and bandwidth before connecting perception nodes.
Relevant target roles
- Robotics Application / ROS 2 Integration Engineer
- Robotics Deployment, Integration & Validation Engineer
- Robotics Software Engineer — ROS 2 / AMR
Chapter 07 interview drill
Interview questions: Lidar scans, camera topics, IMU, and encoders
Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.
Primary interview scenario
A lidar topic publishes at the expected rate, but obstacles appear rotated and some ranges are zero. Explain how you would check scan indexing, invalid values, mounting frame, transform time, and visualization assumptions.
Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.
Technical follow-up questions
Q1At what angle is beam i in a LaserScan?
Under the message's convention it is angle_min + i × angle_increment.
Q2Why does a camera image normally need CameraInfo?
Pixel indices alone do not define physical rays; calibration metadata supplies the camera model used to interpret them.
Q3Why can wheel encoders report motion while the robot hardly moves?
They measure joint or shaft rotation; wheel slip can break the assumed relationship between rotation and floor travel.