Egocentric Sandwich and Salad Assembly Video Data

Egocentric sandwich and salad assembly data is real-world video of a person assembling food by hand: tearing greens and adding toppings, or building burgers, wraps and sides from a line. The footage shows the hands, the ingredients and the work surface as the build comes together. Alongside the video, each episode carries depth, 3D hand pose, contact events and frame-accurate action segments, all aligned on one hardware clock.

Teams search for it as food assembly robot training data, a sandwich making video dataset and egocentric salad prep data. They all describe demonstrations of a multi-step build, collected to a written spec. This page covers only what the Firsthand site states about it and marks everything else as Not stated.

The site states two assembly rows in its commercial task catalog. One is "Assemble a salad", described as "Tear greens, add toppings, dress, and toss a salad". The other is "Order assembly", described as "Assemble burgers, wraps and sides from the line in order, wrap and place them on trays".

Each wording names several operations in order, which is the shape of a spec: the salad row runs from tearing to tossing, and the order row runs from the line to the tray. Anything outside that wording is Not stated, so this page does not claim it. A policy that needs another build writes it into the spec and we scope it, because a catalog row is a starting vocabulary, not a fixed menu.

The salad row is rated Medium and sits in the Food & Beverage sector, in an environment called Working Kitchen Set (food prep). Its capture mode is a multiview rig with handheld grippers, and its status is Available on request.

The site defines that status plainly: the task is scoped and recruited to spec when a buyer asks for it. So recording for the row is not already running, and a first batch is quoted against your spec. The site does not state how many hours, episodes or contributors exist for it, and it states no greens, toppings or dressings.

The order assembly row is rated Easy and sits in an environment called Fast Food & Quick Service Kitchen, one of three rows there. Its capture mode is listed as phone (head-mounted) or multiview rig, and its status is Available on request.

It adds an ordering constraint the salad row lacks: the items come from the line in order and finish on a tray. The row does not state a recipe, an item count or a tray format, and what counts as a correct build is Not stated, so the accept criteria are written into the spec. The same sentence also uses wrap as a verb, so a spec should say whether wrapping the finished item is in scope.

Not by name as a task. The word sandwich appears on the site only in the environment examples for the quick-service kitchen, "Burger chain, fried chicken, pizza counter, sandwich shop, fast-casual kitchen", which are kinds of operation and not task rows. The word bowl does not appear in any assembly task. The site words its build rows as a salad and as burgers, wraps and sides.

The nearest neighbours are a row on the Working Kitchen Set named "Slice + spread", described as "Slice bread and spread a condiment" and rated Medium, and a row named "Pack a lunchbox", described as "Pack a lunchbox with items into compartments". Neither is stated as a sandwich or a bowl. The word sandwich in the route is the term teams search for, so a team that wants layering steps writes them into the spec.

The Working Kitchen Set (food prep) lists "Stovetop, counter, sink, dishwasher, utensils, food props" among its examples. It holds 14 rows: four rated Easy and ten Medium, with the salad row among the ten. All 14 are Available on request, and all 14 list the multiview rig with handheld grippers.

The site defines that capture mode as a staged working set: a multiview rig records the scene while the operator performs the task with handheld grippers, so demonstrations map onto a robot end effector. So for the salad row the site describes a staged set, and the word props in the examples fits that reading. The Fast Food & Quick Service Kitchen lists both a head-mounted phone and a multiview rig for its rows. The site describes the phone mode as real work on site and the rig as a staged set, but it does not say which applies to the order assembly row.

The site names no chain, restaurant, store or venue, and does not state the number of sites, the regions or the kitchen or store types. It does not state capture at a customer site either. Environment, access and schedule are agreed in the written spec.

In the multiview mode, a rig records the staged working set while the operator performs the task with handheld grippers. Camera count, resolution, frame rate and counter layout are Not stated. In the phone mode, a head-mounted phone records first-person video of real work on site. Which streams each mode populates is confirmed in the spec.

Each episode follows the Firsthand episode schema: ten streams synced under 2 ms, with RGB, depth, 3D hand pose with per-joint visibility, contact and grasp events, and frame-accurate action segments. For assembly, hand pose tracks the fingers and wrist as they tear, pinch and place, contact events mark when a hand or gripper meets or leaves an ingredient or a tray, and action segments mark each step of the build.

Object labels use the terms your spec sets. Ingredients, recipes, portion sizes, utensils, equipment models and kitchen or store types are Not stated. Task durations, cycle times, throughput and the number of episodes are Not stated too, as are success or quality labels, food-safety certifications and robot results.

The site rates the salad row Medium, one of ten Medium rows among the 14 in its environment, and the order assembly row Easy, one of two Easy rows among three. Those ratings are the only statements on difficulty. The site gives no technical analysis of food assembly, so this page makes no claim about robot results.

What the row wording implies is a multi-step build on soft, varied items. Tearing, adding, dressing and tossing each change the state of the dish, and the order row adds a sequence from the line to the tray. The site has a separate page on deformable object data, and a spec names the start and end state of each step so action segments stay consistent across contributors.

A good spec treats each named operation as its own task. Tearing greens, adding toppings, dressing and tossing each get a start state, an end state and a set of accept criteria, and so do taking items from the line, wrapping them and placing them on a tray. That lets you ask for more of one step without re-collecting the others.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd. Assembly episodes use the same schema as every other Firsthand collection, so a loader that reads another Firsthand dataset reads this one without changes. The format table below sets each format against what its official documentation states.

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

Not in standard capture. Force or tactile readings are Not stated for either row. The site separately offers a tactile glove tier as a pilot-ready option, in which glove signals are time-synced to a head-mounted stereo camera by hardware timestamps and an IMU. The site does not state that the tier has been used on food assembly, so agree the fit with us first.

Every episode links to a signed contributor release through a documented consent chain, and the consent record is part of the delivery. A vision model runs on every frame at ingest, flagging faces, heads, licence plates and any legible screen or document. Those regions are irreversibly blurred, and a human reviewer confirms the result before footage ships.

If the reviewer is unsure a region is fully covered, the episode is held or discarded, never downgraded and shipped. The site does not state that readable signage or labels are blurred, so raise any such need before the spec is signed. It states no food-safety, hygiene-certification or allergen claims for this work, and this page makes none. It states no in-home capture.

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. Both assembly rows are Available on request, so they are recruited to your spec first, and the 48 hour figure should not be assumed.

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. A batch size and a later-batch turnaround are Not stated, so both are quoted against your spec.

You describe the builds, the ingredients and the sequence your policy needs. We turn that into a written spec covering tasks, environments, capture tier, annotation depth and accept criteria, then quote reach, timeline and price before any capture begins. This is the custom egocentric data collection route that every Firsthand task family follows.

A Spec Pilot, a small and fast first batch, can prove the spec and accept criteria before you scale. Every collection ships under a perpetual, buyer-owned commercial license, with a reject log and signed accept criteria on every batch.