Egocentric Hotel Room Turnover Data

Egocentric hotel room turnover data is first-person video of one person resetting a guest room, recorded from that person’s own point of view while they work. A paid, consented contributor wears the capture rig and performs the task written in a skill spec, and each attempt is delivered as an episode with synchronized streams, hand pose and labeled action segments. It is human capture. It is not robot or teleoperation data, and it is not a fixed corpus you download.

The site states the task in one row of its commercial task catalog. In the Hotel & Lodging environment, the row "Room Turnover & Inspection" reads: "Reset the room after checkout, check every item against the standard and report faults." It is a medium-skill row, captured with a head-mounted phone or a multiview rig, and listed as ready to deploy. The environment itself is described with examples of hotel guest room servicing, resort housekeeping, bed-making, linen changes, bathroom cleaning and amenity restocking. This page is built on that row and on the neighbouring hotel rows quoted below, and on nothing else the site says about hotels.

Neighbouring pages cover different subjects. Egocentric hospitality and housekeeping data spans guest-facing and back-of-house work broadly, egocentric bed making data centres on the bed itself, and egocentric bathroom cleaning data centres on the bathroom. The subject here is the room reset as one task family, which the site’s "Hospitality Housekeeping" row already describes as stripping and making beds, cleaning bathrooms, dusting, vacuuming and restocking in one pass.

People reach this topic through hotel housekeeping robot training data, a room turnover video dataset, egocentric hospitality cleaning data, or custom hospitality task data collection. They describe one request from different angles. The work is the same: write the task down, collect it on demand, and receive validated episodes.

The first table below reproduces eleven rows of the site’s commercial task catalog: eight from the Hotel & Lodging environment and three from the Hospitality Service Set. The lead row is "Room Turnover & Inspection". Around it sit the rows that make up a turnover when they are done in one pass: "Hospitality Housekeeping"; the bed rows "Hotel Bed Making", "Linen changes" and "Strip and remake guest beds using fresh linens and mattress protectors"; a bathroom row; "Hotel Amenity Restocking"; and a row that vacuums and dusts a guest room. All eight hotel rows are listed as ready to deploy, and the turnover row is the only medium one among them. The three service set rows, two medium and one easy, use a multiview rig with handheld grippers and are available on request.

The turnover row names three actions: reset the room after checkout, check every item against the standard, and report faults. The site does not define the standard, does not list the items, and does not say how a fault is reported, whether spoken, written or entered on a device. Whether reporting a fault is inside the episode or outside it is a spec decision, and so is how much of the reset a single episode includes.

One row names a cart. "Hotel Amenity Restocking" restocks toiletries, towels, coffee and minibar items "from the housekeeping cart", and the hospitality service set is described as a table, a counter or bar, and a housekeeping or room area. That is all the site says about carts. It does not describe what a cart holds, how it is laid out, or whether any room-attendant routine beyond these rows is captured, so this page claims none.

Some neighbouring hotel rows are left out on purpose. Laundry rows such as sorting soiled linens, ironing and folding are back-of-house laundry rather than the room itself. The luggage row is a guest-facing task. Bathroom rows that involve cleaning chemicals sit on the bathroom page. The same hotel environment lists them all, and the environment page shows the full set.

Each attempt is delivered as one episode, and a turnover needs a decision up front about what one attempt is: the whole reset from the room after checkout to the last item checked, or one zone of it, such as the bed, the bathroom, the surfaces, the floor or the restock. The site does not set that length, the size of the room or the number of episodes, so the skill spec does. Inside the episode, the synchronized streams run from start to end, and action segments divide it into labeled spans.

A whole-room episode might open on the room as the contributor finds it and close when the last item has been checked, following the order of the catalog wording: reset, check, report. That is an illustration of how a spec can cut an episode, not a stated duration. A zone-level episode is shorter and easier to check against a single accept criterion. Many programs mix the two, with zone-level episodes for the steps a model is weakest at and whole-room episodes for the order of the work.

