In-House vs Outsourced Egocentric Data Collection

Running egocentric capture in-house means owning every stage end to end. That starts with hardware: a head-mounted camera, wrist cameras, a depth sensor, and IMUs, either assembled from components or bought as a lighter phone-mount or 360 head-mount setup. Each sensor needs a way to stay in sync with the others — software timestamping drifts over a session, so a credible rig needs a hardware trigger line and a shared clock domain, plus a calibration procedure to solve and verify intrinsics, extrinsics, and reprojection error.

Beyond hardware, an in-house program needs a contributor pipeline: recruiting participants, briefing them on the task, collecting and storing signed consent per item and per jurisdiction, and paying them. It needs an anonymization step for faces, license plates, and screens before footage moves downstream. And it needs a QA function that defines accept and reject criteria, checks every take against them, and recaptures or discards what fails, rather than shipping a caveat with the data.

None of this is unusual for a team already running robotics hardware programs. The question is whether standing up and maintaining all of it is worth it relative to the volume and duration of the need — see /custom-collection/pricing for how cost drivers like volume, task complexity, and annotation depth scale either path.

A custom collection engagement starts with a written spec: which tasks, objects, and environments the footage needs to cover, which capture tier fits (phone mount, 360 head mount, or the full instrumented rig), how deep the annotation needs to go, and the accept criteria a batch has to clear before it ships.

From there, the service runs the recruiting, hardware shipping, capture, annotation, anonymization, and QA as one managed pipeline, rather than the buyer coordinating a crowd platform, a labelling shop, and a QA tool separately. Most programs start with a Spec Pilot — a small, fast first batch that proves the spec and QA bar hold on real footage — before volume scales. See /custom-collection/as-a-service and /custom-collection/egocentric-data-collection-services for how the service is structured stage by stage.

Delivery ships in RLDS, LeRobot, WebDataset, HDF5, zarr, or Rerun .rrd, with per-stream PTP-domain timestamps and a calibration group carrying intrinsics, extrinsics, and reprojection error for the session, so sync and calibration can be verified independently rather than taken on trust.

Speed depends on what already exists. A team with a working rig, a trained QA process, and a contributor pool can move quickly on a familiar task. A team starting from nothing has to build the rig, establish sync and calibration, and recruit contributors before capturing a single usable episode — all before the first batch exists to evaluate. An outsourced engagement starts from an existing pipeline, so the first validated batch is produced against a written spec rather than against infrastructure still being built.

Quality risk in-house concentrates wherever the team has the least existing expertise — most often sync and calibration, since drift and reprojection error are easy to get wrong and hard to notice until a model trained on the data misbehaves. An outsourced engagement documents sync ceiling, calibration drift, and reject criteria per episode, so quality is machine-checked rather than assumed.

The risk profile is different, not simply smaller, for outsourcing: the buyer is trusting another team’s QA bar and consent chain rather than its own, which is why a written spec with explicit accept/reject criteria and a Spec Pilot exist — so the buyer validates the pipeline on a small batch before committing to volume.

In-house capture tends to fit when the need is continuous rather than one-off, when the task and environment are narrow enough that a small, fixed rig and contributor pool can be reused indefinitely, or when a team already has most of the pieces in place — a sync-capable rig, an established contributor relationship, or an existing QA process it wants to keep running.

It also fits teams that specifically want direct operational control over every stage, including the consent chain and anonymization pipeline, and are prepared to carry the cost of that control: calibration maintenance, contributor management overhead, and absorbing or discarding failed takes themselves rather than having them recaptured at a provider’s cost.

Outsourcing tends to fit when the task, environment, or population a model is missing is new each time — a different skill, a different region, a different demographic — so a standing in-house rig and contributor pool would sit idle between programs rather than being reused.

It also fits teams that need a specific, under-represented skill or environment that an off-the-shelf public dataset does not cover (see /compare/custom-vs-off-the-shelf-robotics-datasets for that comparison), need buyer-owned commercial rights to the result, or want to validate a spec on a small Spec Pilot batch before committing resources to either path. See /guides/how-to-buy-egocentric-video-data for how to evaluate a vendor once outsourcing is the direction.

In-house, the team is responsible for every part of the consent chain: drafting releases, collecting signatures per contributor and per jurisdiction, storing them, and building or licensing an anonymization pipeline for faces, plates, and screens before footage is used. The licensing terms a team can offer downstream customers or partners are whatever it negotiates with its own contributors.

In an outsourced engagement, consent artefacts and a data card are produced per batch as part of the service, anonymization runs before anything leaves QA, and the delivered data ships on a perpetual, buyer-owned commercial license — so the buyer’s rights to the data and any derived model are defined by the engagement’s license terms rather than built up contributor by contributor. See /guides/buyer-owned-training-data for what that license structure covers.

An outsourced engagement typically starts with a description of the gap — a task, environment, or population a model is missing ��� rather than a finished spec. That becomes a written spec with accept and reject criteria, scoped for reach, timeline, and price before capture begins.

Most programs then run a Spec Pilot: a small, fast first batch sized to prove the spec and QA bar hold on real footage, so stream quality, annotation fidelity, and format compatibility with the buyer’s own training pipeline can be checked before any commitment to volume. From there, the same pipeline scales to the program’s target size in scheduled batches.