MCAP vs ROS Bag for Robotics Training Data

Neither is better in the abstract, and they overlap more than the question suggests. MCAP, per mcap.dev, is an open source container file format for multimodal log data that stores multiple channels of timestamped, pre-serialized messages. A ROS bag, per the rosbag2 README, is simply a file full of timestamped messages, and rosbag2 is the ROS 2 tool for recording and playing back communications. Because rosbag2 has an MCAP storage plugin, a ROS 2 recording can be an MCAP file, so for many labs the real question is whether the data should depend on ROS tooling at all or only on a log container.

This page is a decision guide for labs choosing a delivery container for stereo egocentric training data. It is not a benchmark. The sources read for it state no read speeds, write speeds, compression ratios or file sizes for MCAP or for rosbag2, and the Firsthand site states none for its deliveries, so none appear here. Where a detail is missing the page says Not stated. Firsthand is not affiliated with Foxglove, the MCAP maintainers or the ROS project maintainers.

Firsthand offers MCAP delivery. The site does not state ROS bag delivery, so this page never claims it. Where coverage is deep, the median to first validated batch is 48 hours, and for work the catalog does not cover yet, Firsthand runs custom collection at scale through a network of thousands of capture providers, for a consistent, recurring data flow to labs. The sections below set out what each format is, how each holds time-stamped multi-stream data, what tooling the official sources list, and when each one tends to fit.

The mcap.dev home page describes MCAP as an open source container file format for multimodal log data, supporting multiple channels of timestamped pre-serialized data and ideal for pub/sub or robotics applications. It is a Foxglove project, and the foxglove/mcap README calls it a modular, performant, serialization-agnostic container file format under the MIT License. Serialization-agnostic means the container does not dictate the message encoding: the home page lists Protobuf, DDS (CDR), ROS and JSON among the formats it can record and replay.

The home page lists the design choices that matter to a data buyer. The design is row-oriented and append-only, to minimize disk I/O and reduce the risk of data corruption during unclean shutdowns. Schemas are stored alongside the data, so files stay readable as a codebase evolves. An optional index allows efficient seeking, even over a low-bandwidth internet connection, and chunk-based compression can use LZ4 or Zstandard while still supporting indexed reads. Chunking, indexing, CRC checksums and compression are optional features, so a given file may or may not have them. The page also states that MCAP is used in production by a wide range of companies, from autonomous vehicles to drones, and that it is the default log format in ROS 2. The README gives the registered media type as application/vnd.mcap.

The ros2/rosbag2 README opens with a plain definition: rosbag2 is the tool for recording and playback of communications in ROS 2 systems, and a rosbag is simply a file full of timestamped messages. It names two goals in order. The first is efficient recording, to support complex systems in real time, and the second is efficient playback, to allow viewing and using the recorded data. The README calls it the ROS 2 successor of the original rosbag, and the repository is listed under the Apache License 2.0.

In use, rosbag2 is part of the ROS 2 command line interface as ros2 bag, with the verbs burst, convert, info, list, play, record and reindex. You record all available topics with the -a option or choose topics explicitly, and recording writes a new folder named for the current time, or a name you give, holding a metadata.yaml and one or more storage files. The ROS 2 documentation tutorial describes the same flow and adds that ros2 bag can record data from topics, services and actions. A bag is therefore described first as a recording of a running ROS 2 system, made by a tool that is installed with ROS 2.

The rosbag2 README describes itself as the ROS 2 successor of the rosbag tool documented on the ROS wiki. The ROS wiki page returned a bot-check page when it was fetched for this guide, so it was not read, and this page states no property of the ROS 1 .bag file format. Compression, indexing, licence, tooling and conversion details for ROS 1 bags are Not stated here. If your pipeline still produces ROS 1 bags, treat the comparison on this page as covering ROS 2 bags and MCAP only, and read the official ROS 1 documentation directly before deciding.

The MCAP sources read here do not compare MCAP with ROS 1 bags either. The MCAP ROS 2 guide covers conversion from ROS 2 .db3 files, not from ROS 1 .bag files, so do not assume a conversion path exists for ROS 1 data. The Firsthand site does not state delivery of ROS 1 or ROS 2 bags, so a request for either belongs in the skill spec as a question rather than an assumption.

rosbag2 stores bags through storage plugins, and the README links documentation for two: mcap and sqlite3. The rosbag2_storage_mcap package is described as a storage plugin that extends rosbag2 with support for the MCAP file format, available as part of current ROS 2 distributions. You select it by adding the option -s mcap to ros2 bag record, play and info. The ros2 bag play command accepts either a directory holding metadata.yaml and storage files, or a single storage file such as .mcap or .db3, and detects the storage implementation automatically.

