Egocentric Part Trimming and Deflashing Data

Egocentric part trimming and deflashing data is first-person video of a person removing flash from molded parts, recorded from the contributor’s own point of view with synchronized sensor streams alongside. The camera sits on the head, close to what a robot’s onboard camera would see while it handles a small part, so the frames show the hands on the part, the cutter at the flash and the blade along the edge, rather than a distant view of someone at a bench. On this site it is a custom collection: you name the task, the parts and the setting, and capture is run to a written skill spec.

The data is human capture. A paid, consented contributor wears the rig and does the task. It is not robot or teleoperation data, and it is not a fixed corpus you download. This page is a different subject from egocentric light assembly manufacturing data, which covers all fifteen rows of the Plastic & Light-Assembly Manufacturer environment, from egocentric sanding and finishing data, which centres on sanding, polishing, buffing and deburring across fourteen rows, and from visual inspection data, which centres on checking units. The subject here is the two catalog rows that trim and deflash molded parts.

People reach this topic through close cousins: deflashing robot training data, a molded part trimming video dataset, egocentric flash removal and deburring data, or custom light-manufacturing data collection. They describe one request from different angles, and the work is the same: write down the task, collect it on demand, and receive validated episodes. Nothing on this page states that the video carries a flash-detection label, an edge-quality score or a measurement.

A published robot foundation model paper, GR00T N1, linked in the sources below, describes a data pyramid with web data and human video at the base, synthetic data in the middle and real robot trajectories at the top. First-person human video of trimming work sits in that base layer. Human capture does not replace robot data, and this page does not claim that it does.

Deflashing is a sequence of small moves with a small workpiece. The catalog describes the rows as trimming flash from molded parts with flush cutters and cleaning edges with a deburring blade, or cutting excess plastic and deburring edges with hand tools. The hands matter: the site’s tool use page says that grip changes live in finger-level detail that RGB video alone cannot resolve. A clip that shows a part somewhere on a bench does not carry what a policy needs. The hands, the tool and the part have to be present in the episode, and the episode has to say where one step ends and the next begins.

Breadth matters as much as volume. A published model write-up, GEN-0, also linked in the sources, puts it this way: "data quality and diversity matters more than sheer volume." For trimming work that points at the spread of parts, tools and steps. A custom collection lets you aim at the step your model is missing, such as the edge clean-up, rather than hoping a broad collection happens to contain it. This page does not claim that any public corpus lacks deflashing data.

The site’s commercial task catalog lists two rows for this subject, both in the Plastic & Light-Assembly Manufacturer environment of the Manufacturing & Workshops sector. "Trim and deflash molded parts using flush cutters and deburring blades" reads "Trim flash from molded parts with flush cutters and clean edges with a deburring blade." "Trimming & Deflashing Parts" reads "Cut excess plastic from molded parts and deburr edges with hand tools." Both are rated Easy, captured with a head-mounted phone or multiview rig, and marked Ready to deploy, which the catalog defines as contributors and site access already set up. The first table below reproduces them exactly as stated.

Other catalog rows touch the same work and are separate listings. Plastic Chair Manufacturing unloads molded chair shells, trims flash, fits legs and hardware and stacks finished chairs. Injection-Molding Machine Tending, and the row that tends and unloads a molding machine with heat gloves and part bins, include trimming as one step of a longer cycle. Two Metal Fabrication & Welding Workshop rows grind and deburr welds and cut edges, which is metal work, not molded plastic, so this page does not claim them. The second table below sets them side by side.

The site does not describe a part material, a part size, a resin, a mold, a cutter model or a blade type for these rows, so none is stated here. A task outside the rows is settled in a Spec Pilot rather than assumed.

Each attempt is delivered as one episode, and a trimming task needs a decision up front about what one attempt is: one part trimmed and cleaned, a batch of parts, or one step such as the edge clean-up. The site does not set that length, so the skill spec does. Inside the episode, the synchronized streams run from start to end, and action segments divide it into labeled spans.

An episode might open with a part being picked up and close with it set aside, as the catalog rows word the work. That is an illustration of how a spec can cut an episode, not a stated duration. Whether each part is one episode or several is a spec decision.

How many parts and tools are covered is set in the spec. The site states that Firsthand does not capture at a customer’s own facility, so the bench or line used is agreed in the skill spec.

A deflashing collection uses the same capture stack as every Firsthand program. The instrumented tier is a head-mounted stereo rig that records first-person RGB, with a metric depth stream recovered from the calibrated stereo rig rather than from a standalone depth sensor, and 6-DoF IMU data at 200 Hz from head- and wrist-mounted sensors. The wider stack is ten streams: a 4K head camera, two wrist cameras, depth, IMU, 3D hand and body pose, instance segmentation and action labels, hardware-aligned under 2 ms. The two wrist cameras give a closer view of the hands than the head camera alone, which matters where fingers steady a small part.

Every stream is hardware-triggered onto one PTP clock domain, so depth, motion and hand pose line up with the same video frame rather than being approximated afterwards. The rig is calibrated twice per session, before capture starts and after it ends, and an episode is accepted only if RMS reprojection stays under 0.28 px. The catalog lists a head-mounted phone or multiview rig for both rows; a multiview rig adds synchronized third-person angles when the spec asks for them. Which tier applies to your program is set in the skill spec.

The site does not state a camera count, resolution or frame rate specific to deflashing. Force and tactile readings are not among the streams, and no robot or teleoperation data is captured.

