Stereo Parcel and Courier Delivery Data

It is first-person video of the final leg of a delivery: sorting parcels in a van, carrying one to a door, scanning it and handing it to the recipient, plus collecting parcels at pickup and loading the vehicle, and collecting a food order and delivering it. It is recorded from the courier’s own point of view with two calibrated cameras, with hand pose and sensor streams alongside. Stereo describes the capture, and MCAP describes the container. They are separate choices.

The site does not state that stereo is already running on these rows. The catalog lists a head-mounted phone or a multiview rig as their capture setup, so a stereo pair is a capture choice agreed in the skill spec and confirmed on a Spec Pilot. 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. Firsthand is not affiliated with Foxglove or the MCAP maintainers.

Three, all in the Last-Mile Delivery & Courier environment of the Logistics & Warehousing sector, and all listed in lib/commercial-catalog-data.ts. "Parcel delivery" is described as "Sort parcels in the van, carry them to the door, scan and hand them to the recipient." "Courier pickup and drop-off" is described as "Scan and collect parcels at pickup, load the vehicle and hand them over at drop-off." "Food delivery" is described as "Collect a food order at the restaurant, bag it in an insulated carrier and deliver it." All three are rated Easy.

All three are listed as Available on request. The site defines that as scoped and recruited to spec when a buyer asks for it, and it says nothing about delivered hours or delivered stereo footage for any row, so this page claims none. The environment examples read "Parcel delivery, food delivery, courier services, postal sorting and drop-off"; these are kinds of work, not named carriers, couriers or delivery apps, and this page names none. The fourth row in the environment, Postal sorting, is a bench task with no carry or hand-over, so it is not covered here. The first table below reproduces the three rows as the catalog states them.

The egocentric last-mile package delivery page covers the same environment as first-person catalog capture, with ten streams synced under 2 ms, and stereo and MCAP are not its subject. The egocentric box and parcel handling page covers stacking, carrying, palletizing, sealing and scanning, with the two last-mile parcel rows among many. The stereo warehouse sorting and labeling page covers three Warehouse & Distribution Center rows, all Ready to deploy, and none of the three delivery rows. The egocentric stereo MCAP page is the hub across tasks.

This page is the stereo and MCAP treatment of the delivery rows only, with its own stream map and failure modes. The second table below sets the pages side by side.

The catalog lists "Phone (head-mounted) / multiview rig" for all three rows. The site does not state a head-mounted stereo setup for them. Stereo applies through the site general stereo offer: a stereo pair is a capture choice agreed in the skill spec and confirmed on a Spec Pilot.

A multiview rig adds synchronized third-person angles, and wrist cameras give a closer view of the hands, when the spec asks for them. Whether a stereo pair is worn, mounted or combined with a multiview rig on these rows is Not stated. The site does not state capture on a customer’s own delivery routes, so where and when a program captures is agreed in the spec.

Delivery work is close and two-handed. A stereo pair recovers depth from the calibrated frame pair rather than from a standalone depth sensor, so a parcel, a scanner, a door and the hands around them share a frame. The site also states that stereo keeps working outdoors where active depth sensors struggle, and that many programs capture both and sync them on one clock. It gives no depth accuracy figure for these rows.

A stereo pair adds depth, not a verdict. The site states 1080p per eye for dataset 06, and whether that suffices to read a label or see a door handle at working distance is Not stated, so a spec should check it on a Spec Pilot.

The row names four steps: sorting parcels in the van, carrying them to the door, scanning and handing them to the recipient. The row says "the van" and "the door", and no more. The site states no vehicle type, package size or weight, door or building access detail, stop count, route or delivery time for it, and this page adds none.

Because the steps chain, action segments matter: a spec that wants sort, carry, scan and hand-over separated has to name them, and the site does not set an episode length. Whether an episode covers one parcel, one stop or a whole route is a choice for the spec.

The row covers the start and the end of a route: scanning and collecting parcels at pickup, loading the vehicle, and handing parcels over at drop-off. It can sit in the same episode as parcel delivery if the spec says so, since the rows share one environment and one capture setup.

The site states no number of drop-offs per session and no route length. Contact events and action segments can mark when a parcel is picked, loaded or handed over where the spec asks for them, aligned to video and depth.

The third row reads "Collect a food order at the restaurant, bag it in an insulated carrier and deliver it." It describes an order, not a parcel, and it is the only row that names a restaurant or an insulated carrier. This page covers it as one of the three catalog rows, labelled as food delivery wherever it is meant.

The site does not state how the final hand-over of a food order is captured, and it names no restaurant, delivery app or carrier. Those details are set in the spec.

A courier carries a parcel with both hands while moving, so the parcel and the fingers can cover the item or the scanner, and the head camera moves with the body. The site states that fingers disappear behind objects, which is why each hand joint carries a visibility flag, and that its hard-environments stack records head and wrist motion on 200 Hz IMUs alongside the video. The fast-food page notes that egocentric video puts hands entering the frame from below, occlusion during grasp and motion blur during reach into the training distribution.

