Stereo Inventory Cycle Counting Data

It is first-person video of a person counting stock by hand: scanning shelf locations, counting items, recording the totals and reconciling the numbers against the system. It is recorded from their own point of view with two calibrated cameras, with hand pose and sensor streams alongside. The task is the one the site’s catalog lists in two rows. 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 the capture setup, and 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. Firsthand is not affiliated with Foxglove or the MCAP maintainers.

Two, both in the Warehouse & Distribution Center environment of the Logistics & Warehousing sector. The first is named "Count and reconcile shelf inventory using a barcode scanner and count sheets", rated Easy: "Scan shelf locations, count items and record the totals on the count sheet." The second is "Cycle Counting & Inventory", rated Easy: "Count stock in assigned locations with a scanner and reconcile the numbers against the system." Both list a head-mounted phone or a multiview rig as the capture setup, and both are Ready to deploy. The row examples name an e-commerce fulfillment hub, a distribution center, a cold storage facility and a freight warehouse.

The site says nothing further about what Ready to deploy means in volume, hours or delivered stereo footage, so this page claims none. It names only the tools and steps that appear in the rows: a barcode scanner, a scanner, count sheets, shelf locations, assigned locations, counting items and stock, recording totals and reconciling numbers against the system. The first table below reproduces both rows as the catalog states them.

The egocentric inventory counting page covers these two counting rows as egocentric capture, with delivery in RLDS, LeRobot or WebDataset, and stereo and MCAP are not its focus. The egocentric barcode scanning and labeling page lists both counting rows inside a wider table of scanning, label printing and labeling rows, and also does not give them stereo and MCAP treatment. The stereo warehouse order picking page gives stereo and MCAP treatment to the picking rows and does not cover the counting rows.

This page gives the two counting rows their own stereo and MCAP treatment, stream map and failure modes. The comparison table below sets the pages side by side.

A count happens at arm’s length: a hand reaches into a location, moves an item, aims a scanner at a label and then writes on a sheet. A stereo pair recovers depth from the calibrated frame pair rather than from a standalone depth sensor, so the shelf, the stock, the scanner and the hands share a frame. The site also states that depth degrades on wet and reflective surfaces and handles that with per-frame confidence maps.

The site gives no depth accuracy figure for counting, so whether an item edge, a shelf label or a count sheet is resolvable in depth is Not stated, and whether a given wrap, label or surface is reflective enough to lower confidence is also Not stated. A spec should check both on a Spec Pilot. Capture at your own facility is listed as not offered.

The site describes two stereo setups and does not say which one a counting order uses. The hard-environments stack is a global-shutter 4K/60 head camera with a 120° lens, two 1080p/60 wrist cameras, a depth sensor at 848×480 and 30 fps, and 200 Hz 6-DoF IMUs. The off-the-shelf stereo head rig, dataset 06, is dual fisheye cameras at 1080p per eye, a 62 mm baseline, per-unit calibration, a 9-axis IMU and hand-tracking output.

Which rig, resolution and streams a counting order uses is Not stated on the site, and the third table below sets what is stated beside what is not. Intrinsics and extrinsics are re-solved at the start and end of every session, and streams are hardware-triggered onto one clock with a 2.0 ms cross-stream ceiling. The catalog states that a multiview rig adds synchronized third-person angles when the spec asks for them, and wrist cameras give a closer view of the hands, which matters when one hand holds a scanner and the other handles stock or a pen.

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’s 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 counting work the site states hand pose, a stereo-derived depth stream with confidence maps, IMU, contact events, action segments and per-frame instance masks 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. 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.

Occlusion is the first risk. A carton, a scanner or a count sheet can hide the fingers that hold a part of the count. The visibility flag on each joint is the answer the site gives, contact events mark when a hand meets an object, masks are recorded per frame, and a spec can ask for wrist views so a grip the head camera loses is still recorded. The site does not say whether a carton, a scanner or a count sheet counts as the object for contact events, so settle it in the spec.

The number counted is the second. The site states no label for the number counted, the count accuracy or any variance against the system, and no label for a decoded barcode value, a scan result or a scan rate. The rows describe what the contributor does, not a delivered measurement, so ask for any such label at the start. Sequence and definition are also open: the rows do not say how many locations an episode holds, so the spec decides whether one episode is one location or a run of them. SKU counts, shrink rates, scan rates, retailer or warehouse names and throughput are Not stated and are set in the spec or not claimed on this page. Force and tactile readings are not among the listed streams of standard capture.

Calibration is the third, because stereo depth is only as good as the rectification behind it: calibration is measured at the start and end of every session under a 0.28 px RMS gate. An episode is also rejected when the manipulated object is out of frame for more than 15 percent of it, when more than 35 percent of depth pixels in the manipulation region are invalid, or when an undocumented bystander appears, and a reject log ships with every batch.

For every delivered episode the site states that faces, plates and screens are blurred irreversibly, and that footage that cannot be de-identified is discarded. The anonymization record ships with the data. An undocumented bystander is a stated reject criterion, and anything beyond the general rule is settled in the spec before capture. A handheld scanner or a count device may show a screen, and the general rule already covers screens.

Whether system screens, location labels or item labels are blurred beyond that general rule is Not stated, and this page makes no claim about it. Raise any such rule in the spec.

The October 2026 off-the-shelf catalog lists ~324,800 hours across 18 datasets, of which stereo is ~64,800 hours across 9 datasets. None of them names inventory counting or cycle counting among its tasks, and the one mixed-environment stereo set, S1, gives its breakdown by environment and task on request. The Logistics handling group (S2, S5, M5, MC1 and M7) is described as packing and packaging, plus factory floor and site work. So stereo inventory cycle counting in MCAP is custom collection: custom collection at scale through a network of thousands of capture providers, for a consistent, recurring data flow to labs. The off-the-shelf stereo and hand-tracking video page shows what the rig delivers, and the custom order applies it to your task.

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. Both rows are Ready to deploy and the site does not say which speed applies to a stereo counting order, so the timeline is quoted against your spec. Collections are billed per validated hour, and rejected episodes and recaptures are never billed.

Describe the tasks and where each starts and ends: the shelf location, the scan, the count, the recording of the total and the reconciliation against the system. Name the locations an episode holds, the scanner and count sheets you expect to see, what counts as a reject and 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 fifth table below shows what each spec element decides.