The MCAP ROS 2 guide states that ROS 2 supports recording directly to MCAP using the rosbag2 MCAP storage plugin. It also covers existing .db3 files, which can be converted with ros2 bag convert or the mcap CLI, with a caveat: converting may produce different results from recording directly in MCAP. The guide adds that ROS 2 Iron and later embed message definitions when recording, so those bags convert with the CLI without a sourced workspace, while earlier bags need ros2 bag convert with the original workspace sourced.

The result is that MCAP and ROS bag are not two sides of one fork. A ROS 2 bag can use MCAP as its storage, and an MCAP file can hold ROS-encoded messages. The choice that remains is between a ROS-centric workflow built around ros2 bag, and a container-centric workflow where any reader with an MCAP library can open the file.

Both hold multi-stream data as timestamped messages. In MCAP, per mcap.dev, a file carries multiple channels of timestamped pre-serialized data, so a multi-stream recording is a set of channels on one time axis. In rosbag2, you pick the topics to record, and messages from several bags played together with -i are played in order, based on their original recording reception timestamps. The player can order messages by reception timestamp or by publication timestamp, with reception as the default.

Time source matters for training data. The rosbag2 README notes that with --use-sim-time the recorder stamps messages with the latest /clock value, and that nothing is written until the first /clock message is received. For Firsthand capture, the site states hardware-triggered synchronization onto one clock, with a 1.12 ms median and a 2.0 ms ceiling. The site does not state how that sync maps to message times in an MCAP file, so ask for it in the spec, and verify alignment yourself rather than assume the container preserves it.

The Firsthand site states these streams for its stereo egocentric work: a stereo pair from dual fisheye cameras at 1080p per eye with a 62 mm baseline on dataset 06, head and wrist RGB, metric depth at 848×480 and 30 Hz, hand pose of 21 joints per hand with a per-joint visibility flag, and a 9-axis IMU on dataset 06. Calibration is measured every session and shipped with the episode. The streams table above sets each against what the site states for an MCAP delivery. Where the site does not say, the table says Not stated.

The honest gap is the file layout. The site does not state MCAP topic names, message schemas, encodings, rates or files per episode, and it does not state which streams are channels. Those are agreed in the skill spec and confirmed on a Spec Pilot. The same applies if you work through ROS: a bag records messages with a type per topic, as the ros2 bag info output in the tutorial shows, and the site does not state types for these streams either.

For MCAP, mcap.dev lists native reader and writer libraries in C++, Go, Python, Rust, Swift and TypeScript. The README adds a CLI to inspect, merge and split files, installable with brew install mcap, and the ROS 2 guide adds that the CLI can validate files, echo their messages to stdout and convert .db3 files.

For rosbag2, the README says packages are available as Debian packages and are included in any -ros-base installation, which is included within -desktop. The tooling is ros2 bag, with verbs for record, play, info, convert, reindex, list and burst. The recorder and player can be controlled remotely through services such as pause, resume, split, snapshot and playback rate, and a snapshot mode keeps an in-memory circular buffer that is written to disk on request. Playback can be filtered by topic, service or action and by regular expression, and the recorder can publish statistics about lost messages. The repository is listed as C++, CMake and Python. Reader libraries for bags outside ROS are Not stated in the pages read.

The practical difference is the dependency. An MCAP file is opened with an MCAP library in one of six languages, and the sources name no ROS stack as a requirement. A bag is described through ros2 bag, which is part of a ROS 2 installation. That is a reading of the sources, not a measured comparison.

MCAP offers optional chunk-based compression with LZ4 or Zstandard that still supports indexed reads, an optional index for seeking, and optional CRC checksums, and the home page says you configure chunking, indexing, CRCs and compression to make the right trade-offs. rosbag2 compression is off by default. When enabled, the only format available is zstd, applied either by file or by message, and the README recommends using it with the splitting options.

The rosbag2 README draws the link between the two directly: the MCAP storage plugin supports compression in a way that produces files that are still indexable, whereas rosbag2 compression does not. The plugin documentation lists writer options for chunk size, compression of None, Lz4 or Zstd, compression level, CRCs, and whether to write a message index or summary. It offers presets named fastwrite, zstd_fast and zstd_small. The fastwrite preset targets the highest write throughput and lowest resource use on resource-constrained robots, calculates no CRCs and writes no message index. The README says using such files as long-term storage is not recommended, because reading a subset of topics or seeking will not work without the index, and suggests post-processing them afterwards.

Splitting works differently. rosbag2 can split bag files by size or by duration while recording and writes a single file by default, while the mcap CLI can split files after the fact. The site does not state file sizes for its MCAP deliveries, so confirm them in the spec.

Pick MCAP when you want the file to be readable without a ROS installation in the loop. The mcap.dev home page lists native libraries in six languages and a CLI, and schemas are stored in the file, so the data stays readable as your codebase evolves. Pick it when you want several streams on one time axis with an index for seeking, when you replay or inspect data from the command line, or when your tooling already reads ROS 2 logs, since mcap.dev calls MCAP the default log format in ROS 2. It is also the container the site states for its off-the-shelf stereo head rig, dataset 06.

Pick it with eyes open. MCAP is a container of messages, not an episode schema. The site does not state how episode boundaries, action segments or contact events appear in an MCAP file, so if you need them inside the file, say so in the spec. If your training loop expects RLDS, LeRobot or WebDataset, MCAP is not a training format on its own, so name the training format alongside it.

Pick a ROS bag when your lab runs ROS 2 end to end and ros2 bag is already how you record, inspect and replay. The README lists the verbs, the services for pause, seek and rate, snapshot mode and lost-message statistics, which are features of the rosbag2 tool rather than of a container file. Pick it when you need to replay recorded services or actions into a running system, which the README describes through ros2 bag play options such as --send-actions-as-client. Because the MCAP plugin exists, picking a ROS 2 bag does not rule out MCAP files: you can record with -s mcap and keep the ros2 bag tooling.

Pick it with eyes open. The site does not state ROS bag delivery, so ask in the skill spec whether it is offered rather than assuming it. The README also notes that some storage plugins have their own compression, separate from the rosbag2 compression options, so settle the storage plugin first. The MCAP guide says ROS 2 .db3 files are not completely self-contained, which matters for archives you expect to read years from now.

No. The site states MCAP as one packaging option among several, and says a custom order is packaged in the format you name, such as MP4 with JSON or CSV, MCAP, LeRobot or a custom layout. The same captured and annotated episodes are stated to ship as RLDS, LeRobot, WebDataset, HDF5 and zarr, with Rerun .rrd for inspection. ROS bags are not among the formats the site lists.

On the ROS side, conversion is documented in one direction: ros2 bag convert and the mcap CLI turn ROS 2 .db3 files into MCAP. The guide warns that specifying compression_mode and compression_format directly in the convert YAML file results in an unplayable bag, and that conversion may differ from recording directly in MCAP. If you receive MCAP and work in ROS 2, the README says ros2 bag play accepts a single .mcap storage file and detects the storage implementation, but whether a given delivery plays cleanly against your ROS message definitions is Not stated and worth testing on a Spec Pilot. Rerun .rrd is for inspection rather than training, and the RLDS vs LeRobot comparison covers the training side.

Firsthand offers MCAP delivery. The off-the-shelf stereo head rig, dataset 06, ships as MCAP with dual fisheye cameras at 1080p per eye, a 62 mm baseline, per-unit calibration, a 9-axis IMU and hand-tracking output, and a custom order is packaged in the format you name. Off-the-shelf coverage and custom collection work together: start from the off-the-shelf pages to see formats and streams, then specify custom collection for the skills and environments you need. Custom collection runs at scale through a network of thousands of capture providers, for a consistent, recurring data flow to labs.

The site does not state MCAP topic names, message schemas, encodings, rates or files per episode, whether its MCAP files use chunking, compression, CRC checksums or an index, or whether any delivery plays with ros2 bag. It does not state ROS bag or ROS 1 delivery. Those are questions for the skill spec and a Spec Pilot, and this page does not answer them for you. For a format example, see the stereo sample clip page, which shows rig output and is a format example, not an MCAP file or a ROS bag.

The first failure is assuming the container fixes the schema. MCAP leaves message encoding to you, and a ROS bag leaves message types to the ROS interfaces behind each topic, so write down topic names and encodings before the first batch. The second is an unindexed file. The rosbag2 MCAP plugin documentation says files written with the fastwrite preset have no message index, so reading a subset of topics or seeking does not work until they are post-processed, so ask for indexed files if you need lookup by topic or time. The site does not state whether its MCAP files are indexed, so ask.

The third is mixing compression layers. The README says rosbag2 compression does not produce indexable files while MCAP plugin compression does, so choose one layer deliberately. The fourth is trusting a conversion: the MCAP guide says converting .db3 files may give different results from recording in MCAP directly, and bags recorded before ROS 2 Iron do not contain embedded message definitions, so the CLI cannot convert them directly. The fifth is clock confusion: with --use-sim-time nothing is written until the first /clock message arrives, and playback can order messages by reception or publication time. The sixth is assuming sync survived export. The site states a 2.0 ms ceiling at capture, so verify alignment in the delivered file.

Write a skill spec that names the task, the environment and the streams you need, and name the delivery container: MCAP, another format the site lists, or both. If ROS tooling is in your loop, say so and ask in the spec whether files must play with ros2 bag, since the site does not state it. Confirm the layout on a Spec Pilot, then pay per validated hour. Where coverage is deep, the median to first validated batch is 48 hours.

For work that needs scale, custom collection runs at scale through a network of thousands of capture providers, for a consistent, recurring data flow to labs. Use the Request a custom dataset button below, or read the MCAP hub page first for the stereo capture and MCAP delivery detail.