The choice matters because of one machine-checked rule. An episode is rejected if the manipulated object is out of frame for more than 15 percent of it. In a room reset the manipulated object changes from a sheet to a towel to a vacuum to a cloth, and the contributor turns between zones, so the spec should say what counts as the manipulated object at each step. The settings behind these rows are the Hotel & Lodging environment and the hospitality service set. Which applies to your program, and how many room setups or step variations you want, are set in the spec.

Inside each episode, action segments divide the recording into start- and end-timestamped spans, each carrying start_ns, end_ns, verb and noun. For this task family a segment can be one step as written in the skill spec, so a turnover becomes a run of labeled steps such as strip, make, wipe, vacuum, restock and check rather than one long clip. The other standard fields are hand_joints and hand_visible for 3D hand pose, contact_events for the moment the hand meets an object, objects, and instance_masks, stored at the depth resolution of 848×480 so they line up with the depth stream.

Hand pose is delivered for both hands with a per-joint visibility flag for occluded fingers. That is the label that carries how the hands grip, lift, spread and wipe, and it is the main signal for the manipulation inside a turnover. The site describes contact events as the moment the hand meets an item, and it does not say which items count in a hotel room, so the spec is the place to settle what a contact event means for your task.

The site lists no label for the outcome of the turnover. There is no stated inspection result, fault label, checklist item, room-state label or task-completion score, and no contact force reading. The catalog verbs "check every item" and "report faults" describe what the contributor does, not a delivered measurement. Camera pose, a head trajectory and a map of the room are likewise not among the listed deliverables. The site states 6-DoF IMU data at 200 Hz from head- and wrist-mounted sensors, and nothing more about motion.

Delivery is in the format your stack already reads: RLDS, LeRobot, WebDataset, HDF5, zarr or Rerun .rrd, or raw streams with metadata. Readable converter source ships alongside the data so the schema can be retargeted to your own loader. The official documentation for three of these formats is linked in the sources below. Collections are billed per validated hour, and the license is perpetual, irrevocable and worldwide, buyer-owned and non-exclusive by default, with exclusivity available as a separate term.

A published robot foundation model paper, GR00T N1, linked in the sources below, describes a data pyramid with web data and human video at the base, synthetic data in the middle and real robot trajectories at the top. First-person human video of a room being reset sits in that base layer. Human capture does not replace robot data, and this page does not claim that it does. The glossary entry on the data pyramid explains how the layers trade volume for embodiment closeness.

A room reset is a useful shape of task because it is long and made of parts. The catalog strings together bed making, which the household chores dataset page lists as "Bed-making, bimanual sheet handling", bathroom wiping, dusting, vacuuming and restocking, then adds a check against a standard. That is the structure household robots and service robots share: several sub-tasks in sequence, two-handed work on soft items such as linen and towels, and the need to know when one step is finished and the next begins. A clip that shows a room somewhere in frame does not carry what a policy needs. The hands, the items and the step boundaries have to be in the episode.

A custom collection lets you aim at the step your model is missing. If your pipeline already handles bed making and fails at the check, or fails at the order of the work, the spec can name that. This page does not claim that any public corpus lacks room turnover data, and it does not claim a training outcome or a model improvement from any dataset.

The tradeoff to plan for is the embodiment gap between a human pair of hands resetting a room and a robot platform doing the same, which retargeting or pairing with robot data has to close. Counts of contributors, hours and tasks are set in your skill spec.

The site describes the two capture setups in the catalog. For the hotel rows, a head-mounted 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. For the service set rows, the setup is a staged working set recorded by a multiview rig while the operator performs the task with handheld grippers, so demonstrations map onto a robot end effector. "Ready to deploy" means that contributors and site access are set up, and capture starts once a spec is signed.

The site names no property, brand, city, room count or room type, and it lists capture at your own facility as not offered. This page therefore makes no claim that episodes are recorded in a particular hotel, and none that they are recorded at yours. Capture is run to your skill spec using the settings and contributors Firsthand arranges. The hospitality page classes room-turnover work as back-of-house, and it states that front-of-house settings are bystander-dense with lower yield after de-identification.

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. The consent chain has six checkpoints, from before capture to after delivery, and a break at any one discards the footage rather than shipping it at a lower grade. At ingest, automated detection finds faces, plates and screens and blurs them irreversibly, and speech is scrubbed of names, addresses and card numbers while ambient audio is kept. A human reviewer confirms that no un-consented person is identifiable in any frame, and footage that cannot be de-identified is discarded. An undocumented bystander is also one of the machine-checked reject criteria. The anonymization record is delivered with the data.

