Egocentric Food Delivery Pickup and Handoff Data

It is real-world video of a courier doing the food leg of last-mile work, recorded from the courier own viewpoint: collecting a food order at the restaurant, bagging it in an insulated carrier and delivering it. Depth, 3D hand pose, contact events and frame-accurate action segments sit on the same hardware clock. People reach it through several phrasings: egocentric food delivery data, first-person courier order pickup video, an insulated bag delivery dataset or custom last-mile data collection.

It needs its own page because the other delivery pages are about parcels. A food order is not a parcel, and the catalog describes it with different wording: a restaurant, an insulated carrier and a delivery. The data is human capture by paid, consented contributors, not robot or teleoperation data, so using it for a specific robot still needs your own retargeting step. The site states one task instruction per episode as its language data.

One. The row is named "Food delivery" and sits in the Last-Mile Delivery & Courier environment of the Logistics & Warehousing sector. Its description reads "Collect a food order at the restaurant, bag it in an insulated carrier and deliver it." It is rated Easy, its capture setup is "Phone (head-mounted) / multiview rig" and its status is Available on request. The first table below reproduces the row with the catalog wording, as read on the live environment page and in lib/commercial-catalog-data.ts.

The site defines Available on request as scoped and recruited to spec when a buyer asks for it. It states no delivered hours and no delivered footage for this row, so this page claims none. The environment examples line reads "Parcel delivery, food delivery, courier services, postal sorting and drop-off"; these are kinds of work, and this page names no restaurant, delivery app, brand or courier company.

The row names three actions in order: collect a food order at the restaurant, bag it in an insulated carrier, and deliver it. Those are the only phases the site states, so this page uses them as the step list. The second table below sets each against what an episode carries for it.

Pickup is the first phase, where the order is collected and the hands meet it. Bagging follows, where the order goes into the carrier. The third phase, delivering it, is where the order is carried onward and leaves the courier. The word handoff in the page title describes that end of the run. The row itself does not use the word, and the site does not state how a final hand-over of a food order is captured, so where it happens and how it is framed is set in the written spec.

Action segments carry start_ns, end_ns, verb and noun, so each phase can be its own labeled span. Which verbs and nouns are used is defined in the skill spec, not fixed by the site.

Three pages already cover neighbouring rows in the same environment. The egocentric last-mile package delivery page is about carrying a parcel to the door and handing it to a recipient, and it lists the Food delivery row only as neighbouring work. The stereo parcel and courier delivery page is the stereo and MCAP treatment of three rows, and Food delivery is one of them. The egocentric postal sorting page covers the Postal sorting row at a sorting bench, which names no carry or hand-over.

This page is the only one whose main topic is the Food delivery row: the order, the restaurant, the insulated carrier and the delivery. It is first-person catalog capture, and it does not treat stereo as its subject. The third table below sets the pages side by side.

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. Both are the capture modes the catalog lists for the Food delivery row, and for every other last-mile row.

The site does not state a camera count, resolution, frame rate or GPS trace for food delivery, and it names no city, restaurant type or route. Raise these in the spec if your policy needs them.

No, not as the catalog states it. The row lists a head-mounted phone or a multiview rig, and the site does not state a stereo pair for it. Stereo applies only through the general stereo offer: a calibrated pair, agreed in the skill spec and confirmed on a Spec Pilot, if your policy needs depth from frame pairs.

The site describes its stereo head rig as dual fisheye, 1080p per eye, 62 mm baseline, with per-unit calibration, a 9-axis IMU and hand-tracking output, shipped as MCAP. That is a general rig description, not a statement that food delivery has been captured with it. The stereo parcel and courier delivery page is where the stereo and MCAP treatment of the delivery rows sits.

Each episode follows the Firsthand episode schema: ten streams synced under 2 ms, with head and wrist RGB, depth, 3D hand pose with per-joint visibility, contact and grasp events, and frame-accurate action segments. For food delivery, hand pose tracks the grip on an order or a bag and the release, contact events mark when fingers meet the order or the carrier, and action segments mark each phase.

Object labels use the terms your spec sets. Order sizes, carrier models, force or tactile data and a delivery-outcome label are Not stated. The fourth table below lists what is stated and what is not.

The site states the row, its rating, its capture setup and its status. It does not state order counts, delivery times, distances, success rates, delivery-app or restaurant names, or whether a run is on foot or by vehicle. This page makes no claim on any of them.

It also gives no food-safety guidance and no traffic-safety guidance. The row says insulated carrier and nothing about temperatures, handling rules or road rules, so this page adds none. Anything your policy needs on those points is written into the spec and the accept criteria.

Every episode links to a signed contributor release through a documented consent chain, and the consent record is part of the delivery. Faces, plates and screens are detected and irreversibly blurred at ingest, and a reviewer confirms the result before anything ships. The anonymization record is delivered with the data.

The anonymization page states that egocentric capture happens in real homes, workplaces and semi-public spaces, so bystanders end up in frame, and that the pass removes them before anyone downstream sees the footage. The site also states that a clip where a bystander cannot be de-identified is discarded rather than shipped. It does not state a rule for house numbers, addresses, street signs or order text on screens beyond the screen blur, so those are agreed in the spec.

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 Food delivery row is Available on request, so the site states no capture timeline for it beyond a quote against your spec. On-demand top-ups run against the same spec and accept criteria after each training run.

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.

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, rejected items are recaptured at our cost, and every collection ships under a perpetual, irrevocable, buyer-owned commercial license that is non-exclusive by default.

You describe the orders, the pickup, the bagging and the delivery your policy needs to handle. 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.

A Spec Pilot, a small and fast first batch, can prove the spec and accept criteria before you scale. Nothing is captured until the spec is signed.