Force/Torque Sensing for Robots: The Ultimate Guide

A position-controlled robot is a bulldozer with a spreadsheet. Tell it to move to a point and it goes there, and if a wall, a fixture, or a human hand is in the way, it pushes with whatever force the motors and gears can deliver until something yields. That is fine for a spot welder tracing air, and it is a disaster the moment the task is contact: seating a bearing, threading a fastener, polishing a curved surface, or handing a part to a person. Contact tasks are governed by force, and a robot that cannot measure force is guessing.

This guide is about the sensors that let a robot feel what it is touching: the six-axis force/torque (F/T) sensor at the wrist, the torque sensors and current-based estimators inside each joint, and the series-elastic actuators that turn a spring into a torque gauge. We will work through the strain-gauge and capacitive transduction physics, the calibration matrix that makes a raw bridge signal into a clean wrench, the specs that actually decide whether a sensor works in your loop (crosstalk, overload, drift, bandwidth, not the headline full-scale number), and how to mount, calibrate, and select one. Tactile skin and whole-hand sensing get their own treatment in the tactile sensing guide; here the subject is the net wrench and the joint torque, the signals that close a force-control loop.

The take: force sensing is what turns a robot from a machine that follows a path into a machine that negotiates with the world. The transducer is the easy part. The hard part is the calibration matrix, the temperature and zero drift that move your baseline by newtons over minutes, the crosstalk that leaks one axis into another, and the bandwidth and latency budget that decide whether your force loop is stable or rings itself apart. Get those right and a robot can find a hole it cannot see; get them wrong and no control law rescues a sensor that lies about what it feels.

Companion reading: robot sensors, end-effectors & grippers, collaborative robots (cobots), robot teleoperation, and real-time control systems.

Table of contents

1. Key takeaways
2. Why force control needs a force sensor
3. The six-axis wrist sensor: what a wrench is
4. Strain-gauge transduction and the Wheatstone bridge
5. The calibration matrix and crosstalk
6. Capacitive and other transduction families
7. Joint torque sensing: three ways to know a joint's torque
8. The specs that actually bite, and reading a datasheet
9. Wrist mounting, tool bias, and gravity compensation
10. Bandwidth, latency, and force-loop stability
11. Calibration, drift, and temperature
12. Applications: assembly, finishing, collision, teleop haptics
13. Selecting a force/torque sensor
14. Frequently asked questions

Why force control needs a force sensor

Consider a peg-in-hole insertion with a 20 micron clearance, the canonical hard assembly task. Your robot's absolute positioning accuracy is, optimistically, a few hundred microns. The peg and hole are misaligned by more than the clearance every single time. Under pure position control the peg jams against the chamfer and the robot, blind to the contact, keeps commanding the programmed trajectory and drives the peg (or the part, or the gripper) until something breaks.

The way a human does this task is by feel: push gently down, feel the sideways reaction force from the chamfer, slide in the direction that reduces it, and let the geometry guide the peg home. That strategy needs a measurement of the contact force, updated fast enough to steer by. This is force control, and it is the reason force sensing exists.

The same logic covers every contact task. Polishing and deburring need a controlled normal force against a surface whose exact position you do not know, so you regulate force and let position float. Handing a part to a person or working alongside one needs collision detection: notice the unexpected force and stop or retreat before it becomes an injury. Teleoperation with a feel of the remote environment needs the force measured at the robot and reflected back to the operator's hand. Every one of these is a force measurement feeding a control law.

Rule of thumb: if a task is defined by where the tool goes, use position control and skip the force sensor. If it is defined by how hard the tool pushes, or by a contact you cannot predict, you need force sensing. Most real assembly and finishing is the second kind, which is why the sensor keeps paying for itself.

There are two places to measure that force. At the wrist, a six-axis sensor gives you the full contact wrench at the tool, accurately, in one clean frame. At the joints, torque sensing (real or current-estimated) gives you a distributed picture: you can localize where along the arm a contact happened, which is what makes whole-arm collision detection possible. Good robots use both. The wrist sensor is the surgeon's fingertip; joint torque is the sense of your whole arm being bumped in the dark.

The six-axis wrist sensor: what a wrench is

