Egocentric Brake Pad and Rotor Service Data

Egocentric brake pad and rotor service data is real-world, first-person video of a person doing brake work: jacking the car, removing the wheel, compressing the caliper, replacing the pads and rotor, and torquing the bolts. It is recorded from the operator viewpoint, with depth, 3D hand pose, contact events and frame-accurate action segments aligned on one hardware clock.

Brake work asks a lot of a manipulation policy because it is a chain of heavy, awkward, multi-step handling with different tools at each stage, not a single grasp. A first-person view keeps the wheel, the caliper and both hands in the same frame, which is the viewpoint a robot arm with a head or wrist camera would act from.

This page treats brake pad and rotor service as a task family in its own right. The vehicle maintenance page covers oil, filter, battery, brake and diagnostic work together, and the tire and wheel page covers tire rows. Here the task centres on the brakes.

The site states brake service in its task catalog. An environment called Auto Service Center & Tire Shop lists three brake rows: one replacing brake pads with a jack, lug wrench and C-clamp, one replacing and torquing brake pads and rotors with a socket set and a torque wrench, and one named Brake Pad & Rotor Service. Its listed examples include brake work next to oil changes, tire rotation and vehicle diagnostics.

All three rows are rated Hard, and all are recorded with the same capture mode, a head-mounted phone or a multiview rig. Two are Active collection and one is Ready to deploy.

A custom spec is scoped from that vocabulary. You describe the vehicles, tools, stations and sequence your policy needs, and the written spec covers them, with the catalog rows as a starting point rather than a fixed menu.

One row is described as jacking the car, removing the wheel, compressing the caliper and replacing the brake pads, with a jack, a lug wrench and a C-clamp named as the tools. It is rated Hard and its status is Active collection, so recording is running now and a spec can join an existing capture stream.

The motion is a short chain with a clear order: lift, remove the wheel, compress, replace. Action segments are useful here because the boundaries between those steps are exactly the moments a policy has to sequence correctly. A spec can ask for the whole chain or isolate one step.

The site gives no vehicle type, no brake type and no number of wheels per episode for this row. Which vehicle is used, how an episode starts and ends, and whether it covers one wheel or an axle are agreed in the written spec rather than assumed.

A second row is described as removing, replacing and torquing brake pads and rotors using a socket set and a torque wrench. It is rated Hard and its status is Active collection. The catalog gives this row a setting as its description, an automotive repair shop with vehicle lifts, tool chests and dedicated service bays, rather than a list of steps.

A third row, Brake Pad & Rotor Service, is described as lifting the car, removing the wheel and caliper, fitting new pads and a rotor and torquing the bolts. It is rated Hard and its status is Ready to deploy, so contributors and site access are set up and capture starts once a spec is signed.

The site states no torque values, no bolt counts and no tightening sequence for any row. A spec that needs a torque step captured defines it up front.

Torque values, vehicle or brake types, lift or tool specifications, throughput, force or tactile data, a task-completion label and any safety, brake-performance or certification claim are not stated anywhere on the site as standard fields. This page makes none of those claims.

If your policy needs any of them, they are defined in the written spec as annotation depth, and the quote covers them before capture begins. The page does not promise them by default.

The catalog places the brake rows in its Auto Service Center & Tire Shop environment. The site separately describes its automotive dataset as captured in working service bays rather than a staged mock-up, with a lift bay and under-vehicle work on a lift among the listed bays.

The site defines the statuses plainly. Ready to deploy means contributors and site access are set up and capture starts once a spec is signed. Active collection means recording is running now, so a spec can join an existing capture stream. The brake rows sit in those two, so no brake row is currently scoped-to-spec only.

The site names no shop, dealership, vehicle or brand for any row, and it does not state capture at a customer own facility. Environment, access and schedule are agreed in the written spec.

The catalog names a head-mounted phone or multiview rig as the capture mode for every brake row. A head-mounted phone records the first-person view of real work on site, and a multiview rig adds synchronized third-person angles when the spec asks for them.

A head-mounted camera keeps the lift, remove, compress and fit motion in frame from the viewpoint a manipulation policy will see from, 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.

The site does not state a camera count, resolution or frame rate specific to brake service, so those are agreed in the written spec. It also states that the vehicle itself can occlude the view in a service bay, so the second angle from a multiview rig is worth asking for.

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.

For brake service, hand pose tracks the operator through the grip on a clamp or socket, contact events mark when the fingers make and break contact with a wheel, a caliper or a tool, and action segments mark the start and end of each step. Because the labels share one clock with the video and depth, a step boundary lines up with the exact frame where it happens.

Object labels use the terms your spec sets, so labels follow the vocabulary your training stack expects rather than a generic taxonomy.

The site states that the automotive dataset holds a large share of cluttered and low-light work and that under-vehicle capture is hostile to infrared depth, because painted and oily surfaces absorb the projector pattern. Those episodes carry a depth-quality flag instead of being silently interpolated.

Brake work near a lifted vehicle puts the same surfaces in frame, so a spec can ask for the depth-quality flag to be delivered with each episode and for the second angle to cover moments when the vehicle blocks the view. The site does not state a depth accuracy figure specific to brake service.

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.

Brake episodes use the same schema as every other Firsthand collection, so a loader that already reads another Firsthand dataset reads this one without changes. Every batch is validated against signed accept criteria before it ships, with a reject log, and delivery is rolling, per validated batch.

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 site states that licence plates and VIN plates in service-bay footage are blurred at ingest without exception, and the anonymization record is delivered with the data.

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, and the brake rows are currently Active collection or Ready to deploy.

On-demand top-ups run against the same spec and accept criteria after each training run, so new brake data stays consistent with what you already hold. The site does not state a batch size or a later-batch turnaround, so those are quoted against your spec.

You describe the vehicles, tools, stations 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.

Every custom collection ships under a perpetual, buyer-owned commercial license, and exclusivity is available so the data is never resold. The license is documented alongside the consent chain, so a policy trained on the data can go into a product.