Most robot data programs record video, joint positions, and gripper state, then stop. Force-torque sensor data collection gets deferred to phase two, because it costs money and the demonstrations look fine without it.
Then the team attempts an insertion task, or cloth folding, or anything involving a door, and discovers the dataset cannot support it. This guide explains what force data captures that cameras cannot, which tasks genuinely require it, and how to record it so it is usable.
What a force-torque sensor records
A six-axis force-torque sensor sits between the robot’s wrist and its gripper and reports three force components and three torque components. In plain terms: how hard the robot is pushing, in which direction, and how much it is twisting.
That is information no camera can give you. A video of a successful grasp and a video of a grasp that crushed the object look nearly identical. The force trace does not.
Why cameras cannot substitute
Vision infers contact from appearance: deformation, shadow, small displacements. On rigid objects there is often nothing visible to infer from. On deformable objects the visual change lags the force change by enough that a policy learns to react too late. Force is the only direct measurement of the thing that actually determines success.
Which tasks need it and which do not
| Task type | Force data | Reason |
|---|---|---|
| Free-space transport | Optional | No sustained contact to measure |
| Pick and place, rigid | Useful | Detects slip and over-grip early |
| Insertion and assembly | Essential | Alignment is felt long before it is seen |
| Deformable handling | Essential | Cloth and food deform silently under excess force |
| Surface tasks: wiping, sanding | Essential | Constant normal force is the whole task |
| Tool use | Essential | Tool contact forces define correct execution |
| Door and drawer opening | Essential | Constraint direction is discovered through force |
| Human handover | Essential | Release timing depends on the other party’s pull |
The pattern is simple: if a blindfolded human could do the task by feel, the robot needs force data. If they could not, vision may be enough.
The teleoperation problem nobody warns you about
Here is the awkward part. Most teleoperation rigs do not give the operator force feedback. The operator moves a leader arm, sees a screen, and feels nothing.
So the operator regulates force using visual cues alone. They over-grip because dropping is visible and crushing often is not. They push harder than necessary into surfaces because they cannot feel resistance. They release late.
All of that gets recorded as the demonstration. If you train imitation learning on it, the policy inherits every one of those habits. This is one of the least discussed sources of poor real-world performance in otherwise well-run programs, and it is why teleoperation data collection needs force instrumentation even when the operator cannot feel it.
Three ways to reduce the problem
- Show force visually. A simple on-screen bar or color change gives the operator a feedback channel. It is not haptics, but it measurably changes behavior within a session.
- Set force ceilings in the controller. Cap what the follower can apply. You lose some demonstration realism and gain a dataset without destructive outliers.
- Screen episodes on force, not just outcome. An episode that succeeded with a large force spike is a bad demonstration wearing a success label.
Recording it properly
- Sample fast. Contact events are short. Force sampled at video frame rate misses the transient that carries the information.
- Tare per session. Sensor bias drifts with temperature and mounting. An untared trace produces a systematic offset that looks like a real signal.
- Compensate for gravity and payload. A heavy gripper reads force at rest. Subtract it or your contact detection triggers on nothing.
- Store raw, not filtered. Filtering is a modeling decision that belongs downstream. Filtered-at-capture data cannot be unfiltered.
- Timestamp on the same clock as video. Sub-frame alignment is the entire value proposition here, per our log schema guidance.
- Log the sensor model and mounting. Traces are not comparable across hardware without it.
What you unlock once you have it
- Honest quality metrics. Peak force, force variance, and contact duration become per-episode scores, feeding directly into operator quality measurement.
- Automatic phase segmentation. Contact onset and release are visible in the trace, so grasp boundaries can be labeled without human review.
- Failure detection at collection time. A spike above threshold flags the episode immediately rather than during a review weeks later.
- Force-conditioned policies. Some tasks are only learnable when force is part of the observation, not just the evaluation.
- Better sim-to-real correspondence. Contact dynamics are where simulators diverge most, so real force traces are the calibration target. See sim-to-real transfer.
Deformable handling is where force data earns its cost. Our warehouse policy case study tracks success on deformable items from 61 to 84 percent.
Frequently asked questions
Can we use joint current instead of a dedicated sensor?
As a rough proxy, yes. Motor current correlates with load and costs nothing to log. It is noisy, conflates friction with contact, and cannot resolve direction. It is a reasonable starting point and a poor final answer for precision work.
Do tactile sensors replace force-torque sensors?
They complement rather than replace. Tactile skin gives you contact location and distribution across the fingertip; a wrist force-torque sensor gives you total wrench at the tool. Precision manipulation programs increasingly want both.
Is force data useful if our policy is vision-only?
Yes, as supervision and QA even when it never enters the observation space. Using it to filter and score episodes improves a vision-only policy without changing its architecture.
Does force data transfer between robots?
Better than joint-space actions, worse than images. Force is physical and therefore comparable in principle, but mounting, tooling, and payload differences mean it needs normalization before pooling across platforms.
Force-torque capture is the modality teams skip to save budget and then re-collect to recover. If you are specifying a rig for contact-rich work and want the sensor stack reviewed against your task list, tell us what you are building.
Related reading
- Multimodal sensor capture
- What is egocentric data collection?
- Industrial arms platform
- Sim-to-real transfer: measurement and benchmarks
- Case study: Warehouse policy: 61 to 84 percent on deformable items
External reference

Manish Jain · Chief Marketing Officer
Manish Jain is Chief Marketing Officer at Roborax, bringing over 20 years of experience in business strategy, digital transformation, and growth leadership to help enterprises build scalable, high-quality AI data operations.





