What data do robotics companies need from manufacturers?

What do robotics developers rank highest?#

Robotics developers rank real task data highest: what a person or machine did with hands or tools, whether it worked, what went wrong and why. The ranked list below runs from the scarcest input to the most common one.

The order of the ranked list reflects scarcity rather than importance alone. Context and outcome records are often what turn a new recording into training data, because a clip without a label or a task definition teaches very little.

• 1Task recordings: video, depth and, where available, force or position data of people or robots picking, kitting, assembling, tending machines or inspecting parts.
• 2Outcome labels: a pass, fail, defect or rework result tied to each task, so a model can tell good attempts from bad ones.
• 3Exception and recovery records: what happened when a part jammed, a fixture slipped or a pick failed, and what the operator did next.
• 4Process context: work instructions, routings, setup sheets, part families and tolerances that explain what the task was meant to achieve.
• 5Variation: different shifts, operators, part revisions, lighting and line layouts, so models learn more than one clean case.

What do plants already have?#

Plants already hold most of the context and outcome data that robotics developers need, even when they have no task video at all. The gap is usually the recording itself, not the records around it.

Why existing records matter even without video#

Existing plant records matter without video because robotics systems need more than motion data. Exception notes teach recovery behavior, outcome logs define success, and work instructions describe tasks in language that planning models and factory agents can use.

A downtime entry saying a feeder jammed on a warped part, the operator cleared it and set the part aside for inspection is a compact lesson in perception, judgment and procedure. A long run of such entries across shifts and products describes the messy middle of factory work that simulation struggles to reproduce.

Robotics teams also use these records to choose which tasks to automate first and to design test cases. A history of where people struggle is a fair map of where a robot will struggle too.

Which plants fit robotics requests best?#

Plants that fit robotics requests best run manual tasks that repeat often but vary in the details: different parts, packaging, orientations and conditions. High-mix work is useful because it shows a robot more than one clean case, while fully automated lines offer less human task data but useful machine logs.

Product ownership matters as much as task type. A plant that builds its own catalog items can usually say yes to more than a contract manufacturer whose stations handle customer designs all day.

• 1Manual kitting, packing and palletizing of mixed products.
• 2Machine tending, where operators load, unload and deburr parts.
• 3Manual assembly with fasteners, cables, hoses or connectors.
• 4Visual inspection and sorting with recorded accept or reject decisions.
• 5Material handling between work centers, including exceptions such as damaged packaging.

What it takes to record new task data on the floor#

Recording new task data on the floor is a separate project from licensing existing records, with its own consent, scope and customer checks. Agree it in writing before any camera or sensor goes up.

Labels and timing are the parts most often underestimated. A recording of a failed pick is only useful if someone records that it failed, why and what the operator did next, and if the clip can be matched by station and timestamp to the MES event, inspection result or downtime entry it belongs to. Plan who labels each session, and check that camera and MES clocks agree.

• 1Choose stations that handle the company's own products, not customer-owned parts or designs.
• 2Tell workers what is recorded, why and who will see it, and follow any collective bargaining obligations.
• 3Frame cameras on hands, tools and parts rather than faces where possible, and blur what remains.
• 4Keep screens, labels and drawings that reveal customer or supplier details out of view.
• 5Define labels in advance: what counts as success, failure and an exception for each task.
• 6Agree who owns the recordings, where they are stored and how long the buyer may use them.

Illustrative: an electronics assembler weighs a robotics request#

Illustrative: a fictional contract electronics assembler builds boards and box builds for industrial customers. Its MES records pass or fail at each test station, its rework technicians write short notes on every failed unit, and its work instructions include photos for each step. It has no task video.

A robotics developer asks about manual kitting and cable routing. The COO finds that rework notes link to test failures and stations, but most products are built to customer designs under confidentiality terms, and the work instruction photos show customer boards.

The company scopes rework and exception records for products where it owns the process documentation, removes customer board names and part numbers, and replaces operator names with station codes. It agrees to discuss a recording pilot only for an internal kitting station that handles its own packaging materials, with written worker notice in place before capture starts.

Which plant records should stay out#

Plant records that should stay out of a robotics package include customer-owned designs, export-controlled work, process recipes and setpoints, and any footage that identifies people without consent. These exclusions protect both the manufacturer and the buyer.

Recipes and setpoints deserve particular care because they often encode the know-how that keeps a plant competitive. Integrator code and robot programs written under a services contract may also belong to, or be shared with, the integrator. Employee privacy and biometric laws may apply to new capture, depending on the state and the type of recording; this is general information, not legal advice, and those rules are assessed deal by deal with counsel.

How SourceX approaches robotics data requests#

SourceX splits a robotics request into two tracks: existing plant records, which can be assessed now from metadata alone, and any new recording program, which is scoped separately with its own worker notice and buyer specification. Each track runs through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and the manufacturer approves every step.

Each package carries a SourceX Evidence Packet documenting provenance, licensing rights, permitted use, the privacy record and release authorization. For recordings, the privacy record notes what workers were told, how faces and screens were handled and which stations were filmed. Video and sensor archives stay in storage the manufacturer controls or travel on encrypted drives rather than being hosted by SourceX.