Delivery format
ROS bag format for robot training data
ROS bag is useful for robot-native data collection where buyers need ROS topics preserved for replay or conversion. Define topic list, message types, timestamps, sensor calibration, and conversion notes before reviewing samples so you can verify that delivery matches the training pipeline.
Quick facts
- Origin
- ROS (Robot Operating System) — Open Robotics, originally released 2007. Bag v2 is the legacy ROS 1 format; Bag v2/SQLite is the ROS 2 format.
- Status
- Foxglove and the ROS 2 community recommend MCAP as the long-term replacement; Bag remains common in 1000s of deployed robot fleets.
- Conversion path
- rosbag-to-mcap is a documented, lossless conversion — buyers can require MCAP delivery and accept Bag-native sources from up to 20+ years of legacy logs.
- Required fields
- Topic list, message types, timestamps, sensor calibration, conversion notes.
Comparison
| Format choice | Strength | Risk |
|---|---|---|
| ROS bag | robot-native data collection where buyers need ROS topics preserved for replay or conversion | Needs exact schema agreement before capture |
| Raw files | Fast supplier export | High buyer cleanup burden |
| Custom schema | Matches internal pipeline | Harder supplier onboarding |
What is ROS bag?
ROS bag should be requested when the buyer's training or evaluation pipeline already expects robot-native data collection where buyers need ROS topics preserved for replay or conversion. Anchor the bounty to the canonical specification before suppliers submit samples [1], then use implementation documentation to make the expected file layout reviewable [2]. Robotics teams should also name the dataset or paper lineage they expect suppliers to support [3].
[1]"The file consists of a version line followed by one or more records."
For truelabel buyers, that quote matters because it turns ROS bag training data from a generic delivery preference into a source-backed requirement the supplier can test against a sample file.
Using ROS bag with robot data
A useful ROS bag sample should prove topic list, message types, timestamps, sensor calibration, and conversion notes, plus file naming, manifest completeness, timestamp behavior, and rejected-example traceability. Include at least one workflow or converter reference so the supplier can show how the files load in practice [4], one interoperability reference for adjacent formats [5], and one comparison source for why this format is preferable to a raw folder dump [6].
Related pages
Use these to move from category-level context into specific task, dataset, format, and comparison detail.
External references and source context
- ROS bag format 2.0
The ROS wiki documents the version 2.0 rosbag file format.
ROS Wiki ↩ - ROS bag documentation
ROS documentation covers recording bag files from robot nodes.
docs.ros.org ↩ - Reading from a ROS bag file
ROS documentation covers reading from bag files for replay and inspection.
docs.ros.org ↩ - ROS: an open-source Robot Operating System
The ROS paper is a foundational reference for ROS-native data workflows.
ICRA Workshop on Open Source Software ↩ - rosbag2_storage_mcap
The MCAP storage plugin documents an interop path for rosbag2 workflows.
GitHub ↩ - MCAP specification
MCAP is a related container format for robotics logs.
MCAP ↩
FAQ
What is ROS bag used for?
ROS bag is used for robot-native data collection where buyers need ROS topics preserved for replay or conversion.
What fields should ROS bag delivery require?
At minimum, require topic list, message types, timestamps, sensor calibration, and conversion notes, plus a delivery manifest and validation notes.
Can suppliers convert into this format?
Some suppliers can deliver directly in the requested format; others may need conversion. Buyers should require a small sample before full delivery.
Should the format be decided before capture?
Yes. Deciding the format before capture prevents missing fields, timestamp drift, and expensive post-delivery cleanup.
Working with ROS bag training data
Truelabel normalizes ROS bag training data across capture partners so you can ingest one consistent schema instead of writing per-vendor adapters.
Request ROS bag data