A rigid body in contact experiences a wrench: a force vector and a torque (moment) vector, six numbers total. The force (Fx, Fy, Fz) is the net push; the torque (Tx, Ty, Tz) is the net twist about the sensor origin. Together they fully describe the mechanical interaction at a point, which is why a six-axis sensor is the complete contact instrument and a single-axis load cell is not.

The torque components carry a subtlety that trips people up: a torque reading depends on where you measure it. A pure force applied off-axis produces a moment T = r x F about the sensor origin, where r is the vector from the origin to the line of action. So the sensor's Tx, Ty, Tz change if you move the reference point, even though the physical contact did not. This is why datasheets specify a reference frame with a defined origin (often the mounting face or a point a stated distance out along the axis), and why you must transform the wrench to your tool tip before you reason about the contact there. The transform is standard rigid-body mechanics: F is unchanged, and T_new = T_old + (r x F) for the offset r between frames.

The frame convention matters in practice because a contact at the tool tip, several centimetres past the sensor, shows up as a large moment at the sensor even for a modest force. That moment is real information (it tells you the force is off-axis), and it is also what loads the sensor's torque axes hardest. A 50 N side force on a tool 150 mm long is a 7.5 N.m moment at the wrist, which can be a bigger fraction of the torque range than the 50 N is of the force range. Sizing a sensor means thinking about the moment arm as much as the force.

Strain-gauge transduction and the Wheatstone bridge

The dominant transduction method, and the one behind ATI, Schunk, Bota, and most industrial F/T sensors, is the bonded foil strain gauge on a precisely machined elastic element. The element is usually a spoked hub, a "Maltese cross" or a set of flexure beams, designed so that each of the six wrench components strains the metal in a distinguishable pattern.

A metal-foil strain gauge is a serpentine conductor bonded to the surface. Stretch the surface and the foil lengthens and thins, raising its resistance:

Gauge response:   dR/R = GF * epsilon

  GF       = gauge factor, ~2.0 for foil gauges
  epsilon  = mechanical strain (dimensionless, length/length)

The strains involved are minuscule. A well-designed element sees a few hundred microstrain at full scale, so epsilon is around 3e-4 and dR/R is around 6e-4. Measuring a 0.06% resistance change on a 350 ohm gauge, in the presence of temperature swings that change the same resistance by far more, is why you never read a gauge directly. You wire it into a Wheatstone bridge.

A bridge is four resistors in a diamond, excited across one diagonal and measured across the other. When the four arms are balanced the output is zero, and the bridge reports only the difference driven by strain, rejecting the huge common-mode resistance and its temperature drift:

Full-bridge output (four active gauges):
  V_out / V_ex = GF * epsilon

  V_ex   = excitation voltage
  two gauges in tension, two in compression

A quarter-bridge (one active gauge) gives a quarter of that signal and no temperature cancellation. A full bridge with four active gauges, two stretched and two compressed by the same load, quadruples the signal and cancels first-order thermal expansion, because a uniform temperature change moves all four arms together and the bridge sees no difference. Good sensors use full bridges for exactly this reason. Even so, the raw output is small: with V_ex of 5 V and full-scale strain, the bridge swings a few millivolts, which is why the analog front end (a low-noise instrumentation amplifier, often ratiometric to the excitation so supply drift cancels) is as much of the sensor's quality as the metal.

Each of the six axes gets its own bridge (or a set of gauges combined into one), and the machined element is shaped so a force along Z strains the Z bridge strongly and the others weakly. "Weakly" is the operative word: no flexure isolates one axis perfectly, which brings us to the calibration matrix.

The calibration matrix and crosstalk

Here is the fact that makes an F/T sensor a system rather than six independent gauges. Every bridge responds to a mixture of all six wrench components. Push straight down on Z and the Fx and Tx bridges twitch too, because the flexure that bends under Z also bends, a little, under everything else. So the raw output is a six-vector of bridge voltages v, and the true wrench is recovered by a linear map:

Wrench from raw bridges:   w = C * v

  w = [Fx Fy Fz Tx Ty Tz]^T   (the physical wrench)
  v = [v1 v2 v3 v4 v5 v6]^T    (six bridge voltages)
  C = 6x6 calibration matrix

