Egocentric Luggage and Baggage Handling Data

Egocentric luggage and baggage handling data is real-world, first-person video of the physical work of moving bags, recorded against a written spec with the streams the site states for its custom collections. This page joins rows the site keeps in two places: one guest-facing hotel row and three bag rows on a staged mock checkpoint.

It is task data, not footage of travellers. The checkpoint set is described as props with no live airport, and this page does not describe capturing real passengers, baggage systems or screening. The hotel row is real work on site, and the site names no property for it.

Four catalog rows are counted. Luggage Handling sits in Hotel & Lodging, under Hospitality & Events, rated Easy with the status Ready to deploy. Bag search + re-pack, Baggage load to belt and Baggage tag scan sit in Mock Security Checkpoint, under Public Spaces & Outdoor. The first two are rated Medium, the tag scan Easy, and all three are Available on request.

Other bag-adjacent rows are left out on purpose and listed in a table below, because a row about trays, boxes, documents or room resets does not state luggage work.

The catalog line for Luggage Handling reads: load guest luggage onto a trolley, move it through the hotel and deliver it to the room. That is three steps in one row: load, move and deliver. The catalog does not use the word bellhop, and this page names no job title and makes no claim about any staff role.

The site states no luggage sizes, weights, trolley model, route length or delivery rules, so those are set in the spec. Luggage Handling is the only hotel row that names bags.

Three rows use bag props on a staged set. Baggage load to belt loads bags to a belt at pitch, rated Medium. Bag search + re-pack opens, inspects and re-packs a bag, also Medium. Baggage tag scan scans a bag tag and routes it, rated Easy. The environment lists screening bins, a belt, a wand, a mannequin and bag props, with no live airport.

The phrase "at pitch" is catalog wording, and the site states no belt speed, spacing or bag counts. This is a mock checkpoint only. The page makes no real-screening, detection or threat claim, and the site does not say what inspecting a bag means, what a route is or what a tag encodes.

The site states no robot results for baggage work, so this section describes what the work asks of a dataset, not what any policy achieves. Luggage is a container that is lifted, set down and delivered in order, and a trolley adds a second object to load onto and move through the hotel.

At the checkpoint, a bag opens, holds other items and closes again, so re-packing changes what the next grasp finds. A tag scan is a small, precise action, and a belt adds timing to placement. The site states no cycle times or error rates, so a spec names the tasks, bag types and number of sequences.

The catalog lists two modes. The hotel row lists a head-mounted phone and a multiview rig: 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 three checkpoint rows list a multiview rig with handheld grippers, so demonstrations map onto a robot end effector.

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 baggage work are Not stated, so session length and volume are quoted against your spec.

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 item.

For luggage work, contact events mark touches on a handle or trolley and action segments mark load, move and deliver. For checkpoint work, they mark load, scan, open and re-pack. The site does not say which streams apply to each row, so the stream list is confirmed in the spec. Force or tactile data and success labels are Not stated for these rows.

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. Speech is scrubbed of names, addresses and card numbers, while ambient audio is kept.

Luggage delivery is guest-facing work, and the hospitality page states that front-of-house settings are bystander-dense with lower yield after de-identification. The site states no rule for printed text on a bag tag or luggage label, and none for bystanders at the mock checkpoint, so both are settled in the spec. The site names no venue, property or region for these rows.

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 bag or object labels 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 checkpoint rows.

The hotel row is Ready to deploy, which means contributors and site access are set up and capture starts once a spec is signed. The three checkpoint rows are Available on request. Either way the timeline is quoted against your spec before capture begins, and on-demand top-ups run against the same accept criteria.