Wrist Camera Data Collection for Robot Learning

Wrist camera data collection means recording a task through cameras worn at the wrists, so the footage travels with each hand instead of staying fixed on the head or in the environment. On this site the wrist views are two cameras, left and right, captured alongside a head-mounted camera on the instrumented rig and delivered as the streams wrist_l and wrist_r.

This is the buying page for that data. The head-vs-wrist comparison explains what each viewpoint is for, the glossary defines the term, the multiview and head-mounted pages cover the wider rig, and the calibration guide covers the procedure. This page is for a team that already knows it needs wrist-view demonstrations and wants to specify, QA and buy them; the table below shows how the pages divide the topic.

One scope note matters for specifying: wrist views come from the instrumented rig tier. The lighter contributor-worn dual-lens 360 head-strap tier gives up depth, wrist views and sub-millisecond sync, and episode metadata labels which tier a clip came from.

A head-mounted camera gives the wide egocentric view: the environment, the target object and the approach. As a hand closes in on an object, though, the hand and arm frequently block the head camera’s view of the exact contact point. A wrist camera moves with the hand, so it stays close to the object through the final phase of a reach and grasp.

The wrist view also stays near the object during fine manipulation even when the head turns away. The trade-off is that it only covers what is near the hand and loses scene context. That is why the site pairs the two views, and why most manipulation policies need both.

If your robot carries a wrist camera, its observation includes a wrist-frame image, and demonstrations that carry a wrist-frame view in the same episode give that input a counterpart in the training data. That is a reasoning step, not a result: this site does not publish benchmark numbers, and neither does this page. Two wrist cameras are captured, one per hand, because most manipulation involves both.

The instrumented rig carries a head-mounted global-shutter camera, two wrist cameras, a forehead-mounted depth sensor and inertial measurement units on the head and on each wrist. Each wrist camera is worn on a velcro cuff with a rigid mounting plate. The rig is triggered from a PTP grandmaster clock and hardware trigger line in a belt pack, so every sensor runs off the same timebase.

The site states the global shutter for the head camera only; this page makes no shutter claim for the wrist cameras, and the only wrist-camera numbers here are the ones the episode schema itself shows, in the stream table below.

Depth comes from the forehead-mounted sensor; the multiview page describes a head-mounted stereo pair where precision requirements are high, with no baseline figure stated or claimed here. Inertial data is recorded at the head and each wrist as imu_head, imu_wrist_l and imu_wrist_r.

Capture runs through the same pipeline as every program: recruiting, capture against your written spec, per-batch QA, anonymization and licensed delivery. This page does not describe capture at a customer’s own facility.

Every sensor on the instrumented rig, wrist cameras included, is hardware-triggered off a single PTP clock domain, and each stream carries int64 nanosecond timestamps in that domain, so sync can be verified rather than taken on trust. The reject ceiling is 2.0 ms of residual sync error; delivered episodes measure a median of 1.12 ms and a p99 of 1.94 ms.

Every session is calibrated twice, before capture and after it ends. The solve uses a checkerboard target across 40 poses spanning every camera’s frustum, solves per-camera intrinsics to a reprojection error under 0.28 pixels, and solves the head↔wrist↔depth extrinsics against the shared target in the head-camera frame. The drift between the two solves is written into the episode metadata.

An episode is accepted only if RMS reprojection stays under 0.28 px and the drift is within tolerance; otherwise it goes to the reject log. A wrist frame is therefore related to the head frame in geometry as well as in time. The step-by-step procedure is in the calibration guide linked below.

The episode schema groups the data into streams, annotations and calibration. The table below maps the wrist-relevant fields to what each captures and where it sits in the delivery formats.

Each label answers a different question next to the wrist view. action_segments says what the performer was doing, as a start and end timestamp with a verb and noun. hand_joints gives where the hands are: two hands, 21 joints each, per frame, in metres in the head-camera frame. hand_visible says which joints were actually observed, so occluded joints are flagged instead of guessed. contact_events marks when fingers make and break contact with an object; it is listed as optional on the hand tracking page, so name it in the written spec if you want it.

Because hand joints are expressed in the head-camera frame, the same frame the extrinsics use, the wrist-camera transform and the hand pose can be related without a separate alignment step. The meta group carries episode_id and skill_id, so wrist-view episodes tie back to the named skill in the spec.

The site states what the rig captures: a left and a right wrist-mounted view, calibrated to the head camera. It does not state that the rig can reproduce a particular robot’s wrist-camera model, lens, mount position or field of view, and this page makes no such claim.

What the data does give a wrist-camera policy is the same kind of observation: a close, hand-frame view of the grasp, with the head view, depth and labels from the same moment. If a property of your robot’s camera matters, write it into the spec; the written spec and its accept criteria are where that is settled before capture begins.

Acceptance is measured against accept criteria written into the spec before capture begins. Episodes are machine-checked against reject criteria: a sync breach beyond the ceiling for more than three consecutive frames, calibration drift beyond tolerance, the manipulated object out of frame for more than 15 percent of the episode, more than 35 percent invalid depth pixels in the manipulation region, an undocumented bystander, or a mismatch against the named skill spec. The site does not tie these checks to the wrist cameras specifically, and neither does this page.

A human reviewer then checks each episode against the task spec. A reject log ships with every batch, rejected episodes are recaptured at the provider’s cost, and you are billed per validated hour. A Spec Pilot, a small and fast first batch, lets you check the wrist footage, labels and QA bar on real episodes before you scale.

Every contributor and operator signs a documented consent release, and each episode links to that release through a documented consent chain. Faces, license plates and screens that appear in frame are detected and irreversibly blurred at ingest, and a human reviewer confirms the result before anything ships. The anonymization record is included with delivery.

Every custom collection ships under a perpetual, buyer-owned commercial license. Exclusivity is available so the data is never resold to another buyer. The site does not make certification claims for this data, and this page makes none.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd for full-fidelity review. The episode schema is the canonical layout and every format is a projection of it, so the wrist streams are part of what your loader reads.

Where the site names the wrist fields: in the LeRobot v2.1 layout the features are observation.images.head and observation.images.wrist_l/r, one mp4 per camera, with per-frame timestamps aligned to the head-camera clock. In WebDataset each sample carries __key__, head.jpg, wrist_l.jpg, wrist_r.jpg, depth.png and ann.json. In the episode schema the wrist views are streams/wrist_l/r. Delivery uses metric units: depth in millimetres and hand joints in metres.

Describe the skill, the objects and the settings your policy needs wrist views for, and which labels are in scope. We turn that into a written spec covering tasks, environments, capture tier (the instrumented rig, since that is where wrist views come from), annotation depth and accept criteria, then quote reach, timeline and price against it before capture begins. Pricing details are on the pricing page.

Where coverage is deep, the first validated batch lands in a median of 48 hours from signed spec. Thin environments typically take three to four weeks, and we quote that timeline up front. On-demand top-ups run against the same spec and accept criteria, so new wrist-view data stays consistent with what you already hold.