The manufacturer fits C by loading the sensor with dozens of known forces and torques on a calibration rig and solving a least-squares problem for the matrix that best maps voltages to loads. The diagonal terms of C are the main sensitivities; the off-diagonal terms are what subtract the cross-coupling out, decoupling the axes. This is why two identical-looking sensors are not interchangeable: each has its own C matrix from its own machining and gauge-bonding tolerances, stored in a serial-matched calibration file. Load the wrong file and every reading is quietly, smoothly wrong.

Crosstalk (cross-axis coupling) is the residual that a single linear C cannot remove: the part of the coupling that is nonlinear, hysteretic, or temperature-dependent. It is quoted as a percentage of full scale, typically 1% to 5%, and it means a pure Fz of full-scale magnitude shows up as a spurious Fx or Tx of a few percent of their full scale. Crosstalk is why you cannot cleanly resolve a small force on one axis while a large load sits on another. If you are trying to sense a 2 N contact on Fx while carrying a 100 N tool weight on Fz, and crosstalk is 2%, the tool weight alone leaks 2 N into your Fx channel, swamping the signal you care about. This is a real limit on delicate multi-axis tasks, and no amount of averaging removes it, because averaging only smooths random noise while crosstalk is deterministic coupling.

Rule of thumb: the calibration matrix is the sensor. Never mix a body and a calibration file from different serial numbers, always transform the wrench into your tool frame before interpreting it, and remember that the crosstalk spec (more than the noise spec) sets how finely you can resolve one axis while another is loaded.

Capacitive and other transduction families

Strain gauges are the classic method, and other transductions turn deflection into a signal too. The main alternative in modern robot F/T sensors is capacitive sensing, used by Robotiq (the FT 300 line) and a growing share of cobot-targeted designs.

A capacitive sensor measures the deflection of the elastic element by the change in capacitance between plates that move relative to each other as the element flexes: C = epsilon_0 * epsilon_r * A / d, so a change in plate spacing d or overlap area A changes the capacitance, which a chip reads out. The advantages are practical. Capacitive readout integrates cleanly into a single ASIC alongside the signal conditioning, so the sensor ships with digital output (EtherCAT, CAN, USB) and on-board compensation rather than raw analog bridges you must amplify yourself. Capacitive designs often have excellent noise performance and low power. Some integrated sensors put an IMU on the same board so you get acceleration alongside force, which helps with inertial compensation of the tool.

The trade-offs: capacitive sensing is more susceptible to electromagnetic interference and needs careful guarding, and the temperature behaviour of the dielectric and geometry must be compensated in firmware. Done well, a modern capacitive sensor matches or beats strain-gauge units on drift and noise; done cheaply, it drifts.

Piezoelectric F/T sensors (Kistler) generate charge under load, giving enormous stiffness and bandwidth (into the kHz), which suits fast dynamic forces such as machining cuts or impacts. Their weakness is that charge leaks, so they cannot hold a static load reading: a piezoelectric sensor tells you a force changed and cannot confirm that a constant force is present. That rules them out for the slow, sustained contact of assembly, where strain-gauge and capacitive sensors dominate.

Joint torque sensing: three ways to know a joint's torque

The wrist sensor gives you the net wrench at the tool. Inside the arm, torque sensing at each joint gives a distributed picture: whole-arm collision detection, gravity compensation, and joint-level compliance. There are three ways to get it, and the choice defines a robot's cost and capability.

Option A: true joint torque sensors

Put a strain-gauge transducer in the joint's torque path, on the output side after the gearbox. This directly measures the torque the joint delivers, immune to the friction and gear losses upstream of it. This is what high-end torque-controlled robots do: the Franka Research 3 has a torque sensor in every one of its seven joints, and the KUKA LBR iiwa does the same. That is what gives those arms their exquisite whole-body compliance and sensitivity. The cost is real: a torque sensor per joint adds expense, wiring, and calibration burden at every axis, and it demands a compact, stiff, high-resolution strain element that survives the joint's full load.

Option B: current-based torque estimation

Most cobots and many quadrupeds skip per-joint torque sensors and infer torque from motor current. In a permanent-magnet motor under field-oriented control, torque is proportional to the torque-producing (q-axis) current:

Motor torque:   tau_motor = Kt * Iq

