Egocentric Video Data for Hospitality and Housekeeping Robots

Egocentric hospitality data is first-person video of hospitality tasks — guest-facing work such as reception and front-desk interactions, and back-of-house work such as cleaning and housekeeping — captured from the worker’s own point of view rather than a fixed security-style camera. The site tracks “cleaning & housekeeping” as one of its broader activity categories across all captured environments, and separately tracks hospitality as one of its named capture settings.

A hospitality dataset built on this site combines those: the task structure of cleaning and service work, captured specifically in hospitality environments rather than homes or warehouses. The underlying capture, labeling, QA, and licensing process is the same one used across every custom collection on this site.

Custom capture fits best when a task is well-defined enough to write into a spec — a bounded interaction or a bounded physical task, not an entire shift. Guest-facing examples include a single reception or check-in interaction and a single concierge or guest-service exchange. Back-of-house examples include a single cleaning pass or a single room-turnover task, in line with the “cleaning & housekeeping” activity category already tracked across the site’s broader capture mix.

The common requirement is the same one that applies everywhere on this site: a clear start, a clear end, and accept criteria a reviewer can check footage against.

A buyer or their robotics team writes a spec that names the task, the environment, and the accept criteria before any capture starts. For hospitality work, the spec has to say explicitly whether the setting is guest-facing (front-of-house) or back-of-house, because the site treats front-of-house capture as bystander-dense with lower post-de-identification yield.

The spec also states what counts as a completed interaction or a completed cleaning pass, so a reviewer can check every captured item against the same written bar rather than a subjective one. Many programs start with a Spec Pilot, a small, fast first batch that proves the spec and accept criteria before scaling to full volume.

Capture uses synchronized, hardware-aligned streams worn by a consenting operator, the same rig approach used across every environment on this site. In hospitality settings the operator is the one wearing the capture hardware and giving consent; anyone else who appears in frame — guests, co-workers, bystanders — is handled under the site’s bystander and de-identification process rather than being treated as a second consenting participant.

That bystander handling is also the reason front-of-house yield runs lower than in private, less populated environments.

Once footage is captured, it is broken into action segments and episodes against the spec’s step definitions, with hand pose tracked through the task and failure or recovery cases captured and labeled where they occur, consistent with how action-labeled egocentric video is structured across the rest of the site.

For a guest-service interaction that means segmenting the greeting, the service action, and the close; for a cleaning or room-turnover task it means segmenting the discrete sub-steps of that pass.

Capture follows a documented consent chain for the operator wearing the rig. Anyone else who appears in frame is handled through the site’s bystander and de-identification process rather than being captured as a named participant, which is exactly why the site flags front-of-house hospitality settings as bystander-dense with lower yield after de-identification — more footage has to be reviewed and adjusted to remove or obscure bystanders before it is usable.

Faces and screens are detected and blurred at ingest, with a reviewer confirming the result before delivery. Any clip that cannot be reliably de-identified is discarded rather than shipped with a caveat.

The buyer. Delivered data is licensed on a perpetual, buyer-owned commercial basis by default, with exclusivity available, backed by the same documented consent chain used across every environment on the site.

Delivery is billed and licensed against the accept criteria named in the written spec, with rejected items recaptured at no cost to the buyer before anything ships. Pricing is quoted per spec rather than published as a flat rate; see the pricing page for how a quote is built.

Delivered data uses the same formats the site documents elsewhere, including RLDS, LeRobot, and WebDataset, plus HDF5, zarr, and Rerun .rrd, or raw streams with metadata if your pipeline needs the unprocessed form, so a hospitality dataset slots into the same training pipeline as any other environment on this site without a custom ingestion step.

Describe the guest-facing or back-of-house task, the environment, and the accept criteria your training pipeline needs. That becomes a written spec covering the task, setting, capture tier, annotation depth, and accept criteria, quoted for reach, timeline, and price before capture begins.

Start with a Spec Pilot — a small batch captured against a draft spec so both sides can confirm the task definition and bystander handling work before scaling up. Because hospitality is one of the site’s thinner-coverage environments, a first validated batch typically takes three to four weeks rather than the faster median available in deeper-coverage settings, since vetting operators with the right access is the bottleneck rather than demand for the task.