Egocentric Pool and Spa Maintenance Data

Egocentric pool and spa maintenance data is first-person video of the physical work of keeping a hotel pool area in order, recorded against a written spec with the streams the site states for its custom collections. The catalog keeps this work in one row, Pool & Spa Area Maintenance, in the Hotel & Lodging environment.

The page covers that one row and nothing more. The site names no hotel, resort, region or pool, and it does not describe pool equipment, water treatment or safety practice, so those are left out rather than guessed.

One catalog row is counted: Pool & Spa Area Maintenance, in Hotel & Lodging under Hospitality & Events. The catalog rates it Easy, lists the capture mode as a head-mounted phone or a multiview rig, and gives the status Ready to deploy, which means contributors and site access are set up and capture starts once a spec is signed.

Rows that only look similar are not counted. Wiping, towel and cleaning work appear in other hotel rows, and a table below lists the nearest ones and why each stays out. The site has no separate row for a spa treatment room, a hot tub, a sauna or a pool deck.

The catalog line reads: skim and test the pool, arrange loungers, wipe surfaces and restock towels. That is five named activities in one row, and the table below sets each against what the site states and what it leaves open. The line is a description of the task, not a fixed script, so the order and the repeat count are set in the spec.

The word test is the least specific step. The site does not say what is tested, with what, or what the result is used for, and this page makes no water-chemistry, chemical-handling or dosing claim. If your policy needs the test step, the spec has to define it.

It is hotel work. The row sits in Hotel & Lodging, and the environment is described by examples such as guest room servicing, resort housekeeping, bed-making, linen changes, bathroom cleaning and amenity restocking. The pool row is catalogued alongside those, and this page uses hotel and commercial framing only.

Residential pool care is not claimed. The site states no row for a home pool or a private spa, and names no lifeguard, certification or safety-compliance practice for the row.

The site states no robot results for pool-area work, so this section describes what the task asks of a dataset, not what any policy achieves. One pass strings together several kinds of motion: a tool-led skim, a test step, moving larger objects such as loungers, repeated wiping of surfaces, and placing items such as towels.

Because those steps differ so much, the action segments carry a lot of the value: one long clip without step boundaries does not show where skimming ended and arranging began. The site states no cycle times or error rates for the row, so a spec names the steps, the passes and the accept criteria.

The catalog lists a head-mounted phone or a multiview rig for the row. The phone records the first-person view of real work on site, and a multiview rig adds synchronized third-person angles when the spec asks for them. The site lists no handheld grippers for this row, so the page does not describe capture that way.

On the rig tier, every stream is hardware-triggered onto one PTP clock domain, and the rig is calibrated twice per session, before capture starts and after it ends. An episode is accepted only if RMS reprojection stays under 0.28 px. Camera count, resolution and frame rate for pool-area work are Not stated, and so is any rule for capturing in wet areas, so those are settled against your spec before capture begins.

The Firsthand episode schema has ten streams synced under 2 ms: a 4K head camera, two wrist cameras, depth, IMU, 3D hand and body pose, instance segmentation and action labels. The site states 3D hand pose with per-joint visibility and frame-accurate action segments, and contact events mark when a hand meets an object.

For pool-area work, contact events can mark a hand on a skimmer handle, a lounger or a towel, and action segments can mark skim, test, arrange, wipe and restock. The site does not say which streams apply to this row, so the stream list is confirmed in the spec. Force or tactile data and success labels are Not stated for it.

Every contributor signs a written release before capture, and each delivered episode links to that record through consent artefact IDs in the batch data card. At ingest, automated detection finds faces, plates and screens and blurs them irreversibly. A human reviewer confirms that no un-consented person is identifiable in any frame, footage that cannot be de-identified is discarded, and the anonymization record is delivered with the data.

A hotel pool area can be a place where guests are present. The hospitality page states that front-of-house settings are bystander-dense, with lower yield after de-identification. The site states no rule written for pool areas beyond the blurring and review above, so how guest presence is handled on a shoot is settled in the spec.

Several hotel rows share a verb or an object with the pool row. Hotel Amenity Restocking also names towels, and Lobby & Common-Area Cleaning names dusting furniture. None of them names a pool, so none is counted here. The closest pages for the shared skills are linked below.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd. The format table below sets each against what its official documentation states. Action segments are the step labels, and any further object labels, such as lounger or towel, follow the spec.

Every batch is validated against signed accept criteria before it ships, with a reject log, and delivery is rolling, per validated batch. Billing is per validated hour, and rejected items are recaptured at our cost.

Where coverage is already deep, the first validated batch lands in a median of 48 hours from signed spec. Thin environments typically take three to four weeks, because vetting operators there is the bottleneck, and we quote that up front. The hospitality page lists hospitality coverage as thin, and the site does not say which timeline applies to the pool row.

The row is Ready to deploy, so capture starts once a spec is signed. The timeline is still quoted against your spec before capture begins, and on-demand top-ups run against the same accept criteria.