Joint output torque:
  tau_joint = Kt * Iq * N * eta - tau_friction

  Kt  = torque constant [N.m/A]
  Iq  = q-axis current [A]
  N   = gear ratio
  eta = gearbox efficiency (~0.6-0.9 for harmonic/cycloidal)
  tau_friction = Coulomb + viscous + Stribeck friction

The motor controller already measures Iq precisely to run FOC (see the motor controllers & FOC guide), so the torque estimate is free: no extra sensor, no extra wiring, full motor bandwidth. This is why a Universal Robots arm or a Unitree quadruped can be force-aware and collision-sensitive without a single dedicated torque sensor. It is the trick that makes cobots affordable.

The catch is accuracy, and every term leaks error. Friction dominates and is nastier than "Coulomb plus viscous" suggests: real joint friction follows a Stribeck curve (high static breakaway friction, a dip as motion starts, then rising viscous friction), has memory near zero velocity, and changes with temperature, so a cold robot and a warm one estimate different torques from the same current. Gear efficiency eta is a function of load, speed, and temperature, and it drops sharply at low load, exactly where you want fine control. Kt drifts with temperature because it scales with magnet remanence, and NdFeB loses roughly 0.1%/degC of flux, so a 60 degC winding rise is a ~6% torque error unless you compensate. The upshot: current-based torque is excellent for collision detection and gross compliance (hand-guiding, gravity compensation, stopping when bumped) and mediocre for precise force control, because the friction floor typically sits at several percent of the joint's rating and a quieter current sensor does not lower it.

Option C: series-elastic actuators

The third path deliberately inserts a calibrated spring between the gearbox and the load, then measures the spring's deflection to compute torque by Hooke's law:

SEA torque:   tau = k * delta_theta

  k           = spring stiffness [N.m/rad]
  delta_theta = measured deflection across the spring [rad]

This turns torque sensing into position sensing, which is cheap, robust, and high-resolution: a soft spring gives a large, easily-measured deflection for a given torque, so the encoder resolves torque finely. The spring also decouples the motor's reflected inertia from shocks, so an impact does not slam straight into the gear teeth. Introduced by Pratt and Williamson (IROS 1995), SEAs show up on legged robots (see the legged/quadruped guide) and some collaborative designs. The cost is a bandwidth ceiling: the actuator's large-force bandwidth scales as sqrt(k / m_motor) for the reflected motor mass, so softening the spring for better torque resolution lowers your force bandwidth. You are trading force fidelity against force bandwidth, the same tension that runs through every compliant sensing scheme.

Rule of thumb: current estimation is "good enough to be safe and compliant, not good enough to thread a needle." Add a wrist F/T sensor for fine force at the tool, pay for joint torque sensors for fine torque at every axis, and reach for SEAs when you need physical shock tolerance and torque resolution together.

The specs that actually bite, and reading a datasheet

The headline number on an F/T sensor is full-scale range (say plus/minus 200 N, plus/minus 10 N.m). It is rarely what limits you. The specs that cause real grief in the field are these:

Spec	What it means	Why it bites
Crosstalk	A pure load on one axis reads as spurious load on another	Limits resolving a small force on one axis under load on another; typically 1-5% FS
Overload rating	Force beyond which the element yields or breaks	A crash can hit 5-10x full scale; the sensor must survive it. Quoted per axis (e.g. 5x Fz)
Zero / thermal drift	Output shift with temperature and warm-up	Motor and ambient heat shift the zero by newtons over minutes; re-bias before force tasks
Resolution	Smallest resolvable force/torque	Pick the range that puts resolution where your task force lives
Stiffness / bandwidth	Element stiffness and mechanical resonance	A stiff sensor preserves position accuracy and raises the usable force-loop bandwidth
Noise	Output noise at rest, RMS	Sets the smallest contact force you can reliably detect
Signal-to-noise vs range	Resolution as a fraction of full scale	An over-ranged sensor wastes bits; the useful figure is counts at your task force

Two traps in reading these. First, resolution and full-scale are quoted separately and often single-axis, at 25 degC, "typical." The number that matters is resolution at your actual task force with the other axes loaded as they will be in service, over your temperature range. Second, percent-of-full-scale hides absolute error: "1% FS" on a plus/minus 500 N sensor is plus/minus 5 N, which may be larger than the entire force you are trying to control. Always convert the percentage to newtons at your working point before you trust it.

