rosbag2 records timestamped ROS 2 messages and replays them through ROS interfaces. A completed bag directory does not prove that every required topic connected, that messages kept their physical timing or that storage sustained sensor bursts. Data acceptance must be performed per topic.
QoS compatibility affects whether the recorder receives data and whether playback reaches consumers. Source header stamps can differ from recorder receive time. Compression, cache size, storage plugin and file splitting trade resources and recovery behavior. Preserve these choices with the bag.
Use this guide with the ROS 2 QoS guide and robot learning data-quality audit. Isolate actuators before replaying commands.
Treat a bag as a timed message dataset
The value of a bag comes from message payload, topic identity, type definition, source timestamp, recording timestamp and surrounding system configuration. A large file can still miss a low-rate mode topic that explains every command in the high-rate streams.
Define the analysis or reproduction goal before recording. Training, incident reconstruction, calibration and visualization require different topics and time accuracy. Record a machine-readable manifest with required and optional streams.
Freeze topics, types and expected rates
List topic name, type, expected publishers, nominal rate, maximum gap, QoS and retention priority. Include /tf, /tf_static, clock, calibration, parameters or mode changes when they are needed to interpret sensor and action data.
Auto-discovery can capture new topics, but it does not guarantee that a short-lived topic appears before discovery polling or that an incompatible endpoint exchanges data. Compare the final bag metadata with the manifest after every run.
| Contract item | Before record | After record | Failure signal |
|---|---|---|---|
| Topic and type | Freeze manifest | Compare metadata | Missing stream |
| Rate and count | Estimate duration count | Measure gaps | Burst loss |
| QoS | Inspect publishers | Confirm connection | Silent zero count |
| Clock | Declare time source | Detect steps and zero time | Broken chronology |
| Configuration | Version software and calibration | Store alongside bag | Uninterpretable data |
QoS can create a silent empty topic
The recorder is a subscription and must be compatible with publishers. Reliability and durability mismatches can prevent communication. Overrides may be required, but they should be derived from inspected endpoints rather than applied globally.
Run endpoint inspection and a short trial before the mission. The current rosbag2 repository and documentation track features by branch, so archive the exact ROS distribution and package version used.
Separate source stamp from receive time
A message header may represent exposure, sampling, driver processing or another source-defined event. rosbag2 also records when the recorder receives the serialized message. Network and executor delay can separate these times, while some messages have no standard header.
Document timestamp semantics for each topic. Compare source and record time distributions and flag impossible ordering. A bag with monotonic record time can still contain sensor stamps from an unsynchronized device.
Size for bursts rather than average throughput
Calculate average bytes per second, then test simultaneous camera, lidar and point-cloud bursts. Serialization, cache copies, compression and storage flushes create short peaks. A disk benchmark using one sequential file does not reproduce the full pipeline.
Monitor recorder cache occupancy, dropped-message indicators, CPU, memory, disk latency and thermal state. Run for mission duration with every producer active. Leave space for metadata, splits and failure recovery rather than filling the filesystem to its limit.
| Bottleneck | Metric | Stress condition | Mitigation to test |
|---|---|---|---|
| Discovery or QoS | Connected topic count | Late publisher | Static list or override |
| Recorder cache | Occupancy and drops | Sensor burst | Cache and writer tuning |
| CPU | Utilization and callback delay | Compression | Thread and codec choice |
| Storage | Write latency and queue | Flush or thermal limit | Faster media or split |
| Playback consumer | Sample age and queue | High replay rate | Rate and QoS plan |
Choose storage and splitting for recovery
Storage plugins differ in format and behavior. File splitting limits the unit that must be copied, indexed or recovered after interruption. Split by size or duration according to operational handling, but verify that consumers receive required transient-local context in each segment.
Test abrupt power loss, process termination and reindex or recovery procedure on representative media. A design that maximizes one large file may increase incident loss and delay field upload.
Compression trades storage for compute and delay
Compression can reduce disk bandwidth and capacity while consuming CPU and adding latency. Message and file compression have different granularity and recovery properties. Highly compressed camera topics may gain little while still paying processing overhead.
Benchmark the exact topic mix and codec on the recording computer. Measure total drops, CPU tails, write latency and final size. Do not enable compression by policy without verifying that the recorder remains ahead of worst-case input.
Use snapshot recording for pre-event evidence
A circular or snapshot workflow keeps recent data in memory and writes it when an event occurs. This preserves context before an intermittent fault without storing an entire shift. It also risks losing the buffer when power disappears or triggering too late.
Define buffer duration, memory cap, trigger source and post-event interval. Test multiple triggers, split behavior and concurrent copying. Record the trigger event itself so analysts can align cause and capture.
Handle simulation time and clock jumps explicitly
When recording with simulation time, the recorder depends on /clock. Current rosbag2 documentation warns that recording before the first valid clock can produce zero-time problems; playback behavior also depends on clock publication and consumers’ use_sim_time settings.
Test pause, reset, backward jump and restart. Store the world, seed and simulator version. Treat a time jump as an episode boundary unless the downstream tool explicitly supports it.
Playback recreates a new endpoint contract
During playback, rosbag2 becomes the publisher. Consumer QoS, expected rate, clock mode and startup order can differ from recording. Transient state and static transforms must be available when late consumers start.
Inspect playback QoS overrides and start consumers in a controlled order. Use a sandbox namespace and disabled hardware outputs. A recorded velocity or actuator command should never reach a live robot merely because the topic name matches.
Accept each topic by count, gaps and semantics
For every required stream, compare actual count with duration and expected rate, calculate inter-message gaps, inspect timestamp monotonicity and sample payloads. Cross-check related topics such as image and camera info, state and command, or transform and point cloud.
Then replay through a reference consumer and verify useful output. File size alone cannot reveal a missing low-bandwidth topic, corrupt calibration or time-domain mismatch.
Operate recording as a controlled procedure
Before recording, verify storage space, clock, topic manifest, QoS connection and software configuration. After recording, stop cleanly, run integrity checks, compute hashes and move the data with its manifest and rights information.
Use a release checklist before data enters training or incident analysis.
- Freeze required topics, types, QoS and rates.
- Test burst throughput for mission duration.
- Compare source and record timestamps.
- Accept each topic by count, gaps and replay.
- Keep bags isolated from live actuator topics.
Frequently asked questions
Does rosbag2 record every topic when it is running?
Only selected or discovered compatible topics are recorded; short-lived, incompatible or overloaded streams can be absent.
Does Reliable QoS eliminate recording loss?
No. Compatibility, caches, CPU, storage and publisher behavior can still cause gaps or delay.
Should compression always be enabled?
No. Benchmark size savings against CPU, latency and message drops for the actual topic mix.
Is expected file size enough to accept a bag?
No. Validate each topic’s count, gaps, timestamps, payload and replay result.
Can a bag be replayed directly into a real robot?
Not safely by default. Isolate namespaces and hardware, inspect command topics and validate the playback environment first.
Recorded Data Evidence Boundary
A rosbag is a recording of ROS messages, not proof of physical truth or complete coverage. Validate clocks, QoS, content and configuration before relying on it.