Short answer
Programs and logs from fixed industrial robots record real robot observations, exceptions and failures in production, but they describe a different body: a base-mounted arm with fixed waypoints, not a mobile humanoid. They are most useful for exception and failure analysis, task structure and perception of cell conditions, and least useful as humanoid action data. Vendor terms and site rights often restrict their release.
The buyer's problem
Plants with robot cells hold years of machine records. A buyer building a humanoid training set reasonably asks whether those records are robot data in the sense that matters: observations paired with actions, from real work. The honest answer is partial. The records are real and robot-generated, which makes them rare among business assets. They also come from machines whose kinematics, control style and purpose differ sharply from a humanoid's.
This page helps you decide whether to pursue them, which parts to ask for, and what must be added before they carry any weight in a humanoid program.
What exists in a robot cell
| Artifact | Typical content | Use to a humanoid program |
|---|---|---|
| Teach-pendant program | Ordered waypoints, motion types, I/O calls, speeds | Task structure and sequencing; not learned motion |
| Joint or tool trajectories logged at runtime | Time-stamped joint angles or poses | Fixed-arm motion examples; weak transfer to a different body |
| Digital I/O and sensor events | Gripper open/close, part-present sensors, safety inputs | Success and exception signals |
| Alarm and fault logs | Fault codes, timestamps, recovery steps | Failure taxonomies and recovery sequences |
| Cycle and production counters | Units, cycle times, downtime | Workflow statistics, context |
| Vision-system outputs | Part poses, pass/fail from cell cameras | Perception labels, if images are kept |
| Cell layout and tooling files | Positions, tool definitions, fixtures | Workspace geometry; see workcell layouts |
Programs are typically written by technicians, not recorded from demonstrations. A waypoint list shows what a person decided the arm should do, which is closer to a procedure than to a learned skill.
Why fixed-arm data transfers weakly to humanoids
A fixed industrial arm has a known base, rigid links, high repeatability and a single end effector. A humanoid has two arms, hands, a torso and legs, balance constraints and a head-mounted sensor set. Joint-space trajectories from one do not map to the other without an embodiment bridge. Robot description formats show the gap in practice: URDF describes a robot as rigid links connected by joints in a tree structure, and cannot represent parallel mechanisms (ROS URDF). An arm and a humanoid therefore have separate descriptions with different joint sets, and mapping a trajectory from one to the other is retargeting work, not a format conversion.
Cross-embodiment learning is an active research area. The Open X-Embodiment collaboration pooled data from 22 robot embodiments, over a million trajectories in total, and its RT-X models showed positive transfer across robot platforms (Open X-Embodiment Collaboration, 2023). Fixed arms are not excluded from cross-embodiment learning in principle, so the limit is not that the data comes from an arm. That result concerns data collected and standardized for research, with matching observation and action conventions. Plant program archives rarely arrive in that form, and a published pooling result is not evidence that arbitrary cell logs will help your model. See the embodiment gap for the underlying problem.
What the data can support
- Exception and failure analysis. Cell logs show what goes wrong in real production and how operators recover. That informs failure taxonomies and evaluation design.
- Task decomposition. Program structure shows how experts break a task into steps, grasp points and checks.
- Perception data. If the cell camera images were retained, they show parts under real lighting and presentation.
- Workspace and fixture geometry. Tool and fixture definitions give dimensions for simulation.
- Baselines. Cycle times and success rates give a human-designed reference for what a new system must match.
What it cannot support
- Humanoid-specific actions, unless the robot in the cell is a humanoid. Fixed-arm joint data is not humanoid control data.
- Learned manipulation behavior. Scripted waypoints encode no sensing-based reactions unless the program includes vision or force logic.
- Contact forces, unless the controller logged torque or force-sensor data. Check what channels exist.
- Variety. Many cells run one task repeatedly, so breadth is often low.
- Evaluation independence. Held-out sets still need separation by cell, shift or time.
Where it fits in a sourcing plan
Use cell data to build failure and exception understanding and to inform scoping, then source motion data differently. For motion, buyers typically look at human demonstrations compared with teleoperated robot demonstrations, where the robot body is the right one. For tasks that mix a robot with a person, see also machine tending and torque controller data, which cover specific signals that cells often log.
Preparation work
- Extract logs from controllers in documented export formats, with timestamps and clock sources.
- Obtain vendor permission where controller software or file formats are licensed.
- Convert to an open format. Multichannel log containers such as MCAP, ROS bags or Parquet are common choices; whichever you choose, document message types and units.
- Add context: cell layout, tool definitions, part variants, program version.
- Remove site-identifying and personal data, such as operator IDs in login records.
- Decide on retention of any cell camera video; it adds the privacy questions covered in process-monitoring camera footage.
Illustrative export manifest
# Illustrative only - synthetic values
export: cell_log_export_v0
cell: cell_012 (single six-axis arm, fixed base)
period: "12 months"
channels:
joint_state: "250 Hz, radians, controller clock"
tool_pose: "derived, not logged directly"
gripper_io: "event-based"
fault_codes: "event-based, vendor code table attached"
camera: "cell vision still images on pass/fail only"
programs: ["prog_A_rev4.src", "prog_A_rev5.src"]
excluded: ["operator_login", "vendor_licensed_firmware"]
rights_notes: "robot vendor terms under review; site data owned by operator"
Pairing logs with downtime records
Fault codes mean more when joined to what the plant recorded around them. Stoppage reasons, operator interventions and restart times often sit in separate systems; see andon and downtime logs. A cell fault with a matching downtime entry and a free-text note gives you a labeled exception with cause and recovery, which is far richer than a bare code.
Check that clocks agree between controller and plant systems before relying on joins. Offsets of seconds are common and can scramble event order.
Questions to ask suppliers
- What robot make and model produced the data, and is it a humanoid, an arm or a mobile manipulator?
- Which channels were logged, at what rate, and from which clock?
- Are program files the original source or exported listings, and which revisions are included?
- Do logs include fault events with recovery steps, and are the code tables documented?
- Was any camera or force sensor data kept, and under what retention?
- Does the robot vendor's agreement restrict exporting logs, programs or firmware-derived data?
- Do the logs include operator names, shift data or customer part information, and how will it be removed?
- Can you tie log events to production outcomes such as scrap or rework?
Rights questions here are significant: vendor terms, site data and customer parts can all apply. This is not legal advice.
Discuss your requirements
If you want to learn whether US manufacturers hold robot logs or programs that fit your plan, describe the robot type, channels and permitted uses to SourceX. SourceX looks for US businesses that hold the data you describe, checks the data and the supplier's licensing permissions, and coordinates license and delivery. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match. For more context, see the manufacturing data hub or the humanoid training data guide.
Discuss your humanoid training-data requirements with SourceX
Sources
- Open X-Embodiment: Robotic Learning Datasets and RT-X Models — pooled multi-embodiment data and positive transfer across robot platforms.
- URDF (Unified Robot Description Format) — rigid-link tree description of a robot, with no parallel mechanisms.