Rule of thumb: size for resolution at your task force, then check that the overload rating survives your worst-case collision. A plus/minus 500 N sensor used for 5 N assembly forces wastes its resolution; a plus/minus 10 N sensor that breaks on a 60 N crash wastes the sensor. The right choice usually leaves your task force in the upper half of the range with overload headroom of 5x or more.

Representative products, with nominal figures (confirm against the current datasheet, variants differ widely):

Sensor	Type	Typical range (Fxy / Fz / Txyz)	Interface	Notes
ATI Nano17	Strain gauge	~50 / 70 N / 0.5 N.m	Analog + DAQ	17 mm, fingertip-scale, very high resolution
ATI Gamma	Strain gauge	~130 / 400 N / 10 N.m	Analog / EtherCAT	Industrial arm-wrist workhorse
ATI Axia80	Strain gauge (silicon)	~200-500 N / 5-20 N.m	EtherCAT / others	Integrated electronics, cobot-friendly
Robotiq FT 300-S	Capacitive	~300 N / 30 N.m	USB / plug-and-play	Native UR integration
Bota Rokubi / MiniONE	Strain gauge, on-board IMU	~200-500 N / 5-20 N.m	EtherCAT / CAN / USB	Integrated IMU, low drift
OnRobot HEX-E / HEX-H	Optical	~200 / 400 N	Cobot toolside	Optical sensing, impact-robust
Schunk FTN / FTA	Strain gauge	wide range	Various	Robust industrial line
Kistler piezo	Piezoelectric	very wide, high stiffness	Charge amp	Dynamic forces only, no static hold

Wrist mounting, tool bias, and gravity compensation

The sensor mounts between the robot flange and the tool, so everything distal to it (the gripper, the tool, the grasped part) sits on the sensor. That means the sensor reads the tool's own weight and inertia before it reads any contact. The first job of the software is to subtract those, or you will "detect" a 30 N contact that is really just the gripper hanging off the wrist.

Static gravity compensation subtracts the tool's weight wrench. The tool has a mass m and a centre of mass at some offset from the sensor. Its weight is a constant mg in the world frame pointing down, but the sensor rotates with the wrist, so in the sensor frame that weight wrench swings around as the arm moves. You compute it from the known joint angles: rotate the world gravity vector into the sensor frame and apply it at the centre-of-mass offset to get force and moment. Subtract that model from the raw reading and what remains is contact.

The catch is that you need the payload's mass and centre-of-mass offset accurately. A few percent error in m, or a centimetre error in the CoM offset, leaves a residual wrench that swings as the wrist rotates, which looks exactly like a phantom contact that appears and disappears with pose. The standard fix is a payload identification routine: move the wrist through several known orientations, record the sensor wrench at each, and solve for the mass, CoM, and a constant bias offset that best explain the data. UR, Franka, and most cobot stacks ship this as a calibration wizard. Run it whenever the tool changes.

Inertial compensation matters when the arm accelerates. The tool's mass resists acceleration, so a fast move produces a reaction force F = m*a at the sensor that has nothing to do with contact. At low speeds this is negligible; on a fast, heavy payload it is not, and this is where a sensor with a built-in IMU (or a good model of the commanded acceleration) earns its price, because it lets you subtract the inertial term and see contact during motion. Without it, you either move slowly during force tasks or accept that fast moves blind your force sense.

War story: an integrator swore a new F/T sensor was defective because it read a wandering 15 N force that changed every time the arm reoriented, even with nothing touching the tool. The sensor was fine. The tool-payload mass in the gravity-compensation config was left at a default, off by 40%, so the uncompensated fraction of the gripper's weight rotated through the sensor frame as the wrist moved. Running the payload identification wizard, which took ninety seconds, zeroed it. The lesson: a "drifting" force that correlates with pose is almost always a gravity-compensation error, and a "drifting" force that correlates with time is almost always thermal.

Bandwidth, latency, and force-loop stability