The site gives no walking speed, no gait or head-movement figure and no blur measure for these rows. How often a finger is hidden during a carry or a hand-over is Not stated, so a spec can ask for wrist views or a second angle and check it on a Spec Pilot.

Only that stereo keeps working outdoors where active depth sensors struggle, and that the hand-over to a recipient is named in the Parcel delivery and Courier pickup and drop-off rows. The site states no outdoor lighting setup for these rows, no behavior of a stereo pair in glare, shade or low light, and nothing about doors, steps, stairs, gates or building access. This page states none either.

Whether a program needs capture in daylight, at dusk or at an indoor handoff is a choice for the spec, and how the pair behaves there is a question for a Spec Pilot.

The site states that egocentric capture happens in real homes, workplaces and semi-public spaces, so bystanders can end up in frame. For every delivered episode it states that faces, plates and screens are blurred irreversibly, that a reviewer confirms the result before anything ships, and that footage that cannot be de-identified is discarded. The anonymization record ships with the data, and an undocumented bystander is a stated reject criterion. Every episode links to a signed contributor release through a documented consent chain.

The site states no consent process specific to outdoor or public-space capture, no rule for passers-by on a street or at a door, and no handling for house numbers, street signs or traffic safety, so for those it is Not stated and this page invents no process. Shipping labels, address text and barcodes are not listed as blur categories on the site, so this page does not claim they are blurred. Settle any of these in the spec before capture.

MCAP is an open source container file format for multimodal log data, supporting multiple channels of timestamped pre-serialized data. It is serialization-agnostic, so messages can be Protobuf, DDS (CDR), ROS, JSON and more. Its design is row-oriented and append-only, it stores schemas alongside the data, and it offers an optional index plus optional LZ4 or Zstandard chunk compression.

Reader and writer libraries exist for C++, Go, Python, Rust, Swift and TypeScript, and the mcap CLI can inspect, merge and split files. The foxglove/mcap repository is MIT-licensed; that is the MCAP project licence, not the licence of a Firsthand delivery. The MCAP hub page and the glossary entry cover the format in full.

Firsthand offers MCAP delivery, and dataset 06 is stated as shipping as MCAP. For these rows the site states hand pose, a stereo-derived depth stream with confidence maps, IMU, contact events, action segments, per-frame instance masks and one task instruction per episode elsewhere. What it does not state is which of those are channels in an MCAP file, how they are named, what encoding they use or at what rate.

No topic name, message schema or rate is stated on this page, and none should be assumed. GPS or location traces are Not stated for delivery. Name the streams that matter in the skill spec and confirm them on a Spec Pilot batch. The fourth table below sets each stream beside what the site states about it.

Hand and parcel occlusion is the first risk. A parcel, a scanner, an insulated carrier or a finger covers the item, which is why each hand joint carries a visibility flag. An episode is rejected when the manipulated object is out of frame for more than 15 percent of it. For delivery work the spec decides what that object is: the parcel, the scanner or the food order.

Invalid depth near the work is the second. An episode is rejected when more than 35 percent of depth pixels in the manipulation region are invalid. Calibration is measured at the start and end of every session under a 0.28 px RMS gate, and an episode is rejected for a sync breach beyond the ceiling for more than three consecutive frames, for an undocumented bystander or for a mismatch against the named skill spec. A reject log ships with every batch.

Whether a parcel was delivered correctly is Not stated: the site lists no delivery-outcome or task-completion label for these rows. The fifth table below lists the failure modes beside what the site states.

The October 2026 off-the-shelf catalog lists ~324,800 hours across 18 datasets, of which stereo is ~64,800 hours across 9 datasets. The site names no parcel, courier or last-mile delivery dataset among them, so this work is custom collection, not an off-the-shelf purchase.

It is custom collection at scale through a network of thousands of capture providers, for a consistent, recurring data flow to labs. Where coverage is deep, the median time from signed spec to first validated batch is a median of 48 hours; where it is thin, turnaround runs three to four weeks. The site does not say which speed applies to these rows, so the timeline is quoted against your spec. Collections are billed per validated hour, and rejected episodes and recaptures are never billed.

Describe the steps and where each starts and ends: sorting in the van, carrying to the door, scanning, handing over, loading at pickup. Say whether an episode covers one parcel, one stop or a whole route, and name the variation your pipeline is missing. Then name the streams you want in the file, the topic naming and message encoding your reader expects, whether calibration ships inside the file or beside it, and whether MCAP is the only delivery or sits beside RLDS, LeRobot or WebDataset.

Most programs begin with a Spec Pilot, a small first batch that proves the spec and accept criteria on real footage before you scale. The sixth table below shows what each spec element decides.