teleop dataprep

Each selected standardized dataset becomes its own LeRobot dataset, converted in parallel — tick combine to concatenate them all into one instead. Nothing is ever overwritten or deleted — a name that already holds a completed dataset is refused, and refuses only that one job. The name must say its resolution, so that two preps of the same recordings can be told apart. Publishes to datasets_lerobot/<name>.

Publishes a smaller-resolution copy: only the video is re-encoded, and the low-dim data, the tasks and any applied labels are the source's, copied verbatim. Both sides scale by the same factor — nothing is cropped, so the framing is the one the conversion chose. Runs on Vertex like a conversion, but reads the published dataset instead of the recordings.

Labels are applied in place: only the low-dim parquets are rewritten (no video is touched), here on this VM rather than on Vertex. A run replaces whatever labels the dataset already carried — episodes this delivery does not cover are cleared — so it never ends up holding two partners at once. Name a copy below to keep the original as it is instead.

This dataset records a peripheral channel (air blower, …) outside its action vector, so a policy trained on it cannot command the peripheral. Folding appends peripheral_observation to both action and observation.state, here on this VM rather than on Vertex.

This rewrites the published dataset in place — the one dataprep job that does, so the name and the training data stay in step instead of forking into two. videos/ is never opened; only the low-dim parquet and metadata are rewritten. Re-running repairs an interrupted fold rather than double-appending, because every file is checked before it is touched.

The spec is a committed YAML per task (partner_scripts/clean_specs/), judged against the labels already applied to this dataset: an episode that never went through the task's stages, or is marked failed, is dropped whole, and stretches a rule rejects are cut out of the ones that stay. A cut in the middle of an episode leaves two episodes — the arm teleports across a cut, so the ends are not spliced.

The parent is never touched. No video is re-encoded either: an episode owns a window into an mp4 it shares with its neighbours, so this runs here on this VM, not on Vertex. A video file no surviving episode points into is left behind rather than copied.

The rules below start as the spec says and apply to this job only. Blank turns a rule off. The committed YAML changes only if you tick save as the spec's default, which rewrites it from these values and drops its comments — the file is the reviewable statement of the task's policy, so that edit still wants committing.

A standing rule, run once a day: it asks what matches the pattern and qualifies now, and queues the ordinary jobs for those. Nothing is chained — each rule's precondition is another's product, so a conversion tonight becomes a labelling once the partner delivers, and a delivery once it is labelled. Jobs run under the header's build from ref and machine pick, like every other form on this page.

A release is a named, immutable set of LeRobot datasets — what a training run was made of, answerable months later. Only base preps are offered: the dataset each family was converted to, usually the 448. A downscale, a clean or a SARM conversion is a view of a release rather than a member of one, so those are built from the release below instead of picked here. Every member must have been prepared the same way, or no view of the release could be uniform — a mixed selection is refused, naming the odd ones out. Adding or removing a dataset means cutting a new release; that costs a few KB.

A view is the release’s data prepared a particular way. The recipe is a list of steps applied to the base — downscale, clean, sarm-convert. Recipes are shared across releases, and the catalogue defines them for every release. Disabling builds keeps existing outputs available. Training runs retain their resolved dataset names.

The name is also the output name: it is appended to each member’s, replacing the member’s resolution token when the view starts with one. So 224-clean-sarm-dinov3 of …-orin-robot-2-448 publishes …-orin-robot-2-224-clean-sarm-dinov3. That is what keeps two views ending in the same step apart — name them differently and they are separate datasets. The intermediate steps keep their conventional names, so one …-224 is built once and shared by every view that passes through it.

Pi trains on the saved filters selected above. Each filter fixes an episode set, even if the release has changed since it was created.

Generated from the base config. Every knob below is openpi's own, with openpi's default; blank takes the base config's value. reset to defaults

A SARM conversion is a view of a release now, not something launched from here. Define a view whose last step is sarm-convert on the releases tab and press build: it converts each member the view is missing, skipping the ones it already holds. A conversion launched by hand would publish a dataset no release accounts for, which is what releases exist to prevent.

The frames are sampled and embedded at conversion time, so no GPU pass is needed at train time. Only the DINO embeddings are published — the raw frame h5 is 6.4× their size and only a train_images config reads it.

A trained checkpoint scored against the data it was trained from, so the stretches where the two disagree can be found and judged. Most of them never reach a person: this task counts, and the rig’s own pick_count_abs settles which side is wrong. What a reviewer condemns becomes an annotation.mistakes tag the clean tab already drops. Open the review queue → · Compare labels against the model →

Auto-label a split. Scores the checkpoint over every episode of a view and publishes a scan — both decodes of every frame beside the human labels, never over them. Two passes: the rolling-window one every eval number is computed under, and the causal one a rig actually runs, so a stretch the model *knows* and the decode loses is distinguishable from one it never knew. Runs on L4s and shards across them; an eval split is minutes, a training split is roughly nine times that.

Writes two per-frame columns — progress and stage — onto a release view's LeRobot datasets, which is the form openpi's advantage conditioning reads. The stages are the annotations', not the model's: they come from annotation.label and are passed in as the model's conditioning, so a view whose datasets carry no partner labels is refused. One L4 job per dataset.

Runs on H100s, on a release and one of its SARM views. The view's datasets are combined before training and must share a task name — a run trains one stage taxonomy. Checkpoints land in sarm_models/<experiment>; an experiment name that already holds objects is refused, so a run never writes into another run’s checkpoints.