Small Custom Egocentric Datasets: Fast, Small-Batch Collection

A small custom egocentric dataset is a first-person batch captured to a written spec and sized by that spec rather than by a package. Typical shapes are a first batch for a new skill, a narrow skill such as one condition or one missing region in an existing training set, or a pilot-sized order placed before a larger commitment. Each episode is recorded from a contributor’s own point of view, with the streams and labels the spec calls for.

What makes it “small” is scope, not quality. The site describes one pipeline used across every program — contributor and operator recruiting, capture against the spec, per-batch QA with reject reasons, anonymization, and licensed delivery — and a small order runs through it rather than through a lighter-weight shortcut. The batch is smaller; the reporting, the license and the consent chain are the same as for a larger collection.

A small batch fits when the question is narrow or the spec is unproven. A team missing a single condition or a single region does not need a standing program to fill it; the site describes a focused brief of that kind as a normal starting point for on-demand collection. A team writing its first spec for a new skill gains more from a small batch of real footage than from a longer written plan, because footage shows whether task definitions, labels and scenes behave as intended.

A larger collection makes more sense once the spec has been proven and the gap is broad: many tasks, many environments, or a corpus that has to be diverse across regions. A practical test is whether a mistake in the spec would be cheap or expensive to repeat at volume. If it would be expensive, start small, so the correction is made once on the small batch instead of being repeated across a much larger order.

The site publishes two timelines and no others. Where coverage is already deep for the task and environment mix requested, the median time from a signed spec to a first validated batch is 48 hours, with a spec conversation the same week. Where coverage is thin — the site names construction, clinical, agriculture and hospitality — turnaround typically runs three to four weeks, because vetting operators in those environments is the bottleneck.

Two cautions apply. A median is not a guarantee for any single order, and the site does not promise anything faster than these numbers. The site also ties the two timelines to coverage depth rather than to batch size, so a small batch in a thin environment should be planned on the longer range. Speed comes from a warm pipeline, not from cutting consent, review or anonymization.

No standing program is required: the site states that no minimum program size is needed before ordering, and that a focused written spec and a small Spec Pilot batch are a normal starting point. It does not publish a minimum order size, a minimum number of hours, a minimum batch size or a discount, and this page does not invent one. Volume is defined by the spec rather than sold as a fixed package, so for each of those parameters the honest answer is: not stated — scoped per order.

Pricing follows the same logic. Billing is per validated hour, or per accepted item, quoted against the spec before any capture, with no list price. Cost is driven by streams, labels, reach and turnaround. Takes that fail the accept criteria are rejected and recaptured at the provider’s cost rather than billed to you, so a small order pays only for hours that clear review.

A small batch is only as good as the spec behind it. The site describes the same written spec for every order: the tasks to demonstrate, the scenes and objects involved, the contributors, the streams to capture, the labels the pipeline needs, the accept criteria, the delivery format and the timeline. A skill spec, as the site defines it, is the written contract for the program — the named skill, the environments and conditions to cover, the acceptance criteria and the target hours, agreed before a contributor is briefed.

For a small order, the discipline is to keep each field narrow and checkable. Name one skill or one condition, define what counts as a successful episode, and state the accept criteria in terms a reviewer can apply to every episode. Because a small batch is small enough to review episode by episode, vague accept criteria surface quickly. Where a target volume is needed, write it down as a number you choose; the site does not set one for you.

Streams are chosen in the spec, not fixed by order size. RGB video is the baseline, from head-mounted and wrist views; depth, IMU and hand pose are added where the spec calls for them. Each active stream carries hardware-triggered timestamps on a shared clock. The labels the site describes are hand pose and action segments, frame-accurate and tied to the observation at each step, where ordered.

Delivery formats are the same as for any custom order: RLDS, LeRobot, WebDataset, HDF5, zarr, Rerun .rrd, or raw streams with metadata. Anything not in the spec is not part of the batch. This page makes no claim about streams or labels the site does not describe; if your skill needs something beyond the list above, raise it when the spec is written so it can be confirmed rather than assumed.

A small order is not a lower-bar sample. Episodes pass through calibration and synchronization checks on every active stream, plus label and annotation review for hand pose and action segments where those are included. Episodes that fail are rejected rather than delivered with a caveat, and the decisions are recorded in a reject log that ships with the batch, alongside a coverage report against the spec.

Consent and anonymization are part of the pipeline at every size. Every contributor signs a consent release before capture, and that record travels with the episode through delivery; bystander faces, plates and screens are anonymized before delivery. The data ships under a perpetual, buyer-owned license that is non-exclusive by default, so a small batch carries the same ownership terms as a large one.

Three nearby offers answer different questions. A free sample pack shows existing footage captured for a different purpose, so a buyer can inspect schemas, labels and license terms before writing a spec. A Spec Pilot is captured fresh against the buyer’s own spec to prove the spec and accept criteria before committing to full volume. A quote scopes a written spec into reach, stream count, validated-hour volume and turnaround. The page for robotics startups covers the buyer type rather than the batch size.

A small custom batch overlaps with a pilot in size but not always in purpose. A pilot is a proof step on the way to volume; a small batch can be the whole order, such as closing one gap in an existing training set. An order can also be both: a small first batch that proves the spec and, once accepted, becomes the baseline for a larger run.

Scaling does not restart the process. Once a small batch is accepted, the same written spec — corrected for anything the batch surfaced — extends into a larger order, and the streams, labels and format already proven carry forward. Top-ups also run against the original spec and accept criteria, so new data is consistent with what you already hold and slots into the same schema.

The site does not state a cadence, a minimum term or a volume per batch for an ongoing program, so those are agreed in the engagement rather than assumed. What it does state is the direction of travel: small and fast first, then scale on a spec that has already been run against real footage.

Write a short spec with the tasks, scenes, contributors, streams, labels, accept criteria, delivery format and timeline you need, plus the volume you have in mind if you have one, then request a quote against it. The quote is scoped to your spec, covers reach, stream count, validated-hour volume and turnaround, and is not a catalog price.

If you would rather inspect data before writing a spec, start with the free sample pack. If you already know the skill, send the brief and say that you want a small, fast first batch; the median 48-hour timeline applies where coverage is deep for your tasks, and the three-to-four-week range applies where it is thin.