ROS 2 rosbag2 Storage Acceptance for Camera, LiDAR, and IMU
- Locate a recording gap across publisher, DDS, recorder, plugin and device before blaming storage.
- Evaluate storage plugin configurations (MCAP and SQLite3) alongside burst cache parameters for high-frequency sensor streams.
- Implement an acceptance test protocol combining recorder statistics, metadata verification, and playback timestamp validation.
A missing camera, LiDAR or IMU message in a ROS 2 bag is not automatically a disk fault. The publisher, middleware, recorder, cache, storage plugin and device form a chain. Qualify the exact ROS distribution and rosbag2 version with the target sensors, because plugin defaults and diagnostics can change.
Trace the first loss point
| Boundary | Record | Interpretation limit |
|---|---|---|
| Sensor/publisher | Expected and published message counters, timestamp source | A publisher gap exists before recording |
| DDS/RMW subscription | QoS settings and available loss events | Middleware loss is not disk loss |
| rosbag2 recorder/cache | Lost-message statistics, memory use and cache setting | A recorder gap needs further localization |
| Storage plugin and files | Selected MCAP/SQLite3 plugin, split policy, write errors | File errors may follow upstream loss |
| Block device | Time-aligned latency, queue and host errors | A storage stall is evidence only if it aligns with a recording gap |
The rosbag2 project documentation describes storage plugins, cache controls and loss statistics. Its SQLite3 plugin documentation shows that write settings have crash-recovery trade-offs. Do not change a durability preset simply to improve a benchmark.
Acceptance on the actual robot
Record serialized bytes and arrival bursts per topic, not only an all-day average. Run the intended camera, LiDAR and IMU combination, and include file rotation or snapshot mode if production uses it. Compare publisher and recorder counts over the same interval, inspect metadata and replay a sample bag for expected topics and timestamps. A replay that opens does not prove no messages were lost; compare counters and application requirements. Set the permissible loss and recovery behavior before testing. Send topic rates, plugin/version and device host details in a quote request.
We publish measured usable capacity and define trial-batch verification against the quoted product and agreed test scope.