On safety and qualification, the site states no contributor safety protocol, no hygiene or infection-control guidance, no lifting or ergonomics guidance and no hospitality certification for any room turnover row, and this page does not describe one. If your program needs terms about who performs the work, the materials used or the conditions under which it is done, raise them when you scope it. None of this is legal advice, and the executed agreement controls.

A room turnover collection uses the same capture stack as every Firsthand program. The instrumented tier is a head-mounted stereo rig that records first-person RGB, with a metric depth stream recovered from the calibrated stereo rig rather than from a standalone depth sensor, and 6-DoF IMU data at 200 Hz from head- and wrist-mounted sensors. The wider stack is ten streams: a 4K head camera, two wrist cameras, depth, IMU, 3D hand and body pose, instance segmentation and action labels, hardware-aligned under 2 ms. The two wrist cameras give a closer view of the hands than the head camera alone, which matters when one hand holds an item and the other wipes, tucks or sets it.

Every stream is hardware-triggered onto one PTP clock domain, so depth, motion and hand pose line up with the same video frame rather than being approximated afterwards. The rig is calibrated twice per session, before capture starts and after it ends, and an episode is accepted only if RMS reprojection stays under 0.28 px. The site also says depth degrades on wet and reflective surfaces and handles that with per-frame confidence maps. A guest bathroom has mirrors, fixtures and wet surfaces, but the site does not say how depth behaves on any of them, so this page makes no accuracy claim for them.

The site does not state a camera count, resolution or frame rate specific to room turnover, and it names no device, cart or tool. Force and tactile readings are not among the streams, and no robot or teleoperation data is captured. Which tier applies to your program is set in the skill spec.

From signed spec to first validated batch, the site states a median of 48 hours where coverage is deep and three to four weeks where it is thin. The hospitality page lists hospitality coverage as thin, "typically three to four weeks to first batch", and it does not say whether the Hotel & Lodging environment counts as deep, so ask which timeline applies when you request the quote. Speed comes from a warm pipeline, not from cutting consent, review or anonymization.

The site also states program milestones: a pilot reaches its first delivery in two to three weeks, and a standing program reaches full rate in four to six weeks. Those assume capture coverage is already in place. After the first batch, on-demand top-ups run against the same accept criteria, so you can add room setups or steps without rewriting the spec. The site does not state a turnaround for those later batches, so plan them in your quote.

Only footage that clears the signed accept criteria is billed as a validated hour, and rejected items are recaptured at our cost. The site does not publish a price list, a minimum order or a batch size for this task family, so those are set in your quote. Collection is fast and on demand in the sense that you do not need a standing program: a focused brief is a normal starting point.

Where this site does not state something, this page says "Not stated" rather than filling the gap. The tables below separate what is delivered from what is not stated. There is no listed label for inspection results, faults or room state, no property or room type, no amenity, linen or cart specification, no task duration, no site count, no region or city, no episode count, and no success or quality label. Nothing here reports a robot result, a benchmark or a model improvement.

Counts of contributors, hours and tasks are set in your skill spec. A task outside the rows quoted above, such as a room-attendant routine the catalog does not name, is settled in a Spec Pilot rather than assumed.

Describe the steps, the setting and the variation or failure cases your pipeline is missing. That becomes a written skill spec, quoted for reach, timeline and price before any capture begins, and most programs run a Spec Pilot first, a small, fast first batch that proves the spec and the accept criteria on real footage before volume scales. The scoping checklist below maps the parts of a skill spec onto a turnover request. A published sample recording is on the sample data outputs page if you want to see the streams before you write a spec.

Three choices matter most for this family. Name the step and the item rather than a broad activity, because that is what lets each step become one action segment. Decide whether the check and the fault report are inside the episode, since the catalog row names them and the site defines neither. And name where the episode starts and stops: the whole reset or one zone of it, since the site does not set an episode length.