LeRobot v3 dataset uploader: finalized artifacts, spools and receipts
A LeRobot v3 dataset uploader belongs after recording has produced stable artifacts. The V-Modal robotics SDK moves those artifacts through a durable local spool and a transport boundary. It does not control robots. This guide follows v0.2.2, explains its command-line status workflow and separates local upload reliability from downstream cloud publication and search qualification.
Updated:
Install the LeRobot v3 dataset uploader from its subdirectory
The installable Python package lives under lerobot in the robotics repository and is named vmodal-robotics. Use the v0.2.2 source tag and the subdirectory selector when installing the lean core. The root README’s sample still names an earlier tag, so the setup below explicitly pins the release reviewed for this guide. The cloud transport is an optional addition described in that same repository.
Start on a machine with persistent storage for the spool and a recorder that can publish finalized artifacts. Do not place the spool in an ephemeral working directory by accident. Keep the source dataset producer-owned and decide which transport will receive the admitted data. Installing the uploader alone does not establish a validated search pipeline or a qualified reader for every dataset variant.
python3 -m pip install "vmodal-robotics @ git+https://github.com/v-modal/[email protected]#subdirectory=lerobot"Reference: v0.2.2 README.md installation pattern, pinned to the reviewed v0.2.2 tag
Admit finalized artifacts without coupling robot control
The release describes a producer that closes and hashes files, then atomically publishes a ready manifest. Admission validates the artifact contract and creates an immutable copy in the spool. Keep that handoff outside the motion or safety loop. A camera recording must become stable before it is handed to an asynchronous uploader; a changing file cannot be treated as a completed dataset artifact.
This boundary lets the recorder remain responsible for capture and dataset organization while the uploader handles transfer state. Before a pilot, document who writes each artifact, how completion is declared and how source paths map to the dataset. Test rejection of an unfinished file. An explicit producer contract is more useful than assuming the SDK can discover every partially recorded experiment automatically.
Read spool status and distinguish local progress from receipts
The published command is vmodal-robot status, with a spool_dir argument. It reports operational information such as queued work, retries and receipt state. Point every operational command at the same persistent spool used by the running uploader. Otherwise an apparently empty queue may simply be a different directory rather than evidence that the intended recordings were delivered.
Durable local admission, successful transfer and a remote receipt represent different milestones. The README describes reconciliation when a response is lost, so a restart should be evaluated against durable state rather than guessed from the last terminal line. Observe status before and after an interrupted transfer. Keep receipts with the dataset context needed to explain which immutable bytes were accepted by the destination.
vmodal-robot status --spool_dir=/var/lib/vmodal-robotReference: v0.2.2 README.md operational CLI; lerobot/src/vmodal_robot/cli.py status
Hand off ROS 2 recordings at a stable bag boundary
For a ROS 2 pipeline, use the release’s bag handoff and manifest-node documentation rather than treating a live bag as an ordinary closed video. The capture process must define which files and metadata make up a finished artifact set. Preserve source timing and recording identity so later analysis can relate a retrieved camera moment to the correct robot experiment.
The uploader’s transfer contract and ROS capture responsibilities remain distinct. A successful byte delivery does not prove that every topic, clock mapping or downstream reader has been qualified. Start with one representative recording, inspect the admitted artifact set and verify the receiving side. Expand only after restart behavior and data interpretation have both been checked for that recording format.
Search uploaded footage through a separately verified path
The repository distinguishes the shipped offline workflow from live cloud publication, search visibility and pinned LeRobot reader qualification. Treat those as explicit acceptance gates for your deployment. Once the applicable footage has reached its intended destination and indexing is ready, use a supported search client to query that collection. The uploader itself should not be presented as a generic interactive video-search client.
Keep a mapping from a returned source moment back to its dataset and recording. For an experiment review, a relevant image without that provenance is difficult to use. Check a known action in a small recording, retrieve its frame and compare its timestamp with the producer’s timeline. Record any conversion step between native robotics timing and the media representation used by the search service.
Intrinsic is a design; choose a concrete pilot boundary
The Google Intrinsic connector is an integration design, not a working connector in this release. Its architecture material can help a team discuss capture, robot state, transforms and asynchronous export, but it should not be mistaken for an installed integration. Evaluate the implemented uploader and the specific producer adapter you actually have, with separate work identified for any proposed connector.
A practical pilot records finalized input, admission, queue state, remote receipts and downstream visibility as distinct checkpoints. Interrupt the network and restart the uploader, then verify the same source artifact can still be accounted for. Keep robot behavior outside that test’s dependency chain. Bring the dataset format, transport choice, source tag and last completed checkpoint to the integration discussion.