Chapter 07 · Build a repeatable robot laboratory in Gazebo
Today in the field story
One problem, then the next
Record the Rainy-Day Simulator Lab’s selected topics to MCAP with a manifest that names types, QoS, duration, expected counts, transform and clock coverage, configuration, and result assertion. Replay nominal and planted failures more than once. The bag captures messages, not the complete world, code, launch order, external state, or scheduling, so deterministic claims must include those dependencies.
- Why now
The chapter needs durable evidence and a repeatable input path before health and regression behavior are judged.
- Ignore today
Ignore recording every topic without a question or storage budget.
- Unlocks next
A replay fixture for sensor health, navigation, perception, and state estimation.
Understand
Build the physical picture first
An MCAP bag is a labelled recording of ROS messages, not a recording of the entire world that produced them.
rosbag2 subscribes to selected ROS 2 topics and stores their serialized messages plus metadata. MCAP is a storage format supported through the rosbag2 MCAP plugin; it keeps multiple message channels in a structured file and works with ordinary record, info, and play operations. Choose topics from a replay question rather than recording everything without limit. To reproduce a stale-lidar stop, for example, capture /clock, lidar, transforms, odometry, command requests, bounded output, diagnostics, and the final result state.
A successful record command does not prove completeness. Inspect start and end time, duration, topic types, message counts, offered QoS, file splits, and storage errors. Expected count is nominal rate multiplied by duration, but startup boundaries and intentional drop policies must be declared. Average rate can hide a single dangerous gap, so also calculate maximum inter-stamp and inter-arrival gaps. High-bandwidth images can fill disk or delay writes; define storage budget, split policy, and the behavior when recording fails.
DDS QoS still matters at the recorder and player boundary. rosbag2 adapts profiles in many cases, but some topics need explicit overrides for compatible reliability, durability, or history. A bag with zero camera messages may reflect QoS incompatibility rather than a silent camera. During playback, decide whether to publish a clock and configure consumers for simulation time. Do not let live and replay publishers accidentally feed the same topic unless the test deliberately names and controls both sources.
Message replay is not full deterministic execution. The bag does not automatically contain the world file, code revision, dependencies, parameters, calibration, environment variables, transforms published outside the capture window, random seeds, launch order, or external services. Even identical messages can trigger a different callback order under concurrency. Bundle these inputs, start from a clean state, replay more than once, and compare a declared result. Say reproducible when the bounded outcome repeats under the recorded contract; do not promise bit-for-bit determinism without evidence.
Words you need
Name each idea precisely
- rosbag2
The ROS 2 recording and playback system for serialized topic messages and associated metadata.
Physical example:A test records scans, transforms, odometry, commands, and diagnostics during one simulated stop.
- MCAP
A structured storage format available to rosbag2 for keeping multiple timestamped message channels and metadata.
Physical example:One MCAP recording contains lidar and odometry channels whose counts and timing can be inspected before replay.
- QoS override
An explicit recorder or player policy used when the automatically chosen reliability, durability, or history is not suitable.
Physical example:A best-effort sensor publisher may require a compatible recording profile to avoid receiving no images.
- Playback clock
A clock emitted during replay so simulation-time consumers can follow the recording's time progression.
Physical example:Pausing playback pauses the consumer's experiment time instead of letting wall-time timers advance.
- Replay contract
The complete set of captured messages, code, configuration, time rules, initial state, and expected outputs required to repeat a test.
Physical example:A bag plus a pinned container, parameter dump, world, seed, launch entry point, and terminal-state assertion forms a useful regression fixture.
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.
Expected messages are
With recorded,
Measure recording completeness
A lidar is configured for 20 Hz during a declared 60 s capture. ros2 bag info reports 1,188 lidar messages.
Calculate nominal expected count: 20 messages/s × 60 s = 1,200 messages.
Calculate count difference: 1,200 − 1,188 = 12 messages.
Calculate count completeness: 1,188 ÷ 1,200 × 100 = 99 percent.
Inspect the first and last timestamps so startup or shutdown boundaries are not mistaken for mid-run loss.
Calculate the maximum inter-stamp and arrival gap to see whether the 12 missing samples form one long outage or small scattered gaps.
Check recorder QoS, errors, storage throughput, and the original publisher before assigning a cause.
The simple count is 99 percent of nominal, but timing and QoS evidence are still required to explain the missing 1 percent.
Count is a useful first check; gaps, boundaries, QoS, and storage evidence determine whether the recording is fit for replay.
Physical examples
Where this appears in real life
Aircraft flight recorder
A flight recorder captures selected channels and conversations, but investigators still need aircraft configuration, weather, maintenance, and procedures.
Relate selected recorded channels to topics and the missing operating context to code, parameters, world state, and external services.
Recipe video without ingredient amounts
A video shows actions in order but omits exact quantities and oven settings, so a viewer may not reproduce the cake.
Message order alone does not replace effective configuration, initial state, versions, and timing rules.
Hands-on exercise
Make the idea observable
Use the saved simulated sensor scenario and create a small evidence manifest before recording.
List the failure question, required input and output topics, expected rates, QoS, time source, duration, storage budget, and terminal-state assertion.
Record the selected topics using MCAP, then inspect metadata, types, counts, duration, file size, and maximum stamp gaps before playback.
Save the world, robot description, effective parameters, code revision, dependency versions, seeds, launch command, and QoS overrides beside the bag.
Start the consumer stack from a clean state, play with the intended clock policy twice, and capture message counts, output values, event order summary, and terminal result.
Plant one QoS or omitted-topic failure, show the decisive evidence, restore the manifest, and repeat the clean replay.
Playback can complete while a required topic is absent, a clock is wrong, or concurrency changes event order; the result assertion reveals whether the replay answered the intended question.
Another engineer can inspect the manifest, identify recording completeness, reproduce the normal result and planted replay failure, and state what the bag does not capture.
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 comparison table for “rosbag2/MCAP recording, playback, and deterministic replay” contains the test condition, metric, result, and justified engineering decision.
Common mistakes
Catch the wrong mental model
Recording every topic without a question, size limit, or failure policy.
Define the replay claim, select the minimal required channels, budget storage, and verify required counts and gaps.
Calling a non-empty MCAP recording complete.
Inspect topic types, counts, duration, gaps, QoS, errors, and required transform or clock coverage.
Claiming deterministic replay from the bag file alone.
Pin code, dependencies, parameters, initial state, time policy, QoS, seeds, launch order, and external inputs, then measure repeated outcomes.
Job connection
How this becomes employable evidence
Convert an intermittent simulated sensor failure into a small MCAP regression fixture with verified completeness, pinned environment, repeatable playback, and a terminal behavior assertion.
Relevant target roles
- Robotics Deployment, Integration & Validation Engineer
- Robotics Software Engineer — ROS 2 / AMR
- Robotics Application / ROS 2 Integration Engineer
Chapter 07 interview drill
Interview questions: rosbag2/MCAP recording, playback, and deterministic replay
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 colleague sends a bag and says the bug is reproducible, but your output differs. List what you would verify beyond pressing play and why callback order may still vary.
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
Q1Why can ros2 bag info show zero messages for a topic that was visibly publishing?
The recorder may have discovered the topic but had incompatible QoS or another subscription or storage failure; inspect the offered and requested profiles and recorder evidence.
Q2What is missing from a bag if a static transform was published before recording and not captured?
The replay may lack the transform needed to relate sensor frames, unless it is launched separately or captured with the required durable behavior.
Q3Why run the same replay more than once?
It exposes output or event-order variation caused by concurrency, unpinned state, randomness, or external inputs.