Robot data, aligned to one clock
Trajectories, teleoperation sessions and multi-sensor recordings for policies that learn from demonstration: streams aligned in time, calibration kept with every episode, recordings segmented into episodes, and action spaces normalised across robots.
Part of Runix Data. This page sets out the rules we apply in this domain and the public standards they follow.
containers ROS 2 bags and MCAP, read losslessly robot URDF kept with the episode time one clock; drift and drops reported episodes start, end, outcome, instruction actions units, frames and rates normalised delivery RLDS or LeRobot format
A reference card. Each line names a public standard or convention; the rules below say how it is applied.
02 · Covers
The data this covers
Cleaned and structured from what you provide or have the rights to use, or built to a specification agreed in writing.
Teleoperation demonstrations
Episodes recorded by an operator driving the robot, with the instruction that was given.
Autonomous rollouts
Episodes the policy ran itself, successes and failures both, labelled as such.
Multi-sensor recordings
Cameras, depth, joint states and force-torque readings from the same run.
Language-annotated episodes
Episodes paired with the task description, for policies that take instructions.
03 · Rules
The rules, and where they come from
Each rule follows a public standard or an established practice in the field, named with it, so you can check the reasoning rather than take ours on trust.
One clock
Cameras, joint states and force readings are timestamped by different devices. Streams are aligned to one clock, and drift and dropped frames are reported rather than silently interpolated over.
Follows Timestamped message containers such as ROS 2 bags and MCAP.
Calibration travels with the data
Camera intrinsics and extrinsics and the robot's description are stored with each episode, not in a separate file that gets lost.
Follows URDF robot descriptions; the per-episode metadata in open robot datasets.
Episodes, not hours of tape
Long recordings are split into episodes with a start, an end, the outcome and the instruction that was given.
Follows The episode structure of RLDS and LeRobot datasets.
Failures labelled, unsafe removed
Failed attempts are kept and labelled, because a policy learns from them too. Unsafe or corrupted episodes are removed, with the reason recorded.
Follows Open datasets that release labelled failures, such as DROID's episodes marked not successful.
Actions comparable across robots
Units, coordinate frames and control rates are normalised, so data from different robots and controllers can be trained on together.
Follows The gap Open X-Embodiment documented: its cross-robot data shares a 7-DoF end-effector action normalised per dataset, but leaves coordinate frames unaligned.
04 · References
Public references
The standards and open sources these rules are built on. They are other organisations' work, linked so you can read them yourself.
- MCAPAn open container format for timestamped robotics data.
- rosbag2The ROS 2 recording tool; its default storage format has been MCAP since ROS 2 Iron.
- URDFThe XML format that describes a robot's links and joints.
- RLDSGoogle Research's episode-based format for robot and reinforcement-learning data.
- Open X-EmbodimentA collaboration pooling robot data across many embodiments.
- LeRobotHugging Face's open library and dataset format for robot learning.
05 · Delivery
What every delivery carries
The same in every domain; the Runix Data page has the full list.
Provenance and licence, per record
Where each record came from, what was done to it, and the licence or permission it was used under.
A quality report
Coverage, duplication and the checks each record passed, plus what was dropped and why.
Evaluation kept apart
Evaluation data split from training data by source, so a score is not inflated by near-duplicates.
06 · Questions
Common questions
Which robots and formats do you work with?
We read ROS 2 bags and MCAP directly; other logging formats are assessed on a sample. Delivery is in the format your training code expects, such as RLDS or LeRobot.
Why keep failed episodes?
A policy learns from them too, as long as they are labelled. Unsafe or corrupted episodes are the ones removed, with the reason recorded.
Do you sell ready-made Embodied AI datasets?
Not off the shelf. Runix Data builds to a specification agreed in writing: from data you provide or have the rights to use, or from public sources whose licences permit your use. The rules on this page apply either way.
What happens to the data we send?
It is processed only to do the work you asked for. It is not used to train models, ours or anyone else's, and it is not sold.
Send us a sample of your robot data
A slice of the real data and what the model has to do with it. We reply within one business day, and the scoped plan that follows includes the parts we think are not worth doing.
Request early access