A force sensor lives inside a control loop, and force loops have a stability problem that position loops do not. When a robot pushes against a stiff environment, the loop gain runs through the contact stiffness, which can be enormous (steel on steel is tens of MN/m). High environment stiffness plus any delay in the loop, from sensor filtering, communication latency, or a slow control rate, drives the classic contact instability: the robot bounces off the surface, overshoots, slams back, and chatters. Anyone who has watched a force-controlled robot buzz against a hard fixture has seen it.

The physics is that a discrete-time force loop against a stiff contact has a stability limit set by the product of environment stiffness, loop delay, and sample period. Push the loop rate up and the delay down and the stable stiffness range grows. This is why force control wants a high control rate (500 Hz to 1 kHz and up), a stiff sensor (so the sensed force tracks the real contact without the sensor itself acting as a soft, laggy spring), and low latency in the sensor-to-controller path. A sensor that filters its output heavily to look quiet on the datasheet adds phase lag that eats your stability margin. The useful sensor specs here are the bandwidth at which the sensor reports force faithfully and the latency of its digital output, which matter as much as the noise figure.

Three practical consequences. First, prefer a sensor whose bandwidth comfortably exceeds your control rate, so the sensor is not the bottleneck. Second, favour deterministic, low-latency interfaces (EtherCAT, direct analog into your controller's ADC) over a sensor that streams over USB with variable latency, if you are closing a fast loop. Third, when the environment is stiff and instability threatens, switch control strategy: admittance control (measure force, command a compliant motion) and impedance control trade some force-tracking bandwidth for robustness, and a deliberately compliant tool or a soft cover on the contact lowers the effective environment stiffness so the loop stays stable. The general lesson from impedance control theory (Hogan, 1985) is that you cannot make a robot arbitrarily stiff and arbitrarily responsive against a stiff world; you choose where on that trade-off to sit. See the real-time control guide for the loop-timing side.

Rule of thumb: force-loop instability against a hard surface is a bandwidth-and-delay problem. Turning the P gain down does not fix it. Raise the loop rate, cut the latency, use a stiffer sensor, or soften the contact. If you cannot do those, move to admittance/impedance control and accept slower force tracking.

Calibration, drift, and temperature

An F/T sensor's accuracy erodes through three mechanisms, and each has a countermeasure.

Zero drift is the baseline wandering with no load applied. It comes from temperature (the element and gauges change with heat), from warm-up (the sensor's own electronics settle over the first minutes after power-on), and from long-term aging of the bond and metal. In practice the dominant term is thermal, and the dominant heat source is often the robot's own motors and the gripper's actuators warming the wrist. The standard defence is to re-bias (re-zero) the sensor with the tool unloaded immediately before a force task, so any accumulated drift is subtracted at a known reference. Cheap sensors need this often; a good sensor with on-board temperature compensation holds zero far longer, but none hold it forever.

Temperature drift of sensitivity is subtler than zero drift: the gain itself changes with temperature, so a given force reads as a slightly different number when hot. Full-bridge construction cancels the first-order thermal effect, and quality sensors add an on-board temperature sensor and a compensation model, which is why the temperature-compensation spec (often quoted as a percentage of reading per degree, or a compensated operating range) is worth checking. Outside the compensated range, all bets are off.

Creep and hysteresis come from the mechanics. Under a sustained constant load, the element and adhesive relax visco-elastically, so the reading drifts slightly over minutes even though the load is constant (creep). And the reading depends slightly on load history, so approaching a force from above versus below gives slightly different numbers (hysteresis). Both are small in a good sensor (a fraction of a percent of full scale) but they set a floor on absolute accuracy that averaging cannot beat, because they are deterministic and averaging only reduces random error.

The factory calibration (the C matrix) is what turns raw bridges into an accurate wrench, and it is traceable to a load standard. It does not expire quickly, but it can shift after an overload event that plastically deforms the element even slightly, or after years of aging. Periodic recalibration, sending the sensor back to the manufacturer or checking it against known weights, is standard for sensors in precision service. A cheap in-field check: hang a known mass off the tool in a known orientation and confirm the sensor reads the expected wrench.

Rule of thumb: re-bias before every force task to kill zero drift, keep the sensor inside its compensated temperature range, and treat any overload event as a reason to suspect the calibration. A sensor that has been crashed hard should be verified against a known load before you trust its numbers again.

Applications: assembly, finishing, collision, teleop haptics

Assembly and insertion

The archetypal use. Peg-in-hole, connector mating, bearing pressing, and snap-fit assembly all involve fitting parts with clearances tighter than the robot's positioning accuracy. The strategy is force-guided search: press gently in the insertion direction, read the lateral forces and moments from the chamfer or the misalignment, and command small corrective motions that drive those reaction forces toward zero. Spiral and tilt-and-align search patterns are standard. The sensor needs good resolution at low force (assembly forces are often single-digit to tens of newtons) and low crosstalk, because you are resolving a small lateral force while pressing with a larger axial one, exactly the multi-axis case where crosstalk bites. This is also where learned policies increasingly help, using the force signal as a key input (see the imitation learning guide).

Polishing, deburring, and grinding

Surface-finishing tasks regulate a normal force against a surface whose exact geometry you do not know, while the tool follows the surface tangentially. You command a target normal force (say 10 to 40 N) and let the position along that axis float, so the tool rides the surface at constant pressure regardless of small position errors or surface variation. This is force control on one axis, position or velocity control on the others, a hybrid scheme (Raibert and Craig, 1981). The demands are steady force tracking and enough bandwidth to hold force as the surface curves, plus a sensor that survives the vibration and, sometimes, heat of grinding. Dedicated active-contact-flange tools exist for this, but a wrist F/T sensor with a proper force loop does it directly.

Cobot collision detection

Collaborative robots must detect an unexpected contact and stop or retreat before it injures a person, which is the heart of the power-and-force-limiting safety mode in ISO/TS 15066 (see the cobots guide and the functional safety guide). Most cobots do this with joint-level current/torque estimation across the whole arm rather than a wrist sensor, because a collision can happen anywhere along the arm, well beyond the tool. The estimator compares expected torque (from the dynamic model plus gravity) against measured or current-estimated torque, and a discrepancy beyond a threshold triggers a protective stop. A wrist F/T sensor adds sensitive contact detection at the tool specifically, useful for delicate end-of-arm tasks, but whole-arm safety leans on joint sensing.

Teleoperation and haptics

Force sensing is what lets a remote operator feel the environment the robot is touching. The wrist F/T sensor measures the contact wrench, and a bilateral teleoperation controller reflects a scaled version of it back to the operator's haptic input device, so pushing the robot into a stiff surface pushes back on the operator's hand. This closes a human-in-the-loop force loop across a communication link, and it inherits the stability problem of force control plus the added delay of the link, which is why teleoperation haptics is hard: latency in the round trip erodes stability exactly as it does in an autonomous force loop, and the classic fixes (passivity-based control, wave variables) exist precisely to keep a delayed bilateral loop stable. See the teleoperation guide for the control architectures. Surgical robots are the demanding case, where force feedback (or its absence) directly affects how safely a surgeon handles tissue.

Selecting a force/torque sensor

Choose in this order; each criterion eliminates candidates before the next.

1. Where do you measure? Contact wrench at a tool for assembly/finishing: a wrist F/T sensor. Whole-arm collision detection and compliance: joint torque, usually current-estimated. Both, for a capable manipulator. Fine torque at every joint: pay for joint torque sensors or SEAs.
2. Task force and resolution. What is the smallest force you must resolve, and the largest you will apply? Pick a range that puts your working force in the upper half so you get resolution. The biggest range you can find wastes it.
3. Overload headroom. What is the worst-case crash, including the moment from a side impact on a long tool? Confirm the overload rating (per axis) survives it with margin. This often forces a larger range than the task alone would suggest.
4. Crosstalk. Are you resolving a small force on one axis while another is heavily loaded? If so, crosstalk is your binding spec; demand a low number and verify it.
5. Bandwidth and interface. Closing a fast force loop against a stiff environment? You want a stiff sensor, high bandwidth, and a low-latency deterministic interface (EtherCAT or analog), and should avoid a variable-latency USB stream.
6. Drift and temperature. Will the sensor run near hot motors, or over a wide ambient range? Prioritise on-board temperature compensation and a stated compensated range, and plan to re-bias before tasks.
7. Integration. A native driver for your robot (UR, Franka, ROS 2), a clean gravity-compensation and payload-identification workflow, and a stable calibration file matter as much as any single spec.

Rule of thumb: the binding spec is rarely the full-scale range. For assembly it is usually resolution-at-task-force and crosstalk; for finishing it is bandwidth and durability; for collision it is whole-arm coverage (which sends you to joint sensing). Pick the one or two specs your task actually stresses and treat the rest as tie-breakers.

Frequently asked questions

Do I need a wrist F/T sensor if my cobot already detects collisions? Often no, for safety. Cobots detect collisions from joint torque/current across the whole arm, which is what you want for stopping when a person is bumped anywhere. You add a wrist F/T sensor when you need accurate contact force at the tool: assembly, insertion, polishing, force-controlled testing. The joint estimate is too coarse (friction floor at several percent of joint rating) for fine force tasks at the tool.

Why does my sensor read a force when nothing is touching the tool? The tool's own weight. Everything mounted past the sensor sits on it, so the sensor reads the gripper and payload before any contact. You subtract this with gravity compensation, which needs an accurate tool mass and centre-of-mass. If the phantom force changes with pose, it is a gravity-compensation error (run the payload-identification routine). If it drifts with time, it is thermal (re-bias the sensor).

What is crosstalk and why does it matter more than the range? Crosstalk is one axis leaking into another: a pure Fz reads as a small spurious Fx or Tx, typically 1-5% of full scale. It matters because real tasks load multiple axes at once, and you often need to resolve a small force on one axis while a large load sits on another. The crosstalk (more than the noise floor) sets how cleanly you can do that, and averaging does not remove it because it is deterministic coupling.

How much overload headroom do I need? Enough to survive your worst-case crash, which is usually a multiple of your task force. A ratio of 5x to 10x between the overload rating and full scale is common, and you size so that even a full-speed collision stays under the overload limit. Remember that a side force on a long tool produces a large moment at the sensor, so check the torque-axis overload as well as the force axes.

Can I measure joint torque without a torque sensor? Yes, from motor current: tau = Kt * Iq * N * eta - friction. The FOC controller already measures the current, so the estimate is free and full-bandwidth. It is good enough for collision detection, gravity compensation, and hand-guiding, and mediocre for precise force control because friction, variable gear efficiency, and Kt temperature drift corrupt it. The friction floor sits at several percent of joint rating.

Strain-gauge or capacitive: which is better? Both work well when done well. Strain-gauge (ATI, Schunk, Bota) is the mature, high-accuracy, high-stiffness classic with a long track record, and modern strain-gauge units add integrated digital output, on-board compensation, and sometimes an IMU. Capacitive (Robotiq's FT 300) integrates digital output and compensation cleanly and matches strain-gauge on drift and noise in good designs. Choose on interface, integration with your robot, and the specific drift/crosstalk numbers rather than the transduction principle alone.

Why does my force-controlled robot buzz or bounce against a hard surface? Force-loop instability from too much delay against too stiff an environment. High contact stiffness plus latency (sensor filtering, communication, slow control rate) makes the loop oscillate. Fixes: raise the control rate, cut latency, use a stiffer sensor, soften the contact (compliant tool or cover), or switch to admittance/impedance control, which trades force-tracking bandwidth for robustness.

How often do I need to re-zero and recalibrate? Re-bias (re-zero) before every force task, and after any big temperature change, because zero drifts with heat and warm-up. Full factory recalibration (the C matrix) is infrequent, every year or two for precision service, or immediately after any overload event that might have deformed the element. A quick field sanity check is to hang a known mass and confirm the reading.

Does the tool's weight affect the readings during fast moves? Yes. Beyond static weight (handled by gravity compensation), the tool's mass produces an inertial reaction force F = m*a during acceleration that looks like contact. At low speed it is negligible; on a fast, heavy payload it is significant. Sensors with a built-in IMU, or a controller that models commanded acceleration, subtract this so you can sense contact during motion. Otherwise, move slowly during force tasks.

What sample rate does force control need? Higher than you might expect. Stable force control against stiff environments wants 500 Hz to 1 kHz or more, because the stability margin depends on loop delay relative to contact stiffness. The sensor's bandwidth should comfortably exceed the control rate so the sensor is not the bottleneck, and the interface should be deterministic and low-latency (EtherCAT or analog into the controller's ADC).