Delivery format
RLDS format for robot training data
RLDS is useful for reinforcement learning and robotics episodes with observations, actions, rewards, and metadata. Define episode ID, observation stream, action stream, timestamps, task label, and success flag before reviewing samples so you can verify that delivery matches the training pipeline.
Quick facts
- Origin
- Google Research — RLDS spec at github.com/google-research/rlds, used as the canonical episode container in Open X-Embodiment.
- Open X-Embodiment
- 1M+ trajectories from 22 robot embodiments and 21 institutions ship in RLDS (October 2023).
- RT-X / OpenVLA
- Both train on RLDS-formatted data; RLDS preserves the (observation, action, reward, discount, metadata) tuple needed for policy learning.
- Required fields
- Episode ID, observation stream, action stream, timestamps, task label, and success flag.
Comparison
| Format choice | Strength | Risk |
|---|---|---|
| RLDS | reinforcement learning and robotics episodes with observations, actions, rewards, and metadata | 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 RLDS?
RLDS should be requested when the buyer's training or evaluation pipeline already expects reinforcement learning and robotics episodes with observations, actions, rewards, and metadata. 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]"RLDS is an ecosystem of tools to store, retrieve and manipulate episodic data in the context of Sequential Decision Making including Reinforcement Learning, Learning from Demonstrations, Offline RL or Imitation Learning."
For truelabel buyers, that quote matters because it turns RLDS format from a generic delivery preference into a source-backed requirement the supplier can test against a sample file.
Using RLDS with robot data
A useful RLDS sample should prove episode ID, observation stream, action stream, timestamps, task label, and success flag, 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
- RLDS: Reinforcement Learning Datasets
RLDS stores episodic reinforcement-learning and robot learning data.
GitHub ↩ - RLDS with TensorFlow Datasets
TensorFlow Datasets documents RLDS support for episode datasets.
TensorFlow ↩ - Open X-Embodiment: Robotic Learning Datasets and RT-X Models
Open X-Embodiment is a robotics dataset and model reference relevant to RLDS delivery.
arXiv ↩ - TF-Agents Trajectory API
Trajectory structures connect observations, actions, rewards, and step types.
TensorFlow ↩ - LeRobot documentation
LeRobot documentation is relevant when converting robotics datasets into training-ready formats.
Hugging Face ↩ - HDF5 1.14 documentation
HDF5 is a structured data container often compared with RLDS episode storage.
The HDF Group ↩
FAQ
What is RLDS used for?
RLDS is used for reinforcement learning and robotics episodes with observations, actions, rewards, and metadata.
What fields should RLDS delivery require?
At minimum, require episode ID, observation stream, action stream, timestamps, task label, and success flag, 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 RLDS format
Truelabel normalizes RLDS format across capture partners so you can ingest one consistent schema instead of writing per-vendor adapters.
Request RLDS data