Stereo Electronics and Device Repair Data

It is first-person video of a person doing device repair work: diagnosing and repairing phones, laptops, tablets and consumer electronics at a repair counter. It is recorded from their 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 this row. The catalog lists a head-mounted phone or a multiview rig as its 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. The site does not state device models, repair outcomes, turnaround or a diagnosis label, so this page promises none. Firsthand is not affiliated with Foxglove or the MCAP maintainers.

One, in the Electronics & Device Repair Shop environment of the Repair Services sector. It is named "Device Repair", rated Hard, and described as "Diagnosing and repairing phones, laptops, tablets and consumer electronics." The example the catalog gives for the environment is a phone, laptop and consumer electronics repair counter. It lists a head-mounted phone or a multiview rig as the capture setup, and its status is Active collection, which the site describes as recording running now.

The site says nothing about delivered hours or delivered stereo footage for this row, so this page claims none. The row names only categories of device: phones, laptops, tablets and consumer electronics. It names no tool, brand or model. A neighbouring row in the Repair Shop environment, "Electronics repair" (Hard, Available on request), reads "Open the device, diagnose the fault, replace the screen, battery or board and test." This page uses it only to describe the steps a repair spec can name, and the first table below reproduces both rows as the catalog states them.

The egocentric electronics and device repair page covers the Device Repair row and its neighbours with egocentric catalog treatment and has no stereo or MCAP treatment. The stereo soldering and circuit board assembly page gives stereo and MCAP treatment to two board rows, and the stereo e-waste disassembly and sorting page does the same for one teardown row. Neither stereo page names a fault, a diagnosis or a replacement.

This page is the stereo and MCAP treatment of the Device Repair row, with its own stream map and failure modes. The comparison table below sets the pages side by side, with each row status stated as the live catalog lists it.

Repair is about where a part is, what the hand does to reach it and how the device changes as it is opened: a cover lifted, a part eased out, a replacement seated. A stereo pair recovers depth from the calibrated frame pair rather than from a standalone depth sensor, so the device, the tool and the hands share a frame. The site gives no depth accuracy figure for this row and no diagnosis, fault or repair-outcome label, so what a buyer does with that depth is their pipeline question.

A stereo pair adds depth, not a verdict on the repair. The site states 1080p per eye for dataset 06 and gives no figure for how well small parts such as screws or connectors resolve, so that is Not stated and a spec should check it on a Spec Pilot. The site states that Firsthand does not capture at a customer’s own facility and names no repair shop.

The site states 3D hand pose of 21 joints per hand with a per-joint visibility flag, and contact and grasp events that mark when fingers meet a tool or an item. It also states that fine manipulation happens at the fingertip and that wrist-level capture loses that signal. In this row that is the fingers lifting a cover, easing out a part and seating a replacement.

The site does not say how finely hand pose resolves very small parts, and it does not say whether the casing, the part or the tool counts as the object for contact events, so settle both in the spec. Wrist cameras give a closer view of the hands, and a multiview rig adds synchronized third-person angles when the spec asks for them.

The site describes two stereo setups and does not say which one a device repair 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 device repair 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. Counter layout, lighting, tools, magnification and camera clearance are Not stated, so any requirement is settled in the spec.

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 this row 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.

Hand occlusion is the first risk. A casing, a lifted cover or a tool can hide the fingers that hold a part. The visibility flag on each joint is the answer the site gives, contact events mark when a hand takes hold of a part or a tool, and a spec can ask for wrist views or a second angle so a grip the head camera loses is still recorded. An episode is rejected when the manipulated object is out of frame for more than 15 percent of it.

Reflective screens and glossy casings are the second. The site describes glossy or dark surfaces and small parts held close to the lens as places where a single camera loses information, and it states that depth degrades on wet and reflective surfaces and ships per-frame confidence maps so a buyer can mask rather than guess. How a stereo pair behaves on a phone screen or a glossy casing is Not stated. An episode is rejected when more than 35 percent of depth pixels in the manipulation region are invalid.

Close working distance is the third. Distance-invalid pixels beyond the depth sensor reliable range are flagged rather than interpolated, but the site does not state how depth behaves at the close range of a repair counter, so raise it in the spec if your policy relies on it. Small parts and fine fingertip manipulation are the fourth: the site gives no figure for how finely hand pose resolves very small parts, so that is Not stated and should be checked on a Spec Pilot.

Sequence and calibration close the list. The row names diagnosing and repairing without splitting them into stages, so a spec naming each step and where it starts and ends gives a sequence that can be sliced by step, while a spec saying “repair the device” gives one long action segment. 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 an undocumented bystander appears, and a reject log ships with every batch. Device brands or models, repair success or turnaround rates, throughput, repair-shop or customer names, tool brands and ESD or safety certifications are Not stated and are not claimed here.

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, and an undocumented bystander is a stated reject criterion.

The site does not state a rule specific to a repair counter, customer data stored on a device, a data wipe before repair, or serial numbers and labels on a casing, so this page makes no such claim. Settle it 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. One listed dataset, M3, is mono: about 50,000 hours of smartphone RGB video whose environment is labelled “Electronics and components: handling, assembly and repair”. Being mono, it has no stereo pair, and the site does not state that it contains device repair task video. The site lists no off-the-shelf stereo device repair dataset.

Stereo device repair in MCAP is therefore custom repair shop data collection: 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 a stereo device repair 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 steps and where each starts and ends: diagnosing, opening, replacing a part and testing. Name the device categories you expect to see, whether an episode covers one repair or a longer stretch of work, 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.