Short answer
Fixturing data shows how people orient a part, locate it against datums and seat it in a jig or fixture. Useful demonstrations need close views of the contact between part and fixture, labeled part orientation and a recorded outcome. Existing footage rarely frames that clearly, so most buyers combine station video with purpose-built recordings, and still need robot data for control.
Why fixturing is its own data problem
Almost every machining, welding, inspection and assembly cell has a loading step. A person picks up a part, turns it to the correct orientation and seats it in a fixture, often with a tolerance that leaves little room for visible error. Fixturing is where a robot's perception and placement accuracy meet the physical constraints of the cell.
The step is brief and visually subtle. A part can be a millimeter out of seat and look correct on video. Success is typically confirmed by a clamp closing, a sensor going true or a downstream operation succeeding, not by anything a ceiling camera shows. A buyer should specify the data around those confirmations. For a related task that includes the machine around the fixture, see machine tending.
Task anatomy
A fixture-loading episode usually runs through these steps. Treat them as a labeling scaffold and adjust to the cell:
- Acquire the part from a bin, tray, conveyor or the previous station; see parts presentation and identification.
- Identify orientation: find datum features, markings or asymmetries that tell which way the part goes.
- Transport and pre-orient it, sometimes with a regrasp.
- Locate and seat: align pins, edges or pockets, then push or tap into place.
- Confirm: visually, by feel, by sensor, or by closing the clamp.
- Clamp or latch and release.
- Recover from a misseat: remove, reorient, retry.
Objects range from castings and stampings to molded housings and sub-assemblies. Failure modes include loading backwards, partial seating, a part resting on a chip or burr, a dropped part and a clamp closing on a misaligned part.
What a visuomotor policy needs from demonstrations
Visuomotor policy learning from demonstrations is a common approach to precise manipulation. Diffusion Policy represents the policy as a conditional denoising diffusion process and reports a 46.9% average improvement over prior state of the art across 12 tasks from 4 benchmarks (Chi et al., 2023). That result concerns robot demonstration data in benchmark tasks, not business video, and it does not tell a buyer how much data a fixturing task needs.
The practical consequence is that policies of this type learn from observation-action pairs. Human fixturing video supplies the observation side only. To train a robot policy on the task, a team needs demonstrations in the robot's action space, produced by teleoperation, a handheld device or an instrumented rig; see action space and control frequency and human demonstrations vs teleoperated robot demonstrations. Station video from people can still support perception, step understanding and evaluation.
What the data can support
| Purpose | What helps | Weak spots |
|---|---|---|
| Part orientation recognition | Labeled views of parts in their orientations, including wrong ones | Needs variation in lighting and finish |
| Task and step understanding | Station video with step labels | Seating contact hidden by hands or fixture |
| Failure detection | Examples of misseats with outcome labels | Rare in routine footage |
| Placement outcome evaluation | Sensor or clamp signals joined to video | Requires logs and time alignment |
| Robot policy training | Teleoperated or handheld demonstrations | Must be commissioned |
What it cannot support
- Seating force. Pushing a part against locating pins involves force that video does not show. For tasks where feel matters, see snap-fit and press-fit assembly: when visual data falls short.
- Tolerance-level placement from video. Whether a part sits within tenths of a millimeter cannot be read from a conventional camera view.
- Fixture-specific knowledge in general. A fixture in one cell tells a model nothing about a different design.
- Control data. Human video has no robot actions or states.
Capture design
Purpose-built recording lets a buyer choose what the existing footage lacks. Useful choices include a close camera aimed at the part-to-fixture interface, a second view showing the whole operator posture, and a wrist or head camera for the operator's own sightline. Record part identifiers and orientation as labels, and record the confirmation signal (clamp state, proximity sensor or inspector note) with timestamps.
Plan the variety deliberately: several part variants, different starting positions in the bin or on the tray, varied lighting and several operators. Include deliberate misseats and recoveries, labeled as such. Calibration of cameras to the fixture frame lets a team express placement in fixture coordinates; see calibration requirements. Fixture drawings and CAD are often confidential; ask whether geometry can be shared or whether fixture markers must be added to the scene.
Illustrative fixturing demonstration package
# Illustrative only - synthetic values, not an available dataset
package: fixture_loading_v0
cell: cell_M04 (synthetic), fixture_F12, 3 part variants
episodes: 200 loads per variant (example size; buyer sets this)
video:
views: [interface_close_up, workstation_wide, head_mounted]
rate: 60 fps, constant, shared sync event at start of session
labels:
part_variant, orientation_label (correct / flipped / rotated)
step_segments: acquire / orient / seat / confirm / clamp
outcome: seated_first_try / retried / failed (with cause)
signals: clamp_state and proximity_sensor logs, timestamped
calibration: camera-to-fixture extrinsics per session
metadata: operator_id operator_A12 (pseudonymous), lighting_condition
excluded: robot actions, joint states, seating force
Limitations and additional preparation
Operators fixture so fluently that the critical moments are brief; at 30 frames per second a seating action may span only a handful of frames. Higher frame rates and close views are usually worth the extra storage. Occlusion by the operator's hands is the usual labeling obstacle, so view choice matters more than resolution. Annotator guidance should state how to label ambiguous orientations. Collecting at one cell also teaches little about other fixtures; see high-mix, low-volume assembly for the variety problem.
Permissions and provenance
Fixtures embody tooling investment, and part geometries may be customer property. Confirm who can authorize recording near customer-owned tooling and what the operators were told; see manufacturing data confidentiality and worker consent and identifiable people. This is not legal advice.
Questions to ask suppliers
- Which fixtures, part variants and orientations are covered, and how many loads per variant?
- Can a camera be placed to see the interface between part and fixture?
- Are misseats and recoveries recorded and labeled, or edited out?
- What signal confirms a good seat, and is it logged with timestamps?
- How are cameras calibrated to the fixture frame?
- Which operators appear, and how many hands-on hours does each contribute?
- Can fixture geometry be shared, or must it be masked or replaced?
- What frame rate and shutter settings are used?
- Can the supplier support a robot or handheld rig alongside human recording?
Discuss your requirements
If you are specifying fixturing data, describe the parts, fixtures, sensing and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. If no existing asset fits, SourceX can scope a commissioned collection of new recordings. A request does not guarantee a match. See the humanoid training data guide and the manufacturing hub.
Discuss your humanoid training-data requirements with SourceX
Sources
- Diffusion Policy: Visuomotor Policy Learning via Action Diffusion — Diffusion Policy: visuomotor policy as conditional denoising diffusion, 46.9% average improvement over 12 tasks from 4 benchmarks.