Egocentric Tote Induction and Conveyor Loading Data

Egocentric tote induction and conveyor loading data is real-world, first-person video of a person moving totes and items onto and around a conveyor. It is recorded from the operator viewpoint, with depth, 3D hand pose, contact events and frame-accurate action segments aligned on one hardware clock.

A tote has to be taken, carried and set on a moving surface, and an item has to be placed onto a belt already in motion. A first-person view keeps the tote, both hands and the conveyor in one frame.

Box and parcel handling is about the box, bin picking is about single items from a bin, and packing is about filling a container. Here the tote and the conveyor are the point.

Exactly four task rows in the catalog name a tote or a conveyor as the task: Tote induction, Load conveyor, Stack empty totes and Each-pick to tote. All four sit in the warehouse zone environment, which the catalog describes with a conveyor, racking, pallets, totes, a pack bench and scale. All four carry a skill rating of Easy and are Available on request.

A custom spec is scoped from that same vocabulary, with these four rows as a starting point rather than a fixed menu. The first table below lists every row as the catalog states it.

Tote induction is described in the catalog as inducting totes onto a conveyor. Load conveyor is described as loading items onto a moving conveyor. The first is about the tote as the object that enters the line; the second is about the items that go onto a belt that is already running.

The site does not state a conveyor speed, belt layout, tote size or tote spacing, and it does not break either row into sub-steps. A spec that needs any of them states it explicitly.

Stack empty totes is described as nesting and stacking empty totes. Each-pick to tote is described as picking individual items to a tote. The first handles the container; the second fills it one item at a time.

Neither row names a stack height, a tote count or an item type. The generic Warehousing / Logistics row, which mentions totes among other items, is not counted as a tote row.

All four rows are listed for one environment, the warehouse zone, with a conveyor, racking, pallets, totes, a pack bench and scale. The site does not state which specific sites a tote and conveyor collection runs at, so the environment, access and schedule are agreed in the written spec.

Available on request means the work is scoped and recruited to spec when a buyer asks for it. All four tote and conveyor rows carry that status.

The catalog names the capture setup for all four rows as a multiview rig with handheld grippers: 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.

Firsthand custom collections use a head-mounted camera for the first-person view, with a wrist-mounted camera available alongside it for close-range detail. Depth, 3D hand pose, contact events and action segments are aligned to video on one hardware clock, synced under 2 ms. Distance-invalid pixels beyond the depth sensor reliable range are flagged rather than interpolated.

Each episode follows the same episode schema used across Firsthand custom collections: 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. Warehouse collections also state instance segmentation.

For tote and conveyor work, hand pose tracks the operator through the grasp, lift, place and release, contact events mark when the fingers make and break contact with a tote or item, and action segments mark the start and end of each step.

Throughput, conveyor speed or vendor, warehouse management system data, tote size, weight or counts, item identity, force or tactile data, a jam or drop label and any safety certification are not stated on the site as standard fields. If your policy needs any of them, they are defined in the written spec as annotation depth.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd. The first three are the training-loader formats; HDF5 and zarr carry arrays for custom pipelines, and Rerun .rrd gives a multi-stream synchronized playback file for review. 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. The episode schema page lists the fields.

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. Tote labels, shipping labels and printed text are not listed as blur categories on the site, so this page does not claim they are blurred. If text on a tote matters for your use, raise it 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 timeline up front. The catalog status on each task row tells you which case you are in.

On-demand top-ups run against the same spec and accept criteria after each training run, so new data stays consistent with what you already hold.

You describe the totes, items, conveyor position and 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 against that document before any capture begins.

A Spec Pilot, a small and fast first batch, can prove the spec and the accept criteria before you scale volume. Billing is per validated hour, a reject log ships with every batch, and rejected items are recaptured at our cost.