Short answer
Screw-driving stations and torque controllers log the outcome of each fastening, typically torque, angle and a pass or fail result per fastened joint. Aligned to station video, those logs supply ground-truth timing and outcome labels. They do not describe how a person positioned the tool or what a robot should command, so they complement video rather than replace robot data.
The buyer's problem
Fastening is a frequent assembly task, and its success can be defined in measurable terms: the fastener reached the specified torque, at an acceptable angle, without cross-threading. A camera generally cannot verify that; a tool controller can record it.
Many plants already collect this signal. Electric nutrunners and screwdriving systems report a result for every tightening, and the plant stores it for traceability. For a buyer, that creates an unusual opportunity: machine-recorded labels for human video that would otherwise need manual annotation. This page explains what those logs contain, what they can and cannot label, and how to ask for them. For the broader assembly picture, see assembly demonstration video.
What a fastening log usually contains
Field names depend on the controller vendor and the plant's system, so ask for a data dictionary. Typical records, to be confirmed, include:
- a timestamp for each tightening and a station or tool identifier;
- a unit or serial number and a fastener position within the assembly;
- final torque and final angle, with the target and tolerance window;
- an overall result (accepted or rejected) and a reason code for rejections;
- a program or strategy identifier, sometimes with a torque-versus-angle curve for the run.
A curve is much richer than a single final value. It can show seating, a stripped thread or a cross-threaded start. Check whether curves are stored or only summary values.
A terminology warning: "joint" in this context means the fastened joint, the connection between parts. It is unrelated to a robot's joint states. Torque in these logs is the tool's tightening torque, not a robot's commanded joint torque.
What the logs can support
| Use | Why the logs help | What they do not provide |
|---|---|---|
| Outcome labels for video | Each tightening has a machine result and time | Hand pose, tool approach, regrips |
| Step segmentation | Tightening events mark step boundaries | Everything between tightenings |
| Success and failure classification | Rejected runs flag failures with reason codes | Why the person made the error |
| Progress and cycle timing | Timestamps give cycle structure | Robot-feasible timing |
| Evaluation ground truth | Objective pass/fail independent of human judgment | A held-out split by itself |
The strongest use is as ground truth for footage: a rejected tightening at 10:42:07 tells an annotator exactly which clip to look at. Operational systems supplying timing, outcomes and labels for visual data is a general pattern; other examples are MES records aligned to video and the error-proofing records that plants keep to catch missed fasteners.
What the logs cannot support
- Visual data on its own. A torque file contains no images. A buyer who needs perception or demonstration data must also source video.
- Robot actions. Tool logs hold no robot joint positions, end-effector commands or gripper states. Human video of fastening provides no robot actions either; see what human demonstration video can and cannot do.
- Approach and alignment. How the operator found the hole, started the thread and corrected a misalignment happens before the tool reports anything.
- Force in the hand. The torque at the tool is reported; the grip, push and posture forces of the operator are not. Contact-rich insertion work needs instrumented capture; see force-torque data. RH20T, for example, recorded force alongside video for more than 110,000 contact-rich sequences (Fang et al., 2023).
Time alignment is the hard part
Controller clocks, camera clocks and plant servers rarely agree. Joining the logs to video requires known offsets or a shared sync event. Ask whether the controller's timestamps come from a network time source and how the camera recorded its own time. A fixed offset can be estimated by matching a few visible tightenings to log events, but a drifting clock cannot be fixed with a single offset. See sensor synchronization requirements.
Join keys matter equally. If the log carries a serial number and the video file carries only a station and a time, the join depends entirely on timestamp accuracy.
Illustrative package: torque logs joined to station video
# Illustrative only - synthetic values, not an available dataset
package: fastening_logs_with_video_v0
station: station_C02 (synthetic)
logs:
format: csv per shift
fields: ts_utc, tool_id, serial_ref, position_id, torque_final, angle_final,
target_torque, tol_low, tol_high, result, reason_code, program_id
curves: optional per-run torque/angle series (stated if absent)
video:
views: [overhead_fixed, tool_close_up], 30 fps constant
alignment:
clock_source: ntp_synced (declared per device)
verified_offset_ms: measured from 20 visible tightenings, reported per shift
joins: serial_ref pseudonymized; position_id mapped to part drawing region
privacy: operator login IDs removed; serials hashed
excluded: robot actions, joint states, hand forces
Limitations and additional preparation
- Plant context. Torque targets and fastener specifications can reveal product designs and customer requirements. See manufacturing data confidentiality.
- Identifiers. Operator logins, serial numbers and customer order references may be embedded in log rows and need removal or pseudonymization before delivery.
- Selection effects. Logs include every tightening, but video may cover only part of a shift. Confirm which log rows have footage.
- Automated stations. If tightening is done by a fixed automatic machine rather than a person, the footage shows a machine cycle, not human manipulation.
- Dataset use. Treat logs as labels for human video, and as one input to evaluation design; keep training and evaluation data separate.
Permissions and provenance
Employee identifiers inside log rows can make otherwise technical data personal. Customer-specified torque values may be confidential contractual information. Confirm who owns the controller data and whether tool vendors hold any rights through software or cloud services. This is not legal advice.
Choosing between log-first and video-first sourcing
If your goal is labeled video for fastening steps, start from the logs: ask which stations have both controllers and cameras, then select periods where rejected tightenings occurred, so failures are represented. If your goal is perception for tool and fastener handling, start from video and treat logs as optional ground truth. If you plan to evaluate a policy on fastening, logs can serve as an objective outcome check, provided the evaluation runs on a station that reports the same fields. Whichever route you choose, ask whether the fastener type, tool model and program match the task you intend to cover, because a log for a small electronics screw says little about a large structural bolt.
Questions to ask suppliers
- Which controller models and software versions produced the logs, and is there a data dictionary?
- Are torque-angle curves stored, or only final values?
- Is each tightening linked to a serial number and a fastener position?
- How long is log history retained, and does footage exist for the same periods?
- How are controller and camera clocks synchronized, and what offset has been measured?
- Do the records include operator identifiers, and can they be removed?
- What share of rejected tightenings has matching video?
- Are rework tightenings and re-runs flagged as such?
- Which torque targets or part numbers are restricted by customers?
Discuss your requirements
If you need fastening video with machine-logged outcomes, describe the station types, signals 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. A request does not guarantee a match; SourceX follows up about potential sources. Start from the humanoid training data guide or the manufacturing hub.
Discuss your humanoid training-data requirements with SourceX
Sources
- RH20T: A Comprehensive Robotic Dataset for Learning Diverse Skills in One-Shot — RH20T recorded force with video for 110k+ contact-rich sequences.