Stereo Car Battery Test and Replacement Data

It is first-person video of a person testing and replacing a car battery: reading voltage with a multimeter, unbolting the old battery, fitting the new one and cleaning and tightening the terminals. 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 three 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 stereo applies here only through the site’s general stereo offer: 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, and this page makes no claim that any robot has been trained on it. Firsthand is not affiliated with Foxglove or the MCAP maintainers.

Three, all in the Auto Service Center & Tire Shop environment of the Automotive & Transport sector, all rated Medium. The first is named "Test and replace a car battery using a multimeter and socket set": "Read voltage with a multimeter, unbolt the old battery, fit the new one and tighten terminals." Its status is Active collection. The second is named "Test, remove, and replace car batteries and terminals using a wrench and a multimeter.", and its catalog description reads "Automotive repair shop with vehicle lifts, tool chests, and dedicated service bays." Its status is Active collection. The third is "Battery Test & Replacement": "Test the battery with a multimeter, disconnect and swap it and clean the terminals." Its status is Ready to deploy.

All three list a head-mounted phone or a multiview rig as the capture setup. The site says nothing further about what Active collection or Ready to deploy means in volume, hours or delivered stereo footage, so this page claims none. It names only the tools and items that appear in the rows: a multimeter, a socket set, a wrench, a battery and terminals. The first table below reproduces the rows as the catalog states them.

The egocentric car battery replacement page covers the same three rows as first-person capture and lists RLDS, LeRobot, WebDataset, HDF5, zarr and Rerun .rrd as delivery formats. It does not centre a stereo pair or MCAP. The egocentric vehicle maintenance page covers thirteen rows across oil and fluid, filter, battery, brake and diagnostics work, and the battery rows are one of its five groups.

The stereo oil and fluid change page and the stereo brake pad and rotor service page give stereo and MCAP treatment to oil rows and brake rows, and neither lists a battery row. The stereo tire and wheel service page does the same for tire rows. This page gives the three battery rows their own stereo and MCAP treatment, stream map and failure modes. The comparison table below sets the pages side by side.

Testing comes first: the rows name a multimeter and describe reading voltage. The data needs to show the meter, the probes and the point of contact, and a spec decides whether reading the meter is a step of its own. Disconnecting and unbolting follow, using a socket set or a wrench as the rows name them, where the hand and the tool matter more than the wide scene. The swap, removing the old battery and fitting the new one, is the largest hand motion in the chain.

Terminal work closes the sequence: the Ready to deploy row says to clean the terminals and the first row says to tighten them. The site notes that terminals are tightened after the swap, so order matters. The site states no voltage figure, battery type or size for any row, so what the meter reads and which battery is swapped are agreed in the spec rather than assumed. Action segments carry the start and end of each step as the skill spec defines them, so a spec can ask for the whole job in one episode or isolate a single step.

A battery job is close-range work: a probe held to a terminal, a socket on a bolt, two hands lifting a battery. A stereo pair recovers depth from the calibrated frame pair rather than from a standalone depth sensor, so the probe, the terminal, the tool and the hands share a frame. That is the case the pair is for in stereo multimeter battery test video, where the question is how far the probe tip sits from the terminal and how the hand closes on a bolt.

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 battery work, so whether a terminal, a bolt head or the top of a battery is resolvable in depth is Not stated, and a spec should check it on a Spec Pilot.

The site describes two stereo setups and does not say which one a battery 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 battery 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, which matters in a service bay because the vehicle itself or the battery can hide the hands from the head view. The site does not state where the battery sits on the vehicle, so this page does not describe the vehicle layout.

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 battery 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 multimeter, a socket set, a wrench or the battery itself can hide the fingers that hold them, and the vehicle can block the first-person view. The visibility flag on each joint is the answer the site gives, contact events mark when a hand takes hold of an item such as a terminal, masks are recorded per frame, and a spec can ask for wrist views or a second angle so a grip the head camera loses is still recorded. The site does not say whether a terminal or a probe counts as the object for contact events, so settle it in the spec.

The meter reading is the second. The rows describe reading voltage, but the site states that screens are detected and blurred at ingest and does not say whether a multimeter display counts. Whether the reading stays legible in the delivered video is Not stated, so decide in the spec whether it matters before capture. Surfaces are the third: the site states that under-vehicle capture is hostile to infrared depth and that such episodes carry a depth-quality flag instead of being silently interpolated. How a stereo pair behaves around a battery and its terminals is Not stated, so ask for the flag and the confidence maps to be delivered with each episode.

Sequence is the fourth. The site notes that a job is a chain of dependent steps and that terminals are tightened after the swap, and that a spec saying "replace the battery" gives one long action segment while a spec naming test, disconnect, swap and terminals gives a sequence that can be sliced by step. The rows do not say what one episode covers, so the spec decides. Voltage figures, battery types and brands, vehicle makes and types, electric or high-voltage vehicles, service times, throughput and any safety or certification claim are Not stated and are not claimed on this page.

Calibration is the fifth, 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. It also states that licence plates and VIN plates in service-bay footage are blurred at ingest without exception. Every episode links to a signed contributor release through a documented consent chain, and the anonymization record ships with the data.

Whether shop signage, a work order, a tool display or a customer’s documents 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 a battery test or replacement among its tasks, and the one mixed-environment stereo set, S1, gives its breakdown by environment and task on request. So stereo car battery test and replacement 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 site states no provider count or throughput for these rows. 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. Two rows are Active collection and one is Ready to deploy, and the site does not say which speed applies to a stereo battery 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: the multimeter test, the disconnect, the swap and the terminal work. Name the tools you expect to see, whether an episode covers one battery or a longer visit, whether the meter reading must stay legible, 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. Delivery is rolling, per validated batch, under a perpetual, buyer-owned commercial license. The fifth table below shows what each spec element decides.