Inside each episode, action segments divide the recording into start- and end-timestamped spans, each carrying start_ns, end_ns, verb and noun. For this task a segment can be one step as written in the skill spec, so the catalog rows become a run of labeled steps such as trim, clean the edge and set aside rather than one long clip. The other standard fields are hand_joints and hand_visible for 3D hand pose, contact_events for the moment the hand meets an object, objects, and instance_masks, stored at the depth resolution of 848×480 so they line up with the depth stream.

Hand pose is delivered for both hands with a per-joint visibility flag for occluded fingers, 21 joints per hand in 3D. That is the label that carries how the hands hold a part and how they move while the cutter works. The site describes contact events as the moment the hand meets an item, and it does not say whether a cutter, a blade or a part counts as the item, so the spec is the place to settle what a contact event means for your task.

The site does not list labels for the flash or the edge itself. There is no stated label for flash location, burr presence, edge quality, part dimension, tolerance, defect or task-completion score, and no contact force reading. The catalog description describes the task the contributor performs, not a delivered measurement.

Several limits the site already states apply directly to trimming capture, and several it leaves open. Each stated limit below appears elsewhere on the site rather than being introduced here.

Hand occlusion is the first. Fingers disappear behind objects in manipulation, which is why 3D hand pose carries a per-joint visibility flag, and the light assembly page says the same of small parts hidden by fingers. Depth is the second. The site says depth degrades on wet and reflective surfaces and handles that with per-frame confidence maps. It does not say how depth behaves on a glossy molded part in particular, or on a small part held in a hand.

The third is the set of machine-checked reject criteria. An episode is rejected for a sync breach beyond the ceiling for more than three consecutive frames, calibration drift beyond tolerance, the manipulated object out of frame for more than 15 percent of the episode, more than 35 percent invalid depth pixels in the manipulation region, an undocumented bystander, or a mismatch against the named skill spec. A human reviewer then checks each episode against the task spec. For a deflashing task, the spec decides what the manipulated object is: the part, the tool or both.

Also not stated: a mask accuracy figure for small molded parts, and any description of how a part fully covered by the hand is handled. If your policy depends on either, say so at the start.

Validation runs against signed accept criteria written into the spec before capture. Each batch goes through per-batch QA and a reject log ships with it. Only footage that clears the criteria is billed as a validated hour, and rejected items are recaptured at our cost. Many teams start with a Spec Pilot, a small, fast first batch that proves the spec and the accept criteria on real footage before volume scales.

Every contributor signs a written release before capture, and each delivered episode links to that record through consent artefact IDs in the batch data card. At ingest, automated detection finds faces, plates and screens and blurs them irreversibly, and speech is scrubbed of names, addresses and card numbers while ambient audio is kept. A human reviewer confirms that no un-consented person is identifiable in any frame, and footage that cannot be de-identified is discarded. The anonymization record is delivered with the data.

On safety and quality, the site states no contributor safety protocol, no guidance on protective equipment or cutting tools, no tolerance, cycle-time or defect-rate figure, and no safety, quality-system or certification claim for these rows, and this page does not describe one. If your program needs terms about who performs the work, the parts used or the conditions under which it is done, raise them when you scope it. None of this is legal advice, and the executed agreement controls.

From signed spec to first validated batch, the timeline is a median of 48 hours where coverage is deep and three to four weeks where it is thin and contributors need to be recruited first. Speed comes from a warm pipeline, not from cutting consent, review or anonymization. Both deflashing rows are marked Ready to deploy, but the site does not say whether the plastic and light-assembly environment counts as deep or thin coverage, so ask which timeline applies when you request the quote. After the first batch, on-demand top-ups run against the same accept criteria, so you can add more parts or steps without rewriting the spec. The site does not state a turnaround for those later batches, so plan them in your quote.

Delivery is in the format your stack already reads: RLDS, LeRobot, WebDataset, HDF5, zarr or Rerun .rrd, or raw streams with metadata. Readable converter source ships alongside the data so the schema can be retargeted to your own loader. Collections are billed per validated hour.

The license is perpetual, irrevocable and worldwide, with the data buyer-owned and non-exclusive by default. Training, evaluating, fine-tuning and deploying models, including commercial ones, is permitted, and exclusivity is available as a separate term. The executed agreement controls. The site does not publish a price list, a minimum order or a batch size for this task, so those are set in your quote.

Where this site does not state something, this page says "not stated" rather than filling the gap. The table below separates what is delivered from what is not stated. There is no listed label for flash, burrs, edge quality or defects, no force or tactile stream, no tool or part specification, and no tolerance, cycle-time or certification claim. Nothing here claims a training outcome or a model improvement.

The tradeoff to plan for is the embodiment gap between a human hand holding a small part and working a cutter and a robot platform doing the same, which retargeting or pairing with robot data has to close. Counts of contributors, hours and parts are set in your skill spec.

Describe the parts, the tools, the setting and the variation or failure cases your pipeline is missing. That becomes a written skill spec, quoted for reach, timeline and price before any capture begins, and most programs run a Spec Pilot first. The scoping checklist below maps the parts of a skill spec onto a deflashing request. A published sample recording is on the sample data outputs page if you want to see the streams before you write a spec.

Three choices matter most for this task. Name each step rather than a broad activity, because that is what lets each step become one action segment. Name the setting and the capture tier, since the catalog lists a head-mounted phone or multiview rig for both rows. And name where the episode starts and stops: one part, a batch of parts or one step, since the site does not set an episode length.