Robot Sensors: IMUs, Force/Torque & Proprioception

A robot that cannot sense itself is a puppet on an open-loop string, every command a leap of faith, every disturbance an ambush. Before a machine can navigate a room or grasp an object, it has to answer a more basic set of questions: which way is down, how fast am I rotating, where are my joints, and is something pushing back on me right now? Those questions are answered by the proprioceptive and contact sensing stack: the IMUs, encoders, force/torque sensors, current sensors, and tactile skins that let a robot model its own body and its physical contact with the world. Biology solved this problem before it solved vision: a newborn tracks the gravity vector with its vestibular otoliths and its limbs with muscle spindles long before its retina resolves a face. Robotics recapitulates the ordering: a machine must feel itself before it can usefully see the world.

This guide is about that inward- and contact-facing layer of sensing. It is deliberately not about cameras and LiDAR. Those exteroceptive sensors get their own treatment in the LiDAR & depth cameras guide. Here we go deep on inertial measurement, force and torque, tactile contact, and the short-range proximity sensing a robot uses to feel its immediate surroundings. We will derive the noise terms that actually matter on an IMU datasheet, explain why current-based torque estimation is the quiet workhorse of every cobot, and get concrete about real parts: Bosch BMI and BNO IMUs, ATI and Robotiq and Bota Systems force/torque sensors, TE and Honeywell load cells, ST VL53 ToF rangers, and tactile systems from GelSight and SynTouch.

The take: exteroception gets the headlines, but proprioception and contact sensing are what make a robot controllable. A $4 MEMS IMU and a clean motor-current estimate do more for stability and safe contact than a $4,000 LiDAR does, and the hardest problems here are the noise, drift, calibration, timing, and fusion that turn raw counts into a trustworthy state estimate, not the transducers. Get the sensing stack right and your control loops feel telepathic; get it wrong and no amount of clever planning rescues a robot that does not know where its own hand is.

Companion reading: rotary encoders, LiDAR & depth cameras, end-effectors & grippers, and collaborative robots (cobots).

Table of contents

1. Key takeaways
2. The sensing stack: proprioception vs exteroception
3. IMUs deep-dive: accelerometers, gyros, magnetometers
4. IMU sensor fusion: filters, drift, and the yaw problem
5. Encoders & joint position as proprioception
6. Force/torque sensing: 6-axis wrist sensors
7. Joint torque and current-based torque estimation
8. Tactile & contact sensors
9. Load cells, pressure, current, temperature, and the limit switch
10. Range & proximity for self and near-field
11. Sensor specs that matter and reading a datasheet
12. Sensor fusion & state estimation overview
13. Selecting & integrating sensors
14. Frequently asked questions

The sensing stack: proprioception vs exteroception

Every robot's sensing splits cleanly into two families, and confusing them is the source of a lot of bad architecture decisions.

Proprioception is the robot sensing itself: the angles of its joints, the attitude and angular rate of its body, the torques in its drivetrain, the temperature of its motors. The word is borrowed from biology: your proprioceptive sense is how you know where your hand is with your eyes closed. A robot's proprioception comes from encoders, IMUs, joint torque sensors, and motor current.

Exteroception is the robot sensing the world: cameras, LiDAR, depth sensors, microphones. This is how a robot perceives objects, free space, and other agents. It is covered in the LiDAR & depth cameras guide and is out of scope here.

Sitting at the boundary is contact sensing: force/torque sensors and tactile skin. Contact sensing is technically exteroceptive (it measures the world pushing on the robot) but it is so tightly coupled to manipulation control and so similar in character to proprioception (high rate, on-body, fused into the control loop) that it belongs in this guide alongside IMUs and torque sensing.

Rule of thumb: proprioception keeps the robot stable and safe; exteroception lets it be useful. You can build a robot that balances and complies with zero cameras. You cannot build one that does anything intelligent with the world without exteroception. Both layers matter; this guide is the first.

What a robot must measure about itself

Strip a mobile manipulator or a legged robot down to its control needs and the proprioceptive shopping list is short and non-negotiable:

• Body attitude (roll, pitch, yaw) and angular rate, from an IMU. Required for any balancing or flying machine; useful for everything.
• Joint positions: one encoder per actuated joint. Required for any articulated arm or leg.
• Joint velocities: usually differentiated from position, sometimes measured directly.
• Joint torques or contact forces: from current estimation, joint torque sensors, or a wrist F/T sensor. Required for compliant control, force tasks, and collision detection.
• Motor and electronics temperatures: for thermal protection and I²t modeling (see the motor controllers & FOC guide).

The rest of this guide walks each of these, plus the contact and proximity sensing that rounds out the picture, then ties them together with state estimation.

IMUs deep-dive: accelerometers, gyros, magnetometers

The Inertial Measurement Unit is the single most important proprioceptive sensor on any robot that moves its whole body: a drone, a legged robot, a humanoid, a balancing platform. It answers "which way is down" and "how fast am I rotating," and it does so at hundreds to thousands of hertz with no dependence on the environment.

The three transducers

A modern IMU packs up to three sensor types into one MEMS die:

• 3-axis accelerometer: measures specific force (acceleration minus gravity) along three orthogonal axes, in g or m/s². At rest it reads the 1 g gravity vector, which makes it a tilt sensor: knowing where "down" points fixes roll and pitch. It is noisy and picks up every vibration, but it does not drift: its long-term average is anchored to gravity.
• 3-axis gyroscope: measures angular rate (°/s or rad/s) about three axes. Integrate rate over time and you get angle. Gyros are clean and fast in the short term but their bias integrates into unbounded angle drift.
• 3-axis magnetometer: measures the local magnetic field (in µT or gauss), giving an absolute heading reference like a compass. Indispensable for yaw, but easily corrupted by motors, currents, and ferrous structure.

A 6-axis IMU is accel + gyro. A 9-axis IMU (sometimes called an AHRS-grade or MARG sensor) adds the magnetometer. The accel and gyro are complementary by design: the gyro is trustworthy short-term, the accel trustworthy long-term, and fusing them (next section) gives a drift-free attitude in roll and pitch.

MEMS, and how these things actually work

Nearly every robot IMU is MEMS (micro-electro-mechanical systems): tiny silicon structures etched on a chip. A MEMS accelerometer is a proof mass on silicon springs whose deflection changes a capacitance. Model it as a second-order mass-spring-damper: the proof mass m on suspension stiffness k deflects by x = m·a / k = a / ω_n², where ω_n = sqrt(k/m) is the resonant frequency. That single relation contains the whole design tension: softening the springs (lower ω_n) buys sensitivity but costs bandwidth and shock survival, because the usable flat band sits well below resonance. The deflections are angstrom-scale, read out as a differential capacitance.

A MEMS gyro is subtler. Unlike a classic spinning-wheel gyroscope, it drives a mass into a sustained lateral vibration at velocity v; when the chip rotates at rate Ω, the Coriolis acceleration a_c = 2·Ω × v pushes the mass into an orthogonal sense mode, and that tiny out-of-plane motion is read capacitively. The signal is proportional to Ω, but only linearly for small angles, and it is buried under quadrature error (mechanical coupling between drive and sense modes) that dwarfs the Coriolis term and must be cancelled in the ASIC. That quadrature leakage, temperature-dependent and never perfectly nulled, is the physical root of gyro bias. The whole assembly is the size of a grain of rice and costs a few dollars.

The trade is precision. MEMS IMUs are cheap, small, low-power, and rugged, but orders of magnitude less stable than the fiber-optic gyros (FOG) and ring-laser gyros (RLG) used in aircraft and missiles, both of which sidestep moving parts entirely, measuring the Sagnac phase shift of counter-propagating light in a rotating loop. A tactical- or navigation-grade FOG can hold bias to better than 0.01 °/h; a commodity MEMS gyro might be 10 to 100 °/h, a three-to-four-decade gap. For robotics, MEMS is almost always the right answer: you fuse it with encoders and vision rather than paying for a $30,000 navigation IMU. The industry vocabulary for these terms rests on published standards: the metrology and test procedures are pinned down in IEEE Std 528 (inertial sensor terminology), IEEE Std 1431 (Coriolis vibratory gyros), IEEE Std 647 (ring-laser gyros), and IEEE Std 952 (fiber-optic gyros), the referees when a datasheet and a paper disagree on what "bias instability" means.

The Bosch lineup, concretely

Two product families dominate robotics:

• Bosch BMI series (e.g. BMI088, BMI270, BMI323): raw 6-axis accel+gyro parts. The BMI088 is a favorite on drones and robot flight controllers: it is specified for high vibration, with a gyro noise density around 0.014 °/s/√Hz and an accel noise density around 175 µg/√Hz. You run your own fusion on the host.
• Bosch BNO055 / BNO085 (BNO08x): "smart" 9-axis sensors with an on-chip processor running the fusion (Bosch's BSX / Hillcrest's SH-2 algorithms). They output a fused quaternion directly. Convenient when you do not want to write a filter, at the cost of being a black box you cannot fully tune.

Other common parts: the InvenSense/TDK ICM-20948 and ICM-42688 (the 42688 is a low-noise 6-axis part popular on newer flight controllers), and the Analog Devices ADIS16xxx industrial IMUs (e.g. ADIS16505) when you need calibrated, tactical-grade performance in a module.

Rule of thumb: if you are writing the control loop, buy a raw 6-axis part (BMI088, ICM-42688) and run your own fusion: you keep timing control and tuning. Reach for a BNO08x only when you want attitude with zero filter code and can live with a fixed output rate.

The error terms that actually matter

Here is where datasheets earn their keep. The headline "±2000 °/s range, 16-bit" tells you almost nothing about whether the IMU will drift your robot into a wall. These five terms do:

Spec	Units	What it means	Why you care
Noise density	°/s/√Hz (gyro), µg/√Hz (accel)	White noise per √bandwidth	Sets the noise floor; multiply by √bandwidth for RMS noise at your rate
Angle Random Walk (ARW)	°/√h	How fast white-noise-driven angle error grows	The unavoidable short-term integration error of the gyro
Velocity Random Walk (VRW)	(m/s)/√h	Accel equivalent of ARW	Position error growth from accel integration
Bias instability	°/h (gyro), µg (accel)	The floor of slow bias drift (flicker noise)	The best stability you can get even after calibration, the bottom of the Allan curve
Bias repeatability / turn-on bias	°/s, mg	How much bias changes run-to-run	Forces a re-zero at each startup; affects how long you must hold still
Scale factor error	ppm or %	Gain error of the transducer	Multiplies with the true rate; matters at high rates/accelerations
Cross-axis sensitivity	%	Leakage between axes from imperfect alignment	Couples motion on one axis into another; calibratable

Noise density to RMS noise: white noise power is flat in frequency, so its variance scales linearly with bandwidth and its RMS with √bandwidth. If a gyro is rated 0.01 °/s/√Hz and you sample at a bandwidth of 100 Hz, the RMS angular-rate noise is roughly 0.01 × √100 = 0.1 °/s. Halve your bandwidth and you cut RMS noise by √2 ≈ 1.41×, at the cost of latency. This is why the noise density, not the RMS number, is the portable spec: RMS is meaningless until you name the bandwidth it was measured over, and vendors love to quote it at a flatteringly narrow one.

ARW is the term that tells you how badly the gyro drifts in the short term, and it falls straight out of integrating that white noise. Angle is the time-integral of rate; integrating a white-noise process yields a random walk whose standard deviation grows as √t, not t, the hallmark of Brownian diffusion. Formally, ARW N (in °/√h) relates to the rate noise density n (in (°/s)/√Hz) by N = n × 60 when you convert the per-second density to a per-√hour figure. The √t scaling is the honest way to reason about it: a gyro with ARW of 0.3 °/√h accumulates about 0.3° of angle uncertainty after one hour of unaided integration, but only 0.3 × √(1/60) ≈ 0.04° after one minute, and 0.3 × √(1/3600) ≈ 0.005° after one second. Because the error grows sub-linearly, a good gyro can dead-reckon attitude surprisingly far, right up until the deterministic bias (which grows linearly, θ_bias = b·t) overtakes the random walk. The crossover time where linear bias drift equals √t diffusion is roughly t* ≈ (N/b)²; below t* you are noise-limited, above it you are bias-limited, and knowing which regime you live in tells you whether to spend money on a quieter gyro or a better calibration.

Allan variance: reading all of this off one log

The Allan variance, introduced by David Allan in 1966 for characterizing atomic-clock stability, and adapted to inertial sensors by El-Sheimy, Hou, and Niu ("Analysis of Inertial Sensor Errors Using Allan Variance," IEEE Transactions on Instrumentation and Measurement, 2008), is the standard tool for separating an IMU's noise terms. Its power is that it decomposes a single time series into contributions that each dominate at a different averaging time. Divide your log into bins of length τ, average within each bin to get a sequence of cluster means ȳ_k(τ), and the Allan variance is the mean-square of successive differences:

σ²(τ) = (1/2) · ⟨ ( ȳ_{k+1}(τ) − ȳ_k(τ) )² ⟩

The factor of one-half makes σ(τ) equal the RMS deviation for white noise, so the plot reads in physical units. You log the gyro at rest for a long time (hours, the longest τ you can trust needs many independent clusters, so an overnight run buys you the low-frequency end), then plot the Allan deviation against averaging time τ on a log-log scale. The curve has characteristic slopes, each a different physical process:

• A −1/2 slope at short τ → angle random walk (white noise). Read ARW where this line crosses τ = 1 s (or 1 h, by convention).
• A flat minimum → bias instability. The lowest point of the curve is the best bias stability you can hope for.
• A +1/2 slope at long τ → rate random walk (the bias itself drifts).

Allan deviation σ(τ), log-log:

 σ │ \                          /
   │  \  slope -1/2            /  slope +1/2
   │   \ (random walk)        /   (rate random walk)
   │    \____                /
   │         \___       ____/
   │             \_____/
   │              ^ bias instability (flat minimum)
   └────────────────────────────────── τ (averaging time)

The practical workflow: log your specific IMU on your specific board (vibration and temperature change everything), compute the Allan deviation, and pull ARW and bias instability from the curve. Those numbers feed directly into your filter's process-noise tuning. This is one of the few places where a datasheet number is no substitute for measuring your own hardware.

IMU sensor fusion: filters, drift, and the yaw problem

A raw IMU is useless until you fuse its channels into an attitude estimate. The fusion problem is specific and well understood: the gyro is trustworthy over short intervals but drifts; the accelerometer is trustworthy over long intervals (gravity) but is noisy and corrupted by linear acceleration. Combine them so each covers the other's weakness.

The complementary filter

The cheapest good fusion is the complementary filter. It high-pass-filters the integrated gyro angle (keeping its clean short-term behavior, rejecting its slow drift) and low-pass-filters the accelerometer-derived angle (keeping its drift-free long-term behavior, rejecting its noise), then sums them. In one line:

# Complementary filter for a single tilt axis (per timestep dt):
# theta_gyro  = previous angle + gyro_rate * dt   (integrate gyro)
# theta_accel = atan2(accel_y, accel_z)           (gravity-derived tilt)

alpha = tau / (tau + dt)          # tau = filter time constant, ~0.5-2 s
theta = alpha * (theta + gyro_rate * dt) + (1 - alpha) * theta_accel

# alpha ~ 0.98 means "trust the gyro for fast motion,
# slowly pull toward the accelerometer for the DC truth."

A complementary filter is a handful of lines, runs at any rate, and is genuinely excellent for roll/pitch attitude on drones and small robots. Its limits: it assumes the accelerometer reads pure gravity, so high linear acceleration (a hard maneuver) temporarily corrupts the correction. Tune alpha higher to trust the gyro more during dynamics.

Mahony and Madgwick

Mahony and Madgwick filters are the production-grade complementary filters used across the drone and robotics world. Both fuse 6- or 9-axis data into a quaternion, which sidesteps the gimbal-lock singularity that Euler-angle formulations hit at ±90° pitch. Mahony (Mahony, Hamel, and Pflimlin, "Nonlinear Complementary Filters on the Special Orthogonal Group," IEEE Transactions on Automatic Control, 2008) is a geometrically principled observer on SO(3): it forms the attitude error as a cross-product between the measured and predicted gravity/magnetic vectors and drives it to zero with a PI controller, where the integral term is the gyro-bias estimate, elegant, because the same loop that corrects attitude also learns and removes the bias. Madgwick (Sebastian Madgwick's 2010 report, "An efficient orientation filter for inertial and inertial/magnetic sensor arrays") poses the correction as an optimization: find the quaternion increment that best aligns the predicted gravity (and magnetic) field with the measured one, and take a single gradient-descent step of size beta toward it each tick. Both are cheap enough for an 8-bit MCU (a few hundred floating-point operations per update) and both collapse to one tunable gain (Kp or beta) trading responsiveness against smoothness. The gain has a physical meaning: it sets the crossover frequency ω_c between "trust the gyro" (above ω_c) and "trust the accelerometer" (below), so beta should scale with your gyro's actual drift rate, not be copied from a tutorial. For an embedded attitude estimate without the machinery of a Kalman filter, Madgwick is the default.

Kalman and the EKF

When you must fuse heterogeneous, asynchronous, time-stamped sensors (IMU plus encoders plus a wheel odometer plus an occasional vision fix) and you want a principled estimate with a covariance, you graduate to a Kalman filter (Kálmán's 1960 formulation, still the load-bearing math under most robot state estimators). The Kalman filter is optimal only for linear systems with Gaussian noise; because attitude/orientation is nonlinear (quaternions, trig), you use the Extended Kalman Filter (EKF), which linearizes the dynamics and measurement models via their Jacobians around the current estimate, or the Unscented Kalman Filter (UKF) (which propagates a deterministic set of sigma points through the true nonlinearity instead of linearizing) or an error-state EKF (ESEKF) for cleaner handling of the quaternion manifold.

The error-state formulation deserves the spotlight in robotics: rather than estimate the full orientation directly (a unit quaternion is a constrained 4-vector living on a 3-sphere, awkward for a filter that assumes an unconstrained vector space), you estimate a small error rotation in the tangent space (a 3-vector) and periodically inject it back into the nominal quaternion. This keeps the covariance minimal (3×3, not 4×4) and the linearization valid, because small errors stay small. The modern refinement is the invariant EKF (Barrau and Bonnabel, "The Invariant Extended Kalman Filter as a Stable Observer," IEEE Transactions on Automatic Control, 2017), which exploits the symmetry of the SE(3) group so the linearization error is independent of the trajectory, giving provable convergence where a naive EKF can diverge on aggressive maneuvers.

The EKF's advantages over a complementary filter: it tracks gyro bias as a state (so it learns and removes drift), it produces a covariance (so downstream consumers know how much to trust the estimate), and it cleanly incorporates new measurements at their own rates and latencies. Its costs: more compute, more states to tune, and a process/measurement-noise model you have to get right: the process noise Q is exactly where your Allan-variance ARW and bias-instability numbers go, and the measurement noise R is where a sensor's RMS noise lives. Get Q and R wrong and the filter either ignores good measurements (over-confident) or chases noise (under-confident). The PX4 and ArduPilot autopilots, and essentially every serious legged robot, run an EKF or ESEKF for state estimation.

Rule of thumb: use a Madgwick/Mahony complementary filter when you need attitude and your sensors are just an IMU (± mag). Move to an EKF when you must fuse encoders, odometry, GPS, or vision, or when you need a covariance for a downstream estimator. Do not reach for an EKF to do a job a 20-line complementary filter does fine.

Why yaw is the hard one

Here is the asymmetry that trips up newcomers: roll and pitch are observable; yaw is not, at least not from an accelerometer. The accelerometer measures the gravity vector, which points down. Rotating the robot in roll or pitch tilts that vector relative to the body, so the accel sees it and can correct gyro drift. But rotating in yaw (heading) spins the robot around the gravity vector: gravity looks identical before and after. The accelerometer is blind to yaw.

The consequence: with a 6-axis IMU (no magnetometer), yaw drifts without bound. There is nothing to correct the integrated gyro heading. Over minutes, a 6-axis estimate can wander tens of degrees in yaw while roll and pitch stay rock solid.

To bound yaw you need an absolute heading reference:

• A magnetometer (the 9-axis solution): gives a compass heading, but is fragile near motors, high currents, and ferrous structure. Needs hard-iron/soft-iron calibration.
• Vision/SLAM or LiDAR odometry: corrects yaw from environmental features (see the LiDAR & depth guide).
• Wheel odometry on a ground robot, or a GPS course-over-ground outdoors.

This is the reason indoor robots without a clean magnetometer or vision fix slowly rotate their world model, and why "my robot thinks it is facing the wrong way after a few minutes" is almost always a yaw-observability problem, not a bug.

Encoders & joint position as proprioception

Joint position is proprioception, and for an articulated robot it is the proprioceptive signal: without it forward kinematics is impossible and you cannot know where the end-effector is. The transducer is almost always a rotary encoder on each joint.

Encoders have their own full treatment, so this section is deliberately brief: see the rotary encoders guide for incremental vs absolute, optical vs magnetic vs capacitive, single- vs multi-turn, resolution/accuracy, and the on-axis magnetic chips (AS5047, AS5048, MA732) that dominate robot joints.

For this guide, the points to carry forward:

• Absolute encoders report position without a homing move, essential for joints that must know where they are at power-on. Incremental encoders count from an index and need homing.
• A joint typically wants both a high-resolution encoder on the motor (for commutation and velocity) and an absolute encoder on the gearbox output (for true joint angle, immune to backlash), standard on harmonic-drive cobot joints (see gearboxes).
• Velocity is usually differentiated from position, amplifying quantization noise: encoder resolution directly limits velocity-loop quality.
• In the state estimate, joint encoders are the most trusted proprioceptive input: low noise, no drift, high rate. The IMU and torque sensors play supporting roles around them.

Force/torque sensing: 6-axis wrist sensors

When a robot must control contact (insert a peg, polish a surface, deburr an edge, assemble a connector), it needs to measure the forces and torques at its end-effector. The instrument is a 6-axis force/torque (F/T) sensor, mounted at the wrist between the robot flange and the tool.

What it measures and how

A 6-axis F/T sensor reports a full wrench: three forces (Fx, Fy, Fz) and three torques (Tx, Ty, Tz) in the sensor frame. Internally, most do it with strain gauges bonded to a precisely machined elastic element (often a spoked "Maltese cross" hub). A metal-foil strain gauge works because stretching a conductor lengthens and thins it, raising its resistance: ΔR/R = GF · ε, where the gauge factor GF ≈ 2 for foil gauges and ε is the mechanical strain. The strains involved are minuscule (a few hundred microstrain at full scale, so ΔR/R is on the order of 10⁻³), which is why the gauges are wired into Wheatstone bridges: a bridge is a differential amplifier made of resistors that rejects the huge common-mode resistance and temperature drift, leaving only the tiny difference signal. A quarter-bridge sees V_out/V_ex = (GF·ε)/4; full-bridge arrangements (four active gauges, two in tension and two in compression) quadruple the signal and cancel first-order temperature effects, which is why good sensors use them.

Each bridge, though, responds to a mixture of all six wrench components: no single machined flexure isolates one axis perfectly. So the raw output is a 6-vector of bridge voltages v, and the true wrench is recovered by a calibration matrix: w = C · v, where C is a 6×6 matrix the manufacturer fits by loading the sensor with known forces and torques (typically via least-squares over dozens of load cases). The off-diagonal terms of C are precisely what decouple the axes, and the residual you cannot remove with a linear C (from nonlinearity, hysteresis, and temperature) is the crosstalk spec. This is why a factory F/T sensor is useless without its serial-matched calibration file: two identical-looking sensors have different C matrices.

Two implementation families:

• Strain-gauge (resistive): the classic. ATI Industrial Automation's sensors (the Nano, Mini, Gamma, Delta families) are the reference. High accuracy and stiffness, mature, but the bridge signals need careful amplification and temperature compensation.
• Capacitive / MEMS: newer designs (some Bota Systems and OnRobot/Robotiq units) measure the elastic element's deflection capacitively. They can integrate signal conditioning and even an IMU on the same board, and tend to have excellent noise performance and built-in compensation.

The specs that actually bite

The headline number is full-scale range (e.g. ±200 N, ±10 N·m). It is rarely what limits you. The specs that cause real grief:

Spec	What it means	Why it bites
Crosstalk (cross-axis coupling)	A pure Fz reads as a spurious Fx/Tx	Limits how cleanly you can resolve one axis during multi-axis loading; typically 1 to 5% of full scale
Overload rating	Force beyond which the element yields or breaks	A collision can exceed full scale by 5 to 10×; the sensor must survive it. Overload is often quoted per-axis (e.g. 5× Fz)
Zero / thermal drift	Output drift with temperature and time	A warming sensor or motor heat shifts the zero by newtons over minutes; you re-bias before force tasks
Resolution	Smallest resolvable force	A Nano17 resolves down to ~1/160 N; a Delta resolves ~1/8 N, pick the range that gives resolution where you need it
Stiffness / bandwidth	How stiff the element is, mechanical resonance	A stiff sensor preserves position accuracy and raises bandwidth (hundreds of Hz to kHz); a compliant one acts as an unwanted spring
Noise	Output noise at rest	Sets the smallest contact force you can reliably detect

Rule of thumb: size an F/T sensor for resolution at your task force, then check that its overload rating survives your worst-case collision. Picking a ±500 N sensor for 5 N assembly forces wastes your resolution; picking a ±10 N sensor that breaks on a 60 N crash wastes the sensor.

Real products

Sensor	Type	Typical range (Fz / Tz)	Notes
ATI Nano17	Strain gauge	±70 N / ±0.5 N·m	Tiny (17 mm), fingertip-scale, very high resolution (SI-50-0.5 cal: Fz ±70 N, lateral Fx/Fy ±50 N)
ATI Gamma	Strain gauge	±400 N / ±10 N·m	Industrial workhorse for arm wrists
Robotiq FT 300-S	Capacitive	±300 N / ±30 N·m	Plug-and-play for UR cobots, integrated comms
Bota Systems Rokubi / MiniONE	Capacitive (some w/ IMU)	±200 to 500 N / ±5 to 20 N·m	EtherCAT/USB/CAN, on-board IMU option, low drift
OnRobot HEX-E / HEX-H	Strain gauge	±200 / ±400 N	Cobot-targeted, 6-axis
Schunk FT	Strain gauge	wide	Robust industrial line

A wrist F/T sensor is the right tool when you need accurate, full 6-DOF contact wrench at the tool: assembly, polishing, force-controlled testing. It is overkill (and a single point of fragility) when current-based torque estimation at the joints already gives you enough contact awareness for collision detection, which is the next section.

Joint torque and current-based torque estimation

There are two ways to know the torque in a robot joint, and the choice between them defines a robot's cost and capability.

Option A: true joint torque sensors

Put a strain-gauge transducer in the joint's torque path, typically on the output side, after the gearbox. This directly measures the torque the joint delivers (or absorbs), immune to friction and gear losses upstream. This is what high-end torque-controlled robots do: the Franka Emika / Franka Research 3 has a torque sensor in every one of its 7 joints, which is what gives it its exquisite compliance and sensitivity. The Kuka LBR iiwa does the same. The cost is real: a torque sensor per joint adds expense, complexity, and a wiring/calibration burden at every axis.

Option B: current-based torque estimation (the cobot trick)

Most cobots and many quadrupeds skip per-joint torque sensors and instead infer torque from the motor current. In a PM motor, torque is proportional to the torque-producing current:

# Motor torque from phase current (q-axis current in FOC):
tau_motor = Kt * Iq          # Kt = torque constant [N·m/A], Iq = q-axis current [A]

# Joint output torque, accounting for gearing and losses:
tau_joint = (Kt * Iq * N * eta) - tau_friction
#   N   = gear ratio
#   eta = gearbox efficiency (~0.6-0.9 for harmonic/cycloidal)
#   tau_friction = Coulomb + viscous friction (speed-dependent, modeled or learned)

The clean proportionality τ = Kt · Iq is the definition of field-oriented control for a well-controlled PM synchronous motor, which holds the rotor and stator fields at 90° so all current produces torque and none is wasted magnetizing. It is also a deep symmetry: the torque constant Kt (N·m/A) and the back-EMF constant Ke (V·s/rad) are numerically equal in SI units, Kt = Ke, a direct consequence of energy conservation in the electromechanical coupling. 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 quadruped like Unitree's, can be force-aware and collision-sensitive without a single dedicated torque sensor.

The catch is accuracy. Every term in Kt · Iq · N · η − τ_friction leaks error:

• Friction: this dominates, and it is nastier than the "Coulomb + viscous" cartoon suggests. Real joint friction follows a Stribeck curve: high static friction (breakaway), a dip as the joint starts moving (the Stribeck effect, from a lubricant film forming), then rising viscous friction with speed. Worse, friction has memory near zero velocity (pre-sliding displacement and hysteresis), which the LuGre dynamic friction model (Canudas de Wit, Olsson, Åström, and Lischinsky, IEEE Transactions on Automatic Control, 1995) captures with an internal "bristle deflection" state. This is why friction must be identified per joint, often at multiple temperatures, and why a cold robot and a warmed-up robot estimate different torques from the same current.
• Gear efficiency: harmonic and cycloidal drives lose 10 to 40% of torque, and η itself is a function of load, speed, and temperature, not a constant. Efficiency also drops sharply at low load, precisely the regime where you want fine force control.
• Kt variation: the torque constant drifts with temperature because it scales with magnet remanence, and sintered NdFeB magnets lose flux at roughly −0.1 %/°C (reversible). A 60 °C winding rise is a ~6% Kt shift, a systematic torque error unless you compensate with the winding-temperature estimate you already have for thermal protection.
• Backlash and elasticity: the gearbox is not a rigid link; under dynamic loads the wind-up and lost motion smear the current-to-output-torque relationship, especially through direction reversals.

The result: current-based torque is excellent for collision detection and gross compliance (the cobot stopping when you bump it, gravity compensation, hand-guiding) but mediocre for precise force control at low forces. The friction floor means you typically cannot resolve joint torques below several percent of the joint's rating from current alone: that floor is friction, not electrical noise, so a quieter current sensor does not move it.

Rule of thumb: current-based torque estimation is "good enough to be safe and compliant, not good enough to thread a needle." If you need fine force control at the tool, add a wrist F/T sensor. If you need fine torque control at every joint, pay for joint torque sensors. For collision detection and hand-guiding, current estimation is the right, cheap answer, and it is why cobots are affordable (see the cobots guide).

Series elastic actuators: torque from deflection

A third path deserves mention: the series elastic actuator (SEA), introduced by Pratt and Williamson ("Series Elastic Actuators," IROS 1995), deliberately inserts a calibrated spring between the gearbox and the load, then measures the spring's deflection (with an encoder) to compute torque via Hooke's law, τ = k · Δθ. This turns torque sensing into position sensing (cheap and robust) and here the resolution argument flips in your favor: a high-resolution encoder across a soft spring resolves torque finely, because a given torque produces a large, easily-measured deflection. The spring also decouples the motor's reflected inertia from shocks, so an impact no longer slams straight into the gear teeth. The downside is a hard bandwidth ceiling: the actuator's large-force bandwidth is set by the spring and the motor's peak force, roughly ω_max ≈ sqrt(k / m_motor) for the reflected motor mass, and softening the spring for better torque resolution lowers it. You are trading force fidelity against force bandwidth: the same k-versus-ω_n tension we met in the MEMS accelerometer, now at actuator scale. SEAs show up on legged robots and some collaborative designs; see the legged/quadruped guide.

Tactile & contact sensors

A wrist F/T sensor tells the robot the net wrench at the tool. A tactile sensor tells it what is happening at the contact surface itself: where the contact is, its shape, whether it is slipping, the pressure distribution. Tactile sensing is to the gripper what skin is to a fingertip, and it is the enabling technology for dexterous manipulation (see the end-effectors & grippers guide).

The technology families

Type	Principle	Strengths	Weaknesses
Resistive (FSR)	Force-sensitive resistor changes resistance under pressure	Cheap, thin, simple	Poor accuracy, hysteresis, drift; mostly binary/coarse pressure
Capacitive	Pressure changes plate spacing/area → capacitance	Sensitive, good for arrays, low power	Susceptible to EMI; needs guarding
Barometric (MEMS pressure)	Tiny MEMS pressure sensor under an elastomer dome	Cheap, robust, calibratable, good range	One sensor = one taxel; coarse spatial resolution
Optical / vision-based	Camera images a deformable gel membrane	Extremely rich data: geometry, slip, shear, texture	Bulky, camera latency, compute-heavy
Piezoresistive / MEMS arrays	Micromachined pressure-sensitive array	High spatial resolution	Fragile, expensive

Optical tactile: GelSight and friends

The standout of the last decade is optical (vision-based) tactile sensing, pioneered by Johnson and Adelson at MIT ("Retrographic sensing for the measurement of surface texture and shape," CVPR 2009). A GelSight sensor is, in essence, a small camera looking up at the underside of a soft, coated elastomer pad through internal illumination. The trick that makes it work is the opaque metallic coating on the gel's outer face: it turns a squishy transparent membrane into a surface with known, uniform reflectance, which removes the object's own color and texture from the image and leaves only geometry. Illuminate that coated surface from three or more directions with different-colored LEDs and you have a photometric stereo rig: each pixel's RGB triple encodes the local surface normal, and integrating the normal field yields a height map. Because the sensor controls both the lighting and the reflectance, the reconstruction hits sub-10-micron depth resolution: you can read the embossing on a coin, detect the onset of slip from the shear deformation of printed markers tracked frame-to-frame, and estimate the contact wrench from the bulk deformation field. The height map is dense and metric in a way no capacitive array can match.

The trade-offs are real: a GelSight-style fingertip is bulkier than a flat pad, adds camera latency (tens of milliseconds), needs compute to process the image, and the gel wears and must be replaced. But for research-grade dexterity the data richness is unmatched. The MIT-originated GelSight, the open GelSight Mini, and Meta's open-source DIGIT sensor are the reference designs.

Multimodal tactile: SynTouch

SynTouch's BioTac takes a biomimetic route: a fingertip-shaped sensor with a fluid-filled elastomer skin over an electrode-studded core. It senses three modalities at once: pressure (impedance changes as the fluid thins under load), vibration (a hydro-acoustic sensor catches the micro-vibrations of slip and texture), and temperature/heat-flux (which encodes thermal properties, metal feels different from wood). It is the closest thing to a synthetic human fingertip and is used heavily in dexterity and material-recognition research.

Rule of thumb: use barometric or capacitive taxel arrays for affordable, robust grip-force and contact-presence sensing on production grippers. Reach for optical (GelSight/DIGIT) or BioTac when the research goal is dexterity (slip detection, in-hand pose, fine geometry) and you can afford the bulk, latency, and compute.

What tactile gives you that F/T does not

Slip detection is the headline. A wrist F/T sensor sees that grip force dropped but cannot localize where the object is slipping; a tactile array or optical sensor sees the incipient shear at the contact patch and can trigger a grip-force increase before the object falls. Tactile also gives contact localization, shape, and texture, all of which a single 6-axis wrench cannot.

Full-hand, high-density tactile

The research frontier is pushing tactile from isolated fingertips toward dense skin over the whole hand. Peking University's F-TAC Hand reports vision-based tactile sensing at 0.1 mm spatial resolution (about 10,000 taxels per cm², approaching human fingertip density) across roughly 70% of the palm surface, while preserving full range of motion. On the electronics-based side, PaXini's DexH13 tactile hand integrates about 1,140 sensing units that report roughly 15 dimensions of contact, including six-axis force, material texture, elastic response, and temperature. The hard problems these systems raise are wiring, durability, and the compute to fuse thousands of channels in real time, which is why fingertip-only tactile still dominates anything that has to survive a factory.

Load cells, pressure, current, temperature, and the limit switch

Beyond the marquee sensors, a working robot is studded with humbler transducers that are easy to overlook and costly to omit.

Load cells

A load cell is a single- (or few-) axis force sensor, the strain-gauge element behind every digital scale. Robots use them for payload weighing, force-controlled pressing along one axis, and as the force element inside grippers and SEAs. Common forms: S-beam, bending-beam, pancake/donut, and button cells. Suppliers like TE Connectivity, Honeywell (Model 31, FSS/FMA series), HBM, and Futek span from sub-gram to multi-ton cells.

The figure of merit is accuracy class (often a fraction of full scale, e.g. 0.1% FS), plus the same enemies as any strain device: temperature drift, creep (output slowly climbing under a constant sustained load, as the adhesive and metal visco-elastically relax over minutes to hours, typically quoted as a fraction of FS over 30 minutes), and nonlinearity. Creep is why a precision scale waits for its reading to settle: the value the instant you apply weight and the value five minutes later disagree, though nothing moved. A load cell needs a stable, low-noise amplifier because the bridge output is tiny: full-scale sensitivity is typically 1 to 3 mV per volt of excitation, so a 5 V-excited cell swings only ~10 mV across its entire range. The HX711 24-bit sigma-delta ADC with its integrated low-noise PGA is the ubiquitous cheap front end; industrial setups use ratiometric bridge amplifiers that reject excitation-voltage drift by design.

Pressure sensors

Two distinct uses. Pneumatic/hydraulic pressure sensors monitor the air or fluid driving soft actuators, suction grippers, and pneumatic systems (vacuum gripper feedback is a common case, see the grippers guide). Barometric pressure sensors (e.g. Bosch BMP388/BMP390) double as altimeters on drones, giving a relative-altitude estimate that fuses with the IMU and GPS to stabilize vertical position to a meter or so.

Current sensing

Motor current is doing double duty: it is the inner loop of FOC and, as we saw, the basis of torque estimation. Current is measured with shunt resistors (cheap, accurate, but reference low-side or need isolation) or Hall-effect sensors (e.g. Allegro ACS series, galvanically isolated, no insertion loss). Bus and battery current sensing also feeds power budgeting and fault detection. See the motor controllers & FOC guide for how the current loop uses it.

Temperature

Motor windings, power transistors, batteries, and gearboxes all need thermal monitoring. Transducers range from cheap NTC thermistors (winding and ambient), to RTDs (PT100/PT1000) for accuracy, to thermocouples for high temperature, to the on-die temperature sensors in every modern MCU and gate driver. Thermal data feeds I²t models that protect motors from overheating during sustained high-current operation.

The limit switch and bump sensor

Do not over-engineer. A mechanical limit switch is the most reliable position-reference and end-of-travel detector ever built: a binary, latching, zero-software signal that an axis has reached a hard stop or home position. Robots still use them for homing, end-stops, and safety interlocks. A bump sensor (a switch behind a compliant bumper, as on every robot vacuum) is the cheapest possible collision detector. Hall-effect and reed switches give the same binary information without contact wear.

Rule of thumb: reach for the simplest transducer that answers the question. If "did the axis reach home?" is a yes/no, a $1 microswitch beats a $200 absolute encoder for that specific job. Save the expensive sensors for the questions that are genuinely analog.

Range & proximity for self and near-field

Between "the robot's own body" and "the full 3D map of the room" sits a band of short-range and proximity sensing: knowing how far a surface is, or simply whether something is there, within a few centimeters to a few meters. This is distinct from the long-range mapping handled by LiDAR and depth cameras (see the LiDAR & depth cameras guide); here we cover the cheap, on-body rangers and switches.

Time-of-Flight (ToF) rangers

A ToF sensor emits a pulse of (usually infrared) light and times how long it takes to return: distance is d = c · t / 2. That formula hides a brutal engineering demand: light covers 30 cm in one nanosecond, so resolving distance to 1 mm means resolving time to about 6.7 picoseconds. No robot times a single photon that precisely. Instead, chips like ST Microelectronics' VL53 line use arrays of single-photon avalanche diodes (SPADs) and build a histogram of photon arrival times over thousands or millions of emitted pulses; the peak of that histogram estimates the round-trip time far below the resolution of any single measurement, trading integration time for precision the same way the Allan-variance clusters traded averaging time for stability. The VL53L0X, VL53L1X, VL53L4CX, and VL53L8 (multizone) are single-chip laser rangers the size of a grain of rice, costing a few dollars, with ranges from about 1 cm to 4 m and millimeter-class resolution at close range. They talk I²C, draw little power, and are everywhere: cliff detection on robot vacuums, object presence in grippers, short-range obstacle sensing, and gesture detection. The newer multizone parts (VL53L8 with an 8×8 grid) blur the line into a tiny depth sensor. The physical range limit is the photon budget: return signal falls off as 1/d², so on a matte black target at a shallow angle the histogram peak vanishes into the ambient-light floor long before the datasheet's 4 m.

ToF limits: range falls on dark, non-reflective, or angled surfaces, and ambient sunlight can swamp the return outdoors. They are a near-field tool, not a mapping sensor.

Ultrasonic

Ultrasonic rangers (the classic HC-SR04, or rugged industrial units from Pepperl+Fuchs and Banner) time an acoustic pulse instead of light. Their virtue is that they see what optical sensors miss: glass, clear plastic, shiny or transparent surfaces reflect sound fine even when they fool a laser. Their vices trace to sound being slow and diffuse. Update is limited by round-trip time (~340 m/s means a 1 m round trip is ~6 ms), and the beam spreads: diffraction sets the cone half-angle at roughly θ ≈ asin(1.22·λ/D) for an aperture D, and at 40 kHz the wavelength λ ≈ 8.5 mm is large, so a small transducer radiates a wide, fuzzy lobe. There is a subtler trap: the speed of sound itself varies with temperature, c ≈ 331.3 · sqrt(1 + T/273) m/s (about +0.6 m/s per °C), so an ultrasonic ranger calibrated at 20 °C over-reads distance by roughly 3.5% at 0 °C if you do not temperature-compensate. Good for coarse presence and liquid-level sensing; weak for precise localization.

IR proximity and reflective sensors

Cheap IR reflective sensors (an IR LED and a photodiode) give an analog "something is close and reflective" signal at a few centimeters; Sharp GP2Y rangers triangulate distance optically out to tens of centimeters. Coarse and surface-dependent but trivially cheap: line-following, edge detection, crude obstacle sensing on small robots.

Inductive and capacitive proximity switches

In industrial cells, the rugged binary workhorse is the inductive proximity switch: a sealed barrel sensor that detects a metal target within a few millimeters by the eddy currents it induces, with no contact, no wear, and an IP67/IP69K rating that shrugs off coolant and dust. Capacitive proximity switches detect any material (including liquids and non-metals) by a change in capacitance. Both are the unglamorous, indestructible presence detectors that confirm a part is in a fixture or a gripper is at a station, far more reliable in a dirty cell than any optical sensor.

Sensor	Range	Resolution	Best at	Weak at
ToF (VL53)	1 cm to 4 m	mm-class	Cheap precise short range	Dark/angled/transparent, sunlight
Ultrasonic	2 cm to 4 m	cm-class	Glass, shiny, transparent	Angular resolution, speed
IR reflective	1 to 80 cm	coarse	Ultra-cheap presence	Surface color/reflectivity
Inductive prox	1 to 15 mm	binary	Rugged metal detection	Only metals, very short range
Capacitive prox	1 to 25 mm	binary	Any material, rugged	Short range, env sensitivity

Sensor specs that matter and reading a datasheet

Across every sensor in this guide, the same handful of specifications decide whether it works in your loop. Learn to read these and you can size any sensor.

• Range (full scale): the span of values the sensor measures (±2000 °/s, ±300 N, 0 to 4 m). Pick a range that covers your worst case with headroom but is not so large it wastes resolution.
• Resolution: the smallest change the sensor can report. For digital sensors this is partly the ADC: an N-bit ADC over a range R gives a quantization step of R / 2^N. A 16-bit gyro over ±2000 °/s resolves about 0.06 °/s per count.
• Accuracy: how close the reading is to truth, after calibration. Distinct from resolution: a sensor can be high-resolution and inaccurate (precise but biased).
• Bandwidth: the frequency range the sensor tracks faithfully, set by its internal filtering. A 100 Hz bandwidth sensor cannot report a 500 Hz vibration. Higher bandwidth means faster response but more noise (you integrate noise over more frequencies).
• Noise: random variation at constant input, quoted as RMS, noise density, or peak-to-peak. Noise trades against bandwidth; you reduce it by filtering, which costs latency.
• Drift: slow change in output over time and temperature at constant input. Bias drift is the silent killer of integrated quantities (gyro angle, accel position). Always check the thermal drift spec; the room-temperature number alone will mislead you.
• Latency: the delay from a physical event to the sensor reporting it. Internal filtering, sampling, and digital-bus transport all add latency. In a fast control loop, latency is phase lag, and phase lag is instability.
• Repeatability: does the sensor give the same reading for the same input, run to run? More important than absolute accuracy for many control tasks, where you can calibrate out a fixed offset but not a wandering one.

Rule of thumb: there is no free lunch between bandwidth, noise, and latency. You can have low noise (heavy filtering, high latency), high bandwidth (light filtering, more noise), or low latency (light filtering, more noise): pick two, and pick them to match your control loop, not the datasheet's hero number.

Reading a datasheet without getting fooled

A few traps to watch for:

• "Resolution" vs "accuracy." A 16-bit output does not mean 16 bits of accurate data: the lower bits are often pure noise. Look for the noise spec and ENOB; the ADC width alone tells you little.
• Typical vs guaranteed. Most sexy numbers are "typical" at 25 °C. The min/max-over-temperature numbers are what you design to.
• Conditions matter. Noise density is quoted at a stated bandwidth; F/T resolution is quoted single-axis. Read the footnotes.
• Full-scale percentages hide absolute errors. "0.5% FS" on a ±500 N sensor is ±2.5 N, possibly larger than the force you are trying to control.

Sensor fusion & state estimation overview

No single sensor gives a robot a complete, trustworthy picture of its state. Each has a blind spot: the gyro drifts, the accelerometer is noisy and confused by motion, the encoder is blind to base motion, the camera is slow and occasionally wrong, the current-based torque estimate is corrupted by friction. Sensor fusion is the art of combining them so the fused estimate is better than any input: each sensor covering another's weakness.

Why you fuse

The classic example is the IMU complementary filter from earlier: gyro (fast, drifty) plus accelerometer (slow, drift-free) yields attitude that is both fast and drift-free. Scale that idea up to a full robot and you get a state estimator that fuses:

• IMU (body attitude, angular rate, linear acceleration), fast, drifty
• Joint encoders (configuration), accurate, no drift, but only relative to the base
• Joint torques / contact forces, for contact events and ground-reaction estimation
• Wheel/leg odometry, position, drifty
• Vision/LiDAR fixes, absolute corrections, slow and occasional

into one coherent estimate of the robot's pose, velocity, and (for legged robots) contact state. The EKF or its error-state cousin is the standard machinery.

The take: no sensor is trustworthy, but their failure modes are uncorrelated, and that is the whole game. The gyro is wrong slowly, the accelerometer is wrong quickly, the encoder is blind to base motion, the camera is wrong occasionally but absolutely. Fusion arranges a committee whose members lie in different directions, so their errors cancel instead of compound. A good state estimator is a well-designed argument among liars.

Timing and synchronization: the silent killer

Here is the part that bites every team building their first multi-sensor robot. Fusion is only as good as your timing. When you combine a 1 kHz IMU with a 30 Hz camera and a torque reading arriving over CAN with jittery latency, you must know when each measurement was actually taken, not when it arrived at your code.

A measurement applied at the wrong time is worse than no measurement. Quantify it: a body moving at 1 m/s that is mis-timestamped by 5 ms is placed 5 mm wrong; a body rotating at 2 rad/s and mis-timestamped by the same 5 ms is 0.01 rad (0.6°) wrong in attitude, and on a humanoid balancing at 1 kHz that feeds a several-percent error into the integrated velocity used to place the next foot. The fixes are unglamorous but essential: hardware timestamping (latch the time the instant the sensor triggers, not when the interrupt is serviced), time synchronization across buses, and latency compensation for the fact that a measurement often describes a past state by the time it reaches the filter. On EtherCAT this is the distributed clocks mechanism, which disciplines every slave to a reference clock with sub-microsecond skew; on Ethernet it is IEEE 1588 (PTP); for cameras it is a hardware sync pulse. Latency compensation is done properly by out-of-sequence measurement handling: either buffer states and re-run the filter forward from the measurement's true time, or apply the delayed measurement as a correction to the stored past state and propagate. Applying a 30 ms-old camera fix as if it described now is a classic way to inject a phantom velocity that walks a robot sideways.

War story: a legged-robot team spent a week convinced their EKF was mistuned: the estimate converged on flat ground, then diverged the moment the robot trotted. It was not the tuning. The IMU rode a shared I²C bus behind two other chips, and under load the bus arbitration added tens of milliseconds of variable latency to its samples. The filter's R was fine; its clock was lying. Moving the IMU to a dedicated SPI line with a hardware timestamp fixed it in an afternoon.

Rule of thumb: budget your fusion as a timing problem first and a math problem second. Most "the EKF won't converge" failures are timestamp/latency bugs, not tuning bugs.

The role in legged and humanoid balance

For a wheeled robot, a wrong state estimate means a navigation error. For a legged or humanoid robot, it means a fall. Balancing inverted-pendulum dynamics demands a high-rate, low-latency estimate of body attitude, body velocity, and which feet are in contact, fused from IMU, joint encoders, and contact/force sensing. The contact-state estimate (which foot is on the ground, with what force) is itself a fusion problem, often using joint torque or foot force sensors. This is why legged robots run their state estimator at 500 Hz to 1 kHz with carefully synchronized sensors; the legged/quadruped guide and humanoid hardware guide go deeper on the dynamics this estimate feeds.

Selecting & integrating sensors

Pulling it together: choosing and wiring the self/contact sensing stack is a systems problem, and the failures are usually integration failures, not transducer failures.

Choose by the numbers, in order

1. Range: does it cover your worst case with headroom (and survive overload)?
2. Resolution at your operating point: is the smallest resolvable step fine enough where you actually work, given that specs are usually quoted at full scale?
3. Bandwidth and latency: fast enough for your control loop without adding destabilizing phase lag?
4. Noise and drift: quiet and stable enough that you are not fusing garbage?
5. Interface: does it fit your bus and timing model (below)?
6. Mechanical and environmental: size, mass, mounting, IP rating, temperature, vibration.

Sampling rate and bandwidth

Sample at least 2× the highest frequency you care about (Nyquist), and in practice 5 to 10× for clean control. A 1 kHz balance loop wants an IMU sampled at several kHz; a slow temperature monitor is happy at 1 Hz. Over-sampling and then filtering buys noise reduction; under-sampling aliases high-frequency noise into your band irreversibly. Anti-alias filtering before the ADC is not optional for analog sensors.

Interfaces: SPI vs I²C vs CAN vs EtherCAT

Interface	Typical use	Speed	Notes
I²C	IMUs, ToF, simple sensors	~100 kHz to 1 MHz	Cheap, multi-drop, but slow and not great for high-rate IMUs; addressing conflicts
SPI	High-rate IMUs, fast ADCs	up to tens of MHz	Fast, low-latency, point-to-point, the right choice for a 1 kHz+ IMU
Analog + ADC	Load cells, strain, NTC	n/a	Needs a clean amplifier and anti-alias filter; you own the noise
CAN / CAN-FD	Joint drives, F/T sensors, distributed nodes	1 to 8 Mbit/s	Rugged, multi-drop, deterministic-ish; standard on robot joints
EtherCAT	Industrial F/T, full robot buses	100 Mbit/s	Deterministic, hardware-synchronized (DC), the gold standard for synced multi-sensor robots
USB	Bench/research F/T, GelSight	n/a	Convenient, not real-time; fine for non-loop sensing

Rule of thumb: put your fast, loop-critical sensors (IMU, motor current, joint encoders) on SPI or a synchronized fieldbus (EtherCAT/CAN). Reserve I²C and USB for sensors that are not in a tight control loop. Mixing a high-rate IMU onto a shared I²C bus with five other devices is a classic self-inflicted latency wound.

Mounting matters more than you think

• IMU placement: mount rigidly, near the center of mass, away from vibration sources (motors, fans). Vibration aliases into the gyro and accel and no filter fully removes it; soft-mount the board if needed. A few degrees of mounting misalignment is a calibratable but real error.
• F/T sensors: mount stiffly between flange and tool, and account for tool weight and inertia: gravity and acceleration of the tool show up as forces you must compensate (the "payload calibration" step).
• Strain/load cells: protect against off-axis loads and overload; a load cell loaded sideways reads wrong and can be damaged.
• Magnetometers: keep them as far from motors, current-carrying wires, and ferrous structure as possible, and calibrate hard-iron/soft-iron in situ with the actual robot.

Calibration is not optional

Every sensor here needs calibration, and skipping it is the most common reason a "working" sensor gives bad data:

• IMU: gyro bias (re-zeroed at each startup while still), accel scale/bias (six-position tumble), magnetometer hard/soft-iron (figure-8 motion), and temperature compensation over a range.
• F/T: zero/bias before each force task (it drifts with temperature), plus the maker's calibration matrix and tool-payload compensation.
• Load cells/strain: tare and span with known weights.
• Tactile: per-taxel offset/gain; gel sensors need illumination and geometry calibration.

Rule of thumb: budget calibration as a recurring runtime procedure, not a one-time factory step. The sensors that drift (IMUs, F/T, strain) need to be re-zeroed in the field, and your software should make that a first-class operation, not a hack.

Frequently asked questions

What is the difference between proprioception and exteroception, and which sensors are which? Proprioception is the robot sensing its own body: joint angles (encoders), body attitude and rate (IMU), joint torque (current estimation or torque sensors). Exteroception is sensing the external world: cameras, LiDAR, depth, microphones. Force/torque and tactile sensors straddle the line (they measure the world's contact) but behave like proprioception in the control loop. This guide covers proprioception and contact; exteroception is in the LiDAR & depth cameras guide.

Do I need a 6-axis or a 9-axis IMU? Use a 6-axis (accel + gyro) if you have another absolute-heading source (vision/SLAM, wheel odometry, GPS) because those bound the yaw drift that a 6-axis IMU cannot fix on its own. Add the magnetometer (9-axis) only if you have no other heading reference and your environment is magnetically clean (away from big motors and ferrous structure). On most indoor robots near big motors, the magnetometer is more trouble than it is worth, and people bound yaw with vision instead.

Why does my robot's heading drift even though the IMU is "good"? Because yaw is unobservable from the accelerometer. Roll and pitch are corrected against gravity, but yaw rotates the robot around the gravity vector, which the accelerometer cannot see. With no magnetometer or vision fix, the integrated gyro heading drifts without bound. The fix is an absolute heading source, not a better gyro.

What is angle random walk and why should I care more than about range? ARW (°/√h) quantifies how fast the gyro's angle estimate drifts due to white noise during integration. It directly sets how long you can dead-reckon attitude before the error matters. Range (±250 to ±2000 °/s) only matters if you spin fast; ARW and bias instability determine accuracy for nearly every robot. Read them off an Allan-variance plot of your own hardware.

Can I get joint torque without a torque sensor? Yes, estimate it from motor current: τ ≈ Kt · Iq · N · η − τ_friction. The FOC controller already measures the q-axis current, so the estimate is essentially free and runs at full motor bandwidth. It is good enough for collision detection, gravity compensation, and hand-guiding (this is how most cobots work). It is not accurate for fine force control because friction, gear losses, and Kt variation corrupt it. For that, add a wrist F/T sensor or per-joint torque sensors.

What is crosstalk on an F/T sensor and how bad is it? Crosstalk (cross-axis coupling) is when a load on one axis produces a spurious reading on another, e.g. a pure Fz showing up as a small Fx or Tx. It is typically 1 to 5% of full scale on a good sensor. The manufacturer's calibration matrix corrects most of it, but residual crosstalk limits how cleanly you can resolve one axis while others are loaded. It matters most in multi-axis contact tasks like insertion.

GelSight vs BioTac vs a simple FSR: when do I use each? Use an FSR or barometric/capacitive array for cheap, robust grip-force and contact-presence sensing on a production gripper. Use a GelSight/DIGIT optical sensor when you need rich contact geometry, slip detection, and in-hand pose for dexterous manipulation research, accepting the bulk, camera latency, and compute. Use a SynTouch BioTac when you specifically want multimodal (pressure + vibration + thermal) biomimetic sensing, e.g. material recognition. Most production robots use the cheap array; the optical/biomimetic sensors are research and high-end dexterity tools.

How do I choose a sampling rate? At least 2× your highest frequency of interest (Nyquist), and 5 to 10× in practice for clean control. A 1 kHz control loop wants an IMU sampled at several kHz; a temperature monitor is fine at 1 Hz. Always anti-alias filter analog sensors before the ADC: under-sampling folds high-frequency noise into your band permanently.

SPI or I²C for my IMU? SPI, for anything in a tight control loop. I²C tops out around 1 MHz, is shared (adding latency and contention with other devices), and is awkward at high rates. SPI is point-to-point, runs at tens of MHz, and gives low, deterministic latency: exactly what a 1 kHz+ IMU needs. Save I²C for slow, non-loop sensors like a ToF ranger or a temperature chip.

Why does my F/T sensor reading drift during a task? Thermal zero drift. The strain bridges shift their zero as the sensor warms (from ambient, from nearby motors, from its own electronics), often by several newtons over minutes. Re-bias (tare) the sensor right before a force-sensitive operation, and prefer sensors with built-in temperature compensation if you cannot control the thermal environment.

Do I really need an EKF, or is a complementary filter enough? If your sensors are just an IMU (± magnetometer) and you want attitude, a Madgwick/Mahony complementary filter is enough and far simpler. Move to an EKF when you must fuse heterogeneous, time-stamped sensors (encoders, odometry, vision, GPS), when you need a covariance for downstream consumers, or when you want the filter to estimate and remove gyro bias as a state. Do not deploy an EKF to do a job a 20-line complementary filter does fine, but do not try to bolt vision and odometry onto a complementary filter either.

What is the single most common sensor-integration mistake? Timing. Multi-sensor fusion lives or dies on knowing when each measurement was actually taken, not when it arrived at your code. Most "the filter won't converge" or "the robot is unstable" problems trace to un-timestamped or wrongly-latency-compensated measurements, not to the transducers or the math. Budget hardware timestamping and time synchronization (EtherCAT DC, PTP, sync pulses) from the start.