Delivery format
MCAP format for robot training data
MCAP is useful for time-synchronized robotics logs, compressed video topics, IMU, state, and action messages. Define topic schema, timestamp domain, compression settings, camera topic, state topic, and manifest before reviewing samples so you can verify that delivery matches the training pipeline.
Quick facts
- Origin
- Foxglove — MCAP container at mcap.dev, Apache-2.0 license; v1.0 specification published in 2022 as a successor to ROS bag for multi-language robotics logs.
- Format design
- Self-describing chunked binary; schema-aware; supports protobuf, ROS 1, ROS 2, JSON, FlatBuffer — 5 message-encoding ecosystems.
- Compression
- Built-in lz4 and zstd; per-chunk indexing for fast random reads (10x improvement over rosbag for partial-frame access).
- Tooling
- Foxglove Studio, mcap CLI, plus reader/writer libraries for Rust, Python, C++, Go, TypeScript (5 official SDKs).
Comparison
| Format choice | Strength | Risk |
|---|---|---|
| MCAP | time-synchronized robotics logs, compressed video topics, IMU, state, and action messages | 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 MCAP?
MCAP should be requested when the buyer's training or evaluation pipeline already expects time-synchronized robotics logs, compressed video topics, IMU, state, and action messages. 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]"MCAP is a modular container format and logging library for pub/sub messages with arbitrary message serialization."
For truelabel buyers, that quote matters because it turns MCAP robot data from a generic delivery preference into a source-backed requirement the supplier can test against a sample file.
Using MCAP with robot data
A useful MCAP sample should prove topic schema, timestamp domain, compression settings, camera topic, state topic, and manifest, 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
- MCAP specification
MCAP is a container format for pub/sub message logs.
MCAP ↩ - MCAP guides
MCAP guides document using MCAP with robotics data.
MCAP ↩ - Foxglove MCAP documentation
Foxglove documents MCAP in visualization workflows.
Foxglove ↩ - rosbag2_storage_mcap
rosbag2_storage_mcap connects MCAP to ROS 2 bag storage.
GitHub ↩ - ROS bag format 2.0
ROS bag is the incumbent robot-native log format MCAP is often compared with.
ROS Wiki ↩ - ROS bag documentation
ROS documentation explains recording bag files from robot nodes.
docs.ros.org ↩
FAQ
What is MCAP used for?
MCAP is used for time-synchronized robotics logs, compressed video topics, IMU, state, and action messages.
What fields should MCAP delivery require?
At minimum, require topic schema, timestamp domain, compression settings, camera topic, state topic, and manifest, 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 MCAP robot data
Truelabel normalizes MCAP robot data across capture partners so you can ingest one consistent schema instead of writing per-vendor adapters.
Request MCAP data