Robot Sensors: IMUs, Force/Torque & Proprioception — The Ultimate Guide

A robot that cannot sense itself is a puppet on an open-loop string. 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.

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 not the transducers but the noise, drift, calibration, timing, and fusion that turn raw counts into a trustworthy state estimate. 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; a MEMS gyro is a vibrating mass whose Coriolis-induced lateral motion is sensed capacitively when the chip rotates. The whole thing 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. A tactical- or navigation-grade FOG can hold bias to better than 0.01 °/h; a commodity MEMS gyro might be 10–100 °/h. 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 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: 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. Cut your bandwidth and you cut noise — at the cost of latency.

ARW is the term that tells you how badly the gyro drifts in the short term. A gyro with ARW of 0.3 °/√h accumulates about 0.3° of angle uncertainty after one hour from white noise alone — but the more honest reading for robotics is the per-second growth: that same gyro drifts on the order of 0.005°/√s, which compounds over a minute-long unaided integration.

Allan variance: reading all of this off one log

The Allan variance (or its square root, Allan deviation) is the standard tool for separating an IMU's noise terms. You log the gyro at rest for a long time (hours), then plot the Allan deviation against averaging time τ on a log-log scale. The curve has characteristic slopes:

• 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. Mahony uses a PI controller on the gravity/magnetic error to drive the gyro-bias estimate; Madgwick uses a gradient-descent step to align the predicted gravity (and magnetic) vector with the measurement. Both are cheap enough for an 8-bit MCU, both expose a single beta/Kp gain trading responsiveness against smoothness, and both are battle-tested. 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. Because attitude/orientation is nonlinear (quaternions, trig), you use the Extended Kalman Filter (EKF), which linearizes around the current estimate, or the Unscented Kalman Filter (UKF) / an error-state EKF (ESEKF) for better handling of the nonlinearity.

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 (this is where your Allan-variance numbers go). 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). When force or torque deforms the element, the gauges change resistance; arranged in Wheatstone bridges, those tiny resistance changes become voltages. Six (or more) bridges, a calibration matrix, and you decode the full 6-DOF wrench.

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–5% of full scale
Overload rating	Force beyond which the element yields or breaks	A collision can exceed full scale by 5–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	±50 N / ±0.5 N·m	Tiny (17 mm), fingertip-scale, very high resolution
ATI Gamma	Strain gauge	±400 N / ±20 N·m	Industrial workhorse for arm wrists
Robotiq FT 300-S	Strain gauge	±300 N / ±30 N·m	Plug-and-play for UR cobots, integrated comms
Bota Systems Rokubi / MiniONE	Capacitive (some w/ IMU)	±200–500 N / ±5–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 motor controller already measures Iq precisely to run field-oriented control (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. The estimate Kt · Iq · N · η is corrupted by:

• Friction — Coulomb (constant) and viscous (speed-dependent) friction in the bearings and gearbox. This dominates the error and must be modeled or learned per joint.
• Gear efficiency — harmonic and cycloidal drives lose 10–40% of torque, and the loss varies with load, speed, and temperature.
• Kt variation — the torque constant drifts with temperature (magnet strength) and is not perfectly known.
• Backlash and elasticity — the gearbox is not a rigid link; under dynamic loads the relationship smears.

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.

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) 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 the spring adds shock tolerance and intrinsic compliance. The downside is the spring reduces control bandwidth and stiffness. 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. A GelSight sensor is, in essence, a small camera looking up at the underside of a soft, coated elastomer pad through internal illumination. When the pad presses against an object, it deforms to the object's shape; the camera images that deformation. Photometric-stereo reconstruction turns the image into a height map with sub-10-micron depth resolution — you can read the embossing on a coin, detect the onset of slip from shear deformation of printed markers, and estimate contact force from the bulk deformation.

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.

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 changing under sustained load), and nonlinearity. A load cell needs a stable, low-noise amplifier; the HX711 24-bit ADC is the ubiquitous cheap front end, while industrial setups use proper bridge amplifiers.

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. The dominant family is ST Microelectronics' VL53 line (VL53L0X, VL53L1X, VL53L4CX, VL53L8 multizone): 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.

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 are a wide beam cone (poor angular resolution), slow update (sound is slow — ~340 m/s, so a 1 m round trip is ~6 ms), and trouble with sound-absorbing or angled targets. 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–4 m	mm-class	Cheap precise short range	Dark/angled/transparent, sunlight
Ultrasonic	2 cm–4 m	cm-class	Glass, shiny, transparent	Angular resolution, speed
IR reflective	1–80 cm	coarse	Ultra-cheap presence	Surface color/reflectivity
Inductive prox	1–15 mm	binary	Rugged metal detection	Only metals, very short range
Capacitive prox	1–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–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, not just the room-temperature number.
• 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, not just the ADC width.
• 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.

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. On a humanoid balancing at 1 kHz, a 5 ms timing error on the IMU is a several-percent error in the integrated velocity used for the next step — enough to walk the robot off the edge of stable. The fixes are unglamorous but essential: hardware timestamping (latch the time the instant the sensor triggers), time synchronization across buses (PTP/IEEE-1588 on EtherCAT, sync pulses for cameras), and latency compensation (apply a delayed measurement as a correction to a past state, not the present one).

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–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, not just 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–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–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	—	Needs a clean amplifier and anti-alias filter; you own the noise
CAN / CAN-FD	Joint drives, F/T sensors, distributed nodes	1–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	—	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–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–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.