Chapter 07 · Build a repeatable robot laboratory in Gazebo
Today in the field story
One problem, then the next
Spawn the warehouse robot inside the Rainy-Day Simulator Lab and map every boundary: Gazebo world, Gazebo Transport, ros_gz bridge, ROS 2 graph, ros2_control, wheels, odometry, and evaluation truth. Calculate the differential-drive result before commanding the simulation, then plant one radius and one sign fault separately and compare command, joint state, odometry, and ground truth.
- Why now
A moving model becomes useful only when interfaces and ideal geometry agree with observed simulated motion.
- Ignore today
Ignore autonomous planners and dynamic obstacles.
- Unlocks next
A verified mobile base ready to carry imperfect sensors.
Understand
Build the physical picture first
A simulated robot crosses three explicit boundaries—world, Gazebo Transport, and ROS 2—and movement is believable only when commands, wheel state, odometry, and ground truth agree.
Start-up is a sequence, not a pile of processes. Gazebo loads a named world and its systems. A spawn command creates one uniquely named robot entity from SDF or URDF-derived content at a known pose. The robot model exposes joints and plugins. ROS-side launch then starts only the bridges and controllers that the test needs. If two entities, topics, or frames share accidental names, the system may move while tools observe the wrong robot. Record entity name, ROS namespace, frame prefix, initial pose, and resource paths as part of the scenario.
Gazebo Transport and ROS 2 are different communication systems. ros_gz_bridge converts supported message types across that boundary in a declared direction: Gazebo to ROS, ROS to Gazebo, or bidirectional where appropriate. It does not convert every possible message, repair wrong units, invent frame IDs, or guarantee a useful QoS choice. Bridge /clock so ROS nodes can use simulation time, then bridge only the commands and observations required by the experiment. Inspect both sides of the boundary when a topic appears on one graph but not the other.
gz_ros2_control lets a normal ros2_control controller use simulated joints through state and command interfaces. For a differential-drive base, a controller converts requested forward and yaw velocity into left and right wheel rates using wheel radius and wheel separation. The simulated hardware updates joint state, and wheel odometry integrates that state into a moving pose estimate. A green active-controller state proves interface ownership; it does not prove that wheel radius, separation, signs, frames, or odometry are correct.
Gazebo ground truth gives a privileged reference for a test. Command a straight segment and a turn, then compare wheel-derived odometry with the internal simulated pose. Straight-line scale error suggests wheel radius or encoder scale; a wrong turn rate suggests separation; reversed motion suggests a sign or axis problem. Small divergence can also come from slip and contact modeling. The purpose is not to force odometry to equal truth forever, but to explain each difference with measured evidence and declared tolerance.
Words you need
Name each idea precisely
- Spawn
Create a model entity in a running Gazebo world with a chosen name and initial pose.
Physical example:A test launch inserts rover_01 at x = 0 m, y = 0 m, yaw = 0 rad rather than relying on a hand-dragged position.
- ros_gz_bridge
A converter that carries supported message types between Gazebo Transport and ROS 2 in configured directions.
Physical example:A Gazebo lidar message becomes a ROS sensor_msgs/LaserScan while a ROS velocity command travels toward Gazebo.
- gz_ros2_control
The Gazebo-facing ros2_control hardware integration that exposes simulated joint state and command interfaces.
Physical example:The same differential-drive controller contract can command simulated wheel joints before a separate real motor-driver backend is used.
- Wheel odometry
An estimate of robot motion obtained by integrating measured or simulated wheel rotation using wheel geometry.
Physical example:Ten wheel revolutions are converted to travelled distance using circumference, but slip can make the estimate differ from floor motion.
- Ground-truth pose
The simulator's internal model pose used as a reference for evaluating an estimate.
Physical example:Plot odometry x beside Gazebo's internal rover x to expose a five-percent wheel-radius error.
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.
For differential drive,
Predict a differential-drive command
A robot has wheel radius r = 0.10 m and wheel separation L = 0.50 m. The left wheel turns at 4 rad/s and the right at 6 rad/s.
Convert left angular rate to edge speed: 0.10 m × 4 rad/s = 0.40 m/s.
Convert right angular rate to edge speed: 0.10 m × 6 rad/s = 0.60 m/s.
Average the edge speeds for centre forward speed: (0.40 + 0.60) ÷ 2 = 0.50 m/s.
Find the edge-speed difference: 0.60 − 0.40 = 0.20 m/s.
Divide by wheel separation for yaw rate: 0.20 ÷ 0.50 = 0.40 rad/s.
Predict a forward-left arc, then compare signed command, joint rates, odometry, and ground truth.
The ideal no-slip model predicts v = 0.50 m/s and yaw rate = 0.40 rad/s.
A moving model can still be wrong; geometry and sign checks connect wheel state to body motion.
Physical examples
Where this appears in real life
Two-wheel hand trolley
Push both wheels equally and the trolley goes straight; make the right wheel edge move faster and the trolley turns left.
The centre speed comes from the average wheel-edge speed, while turning comes from their difference divided by the spacing.
Interpreter at a service desk
A clerk and customer use different languages, so an interpreter translates only phrases both sides have agreed to support.
Relate the two languages to Gazebo Transport and ROS 2, and note that translation cannot correct a false measurement or unclear meaning.
Hands-on exercise
Make the idea observable
Use the pinned Jazzy and Harmonic workspace, one saved world, and a differential-drive model with measured wheel radius and separation.
Launch the world, spawn one uniquely named robot at a recorded pose, and verify entity, namespace, frame, and topic ownership.
Bridge
/clockplus the minimum command and observation topics; inspect Gazebo and ROS topic types, direction, rate, frame IDs, and timestamps.Activate the simulated differential-drive controller and record requested body twist, wheel commands, measured joint states, odometry, and Gazebo ground truth.
Run one straight and one turning command within safe simulated limits; calculate the ideal result before plotting the observed result.
Plant one wheel-radius or wheel-sign error, reproduce its odometry signature, restore the correct value, and rerun both paths.
The planted radius fault creates a systematic scale mismatch, while a sign fault creates a direction or turning contradiction visible across several signals.
Another engineer can start the complete graph from one launch entry point, identify every bridge direction, and reproduce the clean and faulty odometry comparisons.
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 “ros_gz bridge, spawning, differential-drive kinematics, wheel odometry, and gz_ros2_control” runs from one documented command and the nominal plus boundary outputs are attached.
Common mistakes
Catch the wrong mental model
Using a dynamic bridge for everything and assuming every topic now has correct semantics.
Configure the required message pairs and directions explicitly, then verify type, QoS, unit, frame, timestamp, and rate on both sides.
Treating an active controller as proof that simulated motion is correct.
Compare command, claimed interfaces, joint state, odometry, and ground truth against a calculated known path.
Changing wheel radius and separation together while diagnosing odometry.
Change one controlled parameter at a time; use straight motion for scale and a turn for rotational geometry.
Job connection
How this becomes employable evidence
Integrate a vendor mobile-base model with ROS 2, prove the bridge and controller boundaries, and diagnose a wheel-geometry defect from command, state, odometry, and ground-truth traces.
Relevant target roles
- Robotics Application / ROS 2 Integration Engineer
- Robotics Software Engineer — ROS 2 / AMR
- Robotics Deployment, Integration & Validation Engineer
Chapter 07 interview drill
Interview questions: ros_gz bridge, spawning, differential-drive kinematics, wheel odometry, and gz_ros2_control
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 Gazebo rover spawns, accepts cmd_vel, and visibly moves, but odometry reports half the distance. Give an evidence order that distinguishes bridge, controller, wheel radius, encoder scale, frame, and clock problems.
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
Q1What does ros_gz_bridge do that gz_ros2_control does not?
The bridge converts supported Gazebo Transport and ROS 2 messages; gz_ros2_control exposes simulated joint state and command interfaces to ros2_control.
Q2If both equal-size wheels turn at the same signed rate, what ideal yaw rate should the base have?
Zero, because the wheel-edge speed difference is zero.
Q3Why compare wheel odometry with Gazebo ground truth?
The comparison exposes geometry, sign, integration, frame, and slip effects that a successful movement animation cannot reveal.