Sensors: How Robots Perceive

A blindfolded person can barely walk across a room; a robot with no sensors is just expensive metalwork. Every decision a robot makes is only as trustworthy as the data its sensors supply. Garbage in, garbage out — and in robotics, garbage out can mean a bent wrist or a toppled shelf of products.

Sensors split into two fundamental families:

• Proprioceptive sensors measure the robot's own internal state — motor speed, joint angle, battery voltage, body tilt.
• Exteroceptive sensors measure the outside world — distances to walls, ambient light, the weight of a grasped object.

A well-designed robot uses both families together. An arm that knows its joint angles (proprioceptive) but can't feel when it's gripping too hard (exteroceptive force sensor) will crush every fragile part it touches. Balance is the goal, not maximum sensor count — every sensor adds wiring, latency, and complexity.

Before choosing any sensor, engineers evaluate it on four axes:

These four metrics trade off against each other and against cost. A high-resolution, low-noise, wide-range, fast sensor is expensive. Real engineering is choosing which metrics matter most for a given task — and living with the compromises on the others.

An encoder measures rotation — how far a shaft or wheel has turned. It's the most common proprioceptive sensor in robotics. The two main types are:

• Incremental encoder: produces pulses as the shaft rotates; you count pulses from a known reference position. Loses position if power is cut.
• Absolute encoder: outputs the actual angular position at all times; survives power cycles.

A typical incremental encoder on a hobby robot wheel might give 360 pulses per revolution (PPR). With a 6 cm diameter wheel, one pulse represents $\pi \times 6 / 360 \approx 0.052$ cm of travel. Higher PPR means finer resolution but also faster pulse counting. Here's how to read an encoder on an Arduino:

volatile long count = 0;
void encoderISR() { count++; }  // interrupt fires on each pulse
void setup() {
  attachInterrupt(digitalPinToInterrupt(2), encoderISR, RISING);
}
void loop() {
  float dist_cm = count * (PI * 6.0 / 360.0);
}

Encoders don't feel slip — if a wheel skids, the count is wrong.

An Inertial Measurement Unit (IMU) bundles two (or three) sensors into one chip:

• Accelerometer — measures linear acceleration along each axis (in $m/s^2$). Gravity counts as acceleration, so a stationary IMU reads 9.8 m/s² pointing downward — which is how it estimates tilt.
• Gyroscope — measures angular velocity (in °/s or rad/s). Integrate over time to get orientation angle.
• Magnetometer (optional) — measures magnetic field direction to give an absolute heading, like a compass.

The catch: gyroscopes drift. Every small measurement error accumulates when you integrate. After 30 seconds, a consumer gyroscope might report 5° of phantom rotation. This is called gyro drift or integration drift, and it's why drones, phones, and cars fuse IMU data with GPS or visual odometry rather than relying on the gyro alone. The art of combining noisy sensor streams is called sensor fusion, and it's one of the richest problems in robotics.

Range sensors let a robot answer: how far away is that wall? Three technologies dominate:

Ultrasonic sensors are the Hello World of robotics sensing: a $2 HC-SR04 can tell an Arduino-driven car not to hit a wall. LiDAR is what gives a self-driving car its detailed 3D map of the road. Same principle — time of flight — but orders of magnitude apart in speed, resolution, and cost.

Cameras capture 2D images (or 3D stereo depth) at high resolution — a modern robot camera might produce $640 \times 480$ pixels at 60 Hz, giving 18 million data points per second. That richness is both the superpower and the problem: interpreting an image requires substantial compute.

Four camera variants appear in robotics:

• Monocular — one lens, 2D image. Cheap, but depth is ambiguous without additional processing.
• Stereo — two lenses separated horizontally. The disparity between the two images encodes depth, like human binocular vision. Accuracy degrades with distance.
• Depth (RGB-D) — combines a color camera with an infrared structured-light depth sensor (e.g., Intel RealSense, Kinect). Direct per-pixel depth at short range.
• Event camera — records only pixel-level brightness changes asynchronously; ultra-low latency and no motion blur, useful for high-speed robotics.

Camera data almost always requires preprocessing — undistortion, noise filtering, feature extraction — before the controller can act on it.

A robot that can't feel force is dangerous around humans and fragile objects. Force/torque (F/T) sensors measure the loads applied at a robot's wrist or fingertips, typically using strain gauges — thin metal strips whose electrical resistance changes when they bend.

Applications where F/T sensors are non-negotiable:

• Assembly tasks: pressing a peg into a hole requires knowing when contact is made and how hard to push.
• Human-robot collaboration: the robot must yield when a person pushes on it, not fight back.
• Grinding or polishing: maintaining a constant contact force regardless of surface irregularities.

A lighter-weight alternative is current sensing — measuring the motor current, which is proportional to torque. Industrial robots like the KUKA LBR iiwa embed current sensors in every joint, enabling compliance without external F/T hardware. This approach is less accurate but far cheaper and lighter.

Every sensor fails in characteristic ways worth memorizing:

The engineering response to imperfect sensors is redundancy and fusion. Use multiple sensor types that fail in different ways, and combine their outputs using algorithms like Kalman filters or particle filters. When one sensor is fooled, another compensates. No individual reading is trusted blindly — all readings are evidence, weighted by estimated reliability.

A sensor is never chosen in isolation — it must match the task, the environment, and the budget. Here's a quick decision framework:

1. What physical quantity do you need? Speed → encoder or IMU. Distance → ultrasonic/LiDAR. Visual scene → camera.
2. What is the required range and resolution? A warehouse navigation task needs 10 cm accuracy over 20 m; a surgical robot needs 0.1 mm accuracy over 30 cm.
3. What is the environment like? Dusty/wet environments kill open optical encoders. Bright sunlight saturates some IR sensors. Metallic surfaces scramble magnetic encoders.
4. What is the loop rate requirement? Control loops running at 1 kHz need sensors sampling at least that fast, or you're interpolating blind.

Before writing a line of control code, sketch your sensor suite and annotate each sensor with its resolution, range, noise, and sample rate. Mismatched sensors account for a surprising fraction of robotics project failures.

Here is a snapshot of how a typical mobile robot uses multiple sensor families simultaneously:

# Pseudocode: one control cycle on a differential-drive robot
encoder_ticks = read_encoders()        # proprioceptive: wheel travel
imu_angle     = read_imu_yaw()         # proprioceptive: heading
lidar_scan    = read_lidar()           # exteroceptive: obstacle distances

# Fuse encoder + IMU into an estimated pose
pose = odometry_update(encoder_ticks, imu_angle)

# Check for obstacles in the path
if nearest_obstacle(lidar_scan) < 0.3:  # 30 cm threshold
    cmd_velocity = stop()
else:
    cmd_velocity = drive_toward_goal(pose, goal)

send_motor_commands(cmd_velocity)

Notice each sensor plays a distinct role: encoders track distance traveled, the IMU tracks heading, and LiDAR detects the environment. A failure in any one stream degrades performance in a predictable way — which is why you instrument each stream with sanity checks and fallback behaviors in production code.