Why SLAM uses wheel odometry instead of IMU alone

You are building SLAM for an indoor robot that carries a 2D LiDAR, an IMU and a camera, and every algorithm you look at asks for wheel odometry before it will run. That request is not a styling choice: it comes from how the two sensors fail. Position from an IMU takes a double integration, so its error grows with the square of time, while encoder error grows with distance travelled. Below are the error equations, a worked 60-second example at office speed, the role each sensor plays in the stack, and the decision for each platform type.

The short answer: odometry as the motion model, IMU for attitude

Run SLAM on odometry. Wheel encoders measure displacement directly, so their error accumulates with distance travelled — plan on 1-3% of distance for an indoor differential drive before calibration, near 1% after. An IMU cannot measure position at all: it measures acceleration, and turning acceleration into position needs two integrations, which turns any constant bias into an error of 0.5·b·t². A residual bias of just 0.01 m/s² puts the estimated pose 18 m off after 60 s. The IMU still earns its place: pitch, roll and angular rate at hundreds of hertz, which wheels cannot supply. Fuse the two — wheel odometry, IMU and visual odometry through an EKF is the standard arrangement — and let scan matching plus loop closures bound whatever drift remains.

What an IMU must do to give position

An accelerometer outputs specific force: acceleration with gravity mixed in. To get velocity you subtract gravity and integrate; to get position you integrate again. Every error in that chain compounds:

Three terms matter indoors. A residual accelerometer bias builds position error as 0.5·ba·t². A gyro bias rotates the heading estimate at bg radians per second, and a heading error ψ displaces the position estimate by roughly distance × ψ. Random noise adds a slower random-walk term on top. For a consumer MEMS unit indoors, plan on 1-5 mg of residual accelerometer bias (0.01-0.05 m/s²) and, before a static calibration, 0.1-1°/s of gyro bias. The quadratic term punishes wall-clock time: stretch the uncorrected interval from 60 s to 120 s and 18 m becomes 72 m. If your IMU drift runs ahead of this arithmetic, the bias estimate is the first suspect — fixing IMU linear acceleration drift works through it.

What wheel odometry measures directly

A wheel encoder counts rotation; multiplied by wheel radius, that is displacement, not a derivative of it. Two systematic errors dominate: wheel-radius error, which scales every distance, and wheelbase error on a differential drive, which injects heading error each time the robot turns. With slip and quantization added, the planning rule lands at 1-3% of distance travelled on hard indoor floors, near 1% after a straight-line scale correction and a square-path wheelbase correction.

The shape of that equation is the point. Error scales with distance, not time: a robot parked for an hour accumulates nothing, while IMU-only error quadruples with every doubling of time. Heading is usually the larger half — 0.5° of heading error across 24 m of travel displaces the endpoint by 24 × 0.0087 = 0.21 m — which is why the square-path calibration pays back more than a better encoder does.

Worked example: 60 seconds of dead reckoning

Office robot, constant 0.4 m/s, 60 s without a correction: d = 0.4 m/s × 60 s = 24 m.

IMU only, accelerometer bias ba = 0.01 m/s²: e = 0.5 × 0.01 m/s² × (60 s)² = 0.5 × 0.01 × 3600 m = 18 m.

IMU only, gyro bias bg = 0.5°/s = 0.0087 rad/s: heading error = 0.0087 rad/s × 60 s = 0.52 rad ≈ 30°; position error ≈ 0.5 × 0.4 m/s × 0.0087 rad/s × (60 s)² = 6.3 m.

Wheel odometry, k = 2%: e = 0.02 × 24 m = 0.48 m, plus the 0.21 m heading term — under 0.7 m total.

Same minute, same robot: meters versus half a meter. In an office the scan matcher finds usable geometry every second or two, so the real correction interval is far shorter than 60 s — the absolute numbers shrink and the ratio does not.

What moves the error numbers

Four inputs set where in the ranges you land, and each has a short fix:

• Wheel radius. A 1% radius error is a 1% distance error. Drive a measured 10 m line, divide endpoint error by distance, correct once.
• Wheelbase. Shows up only while turning. Drive a 2 m square, measure the return offset, correct, repeat until it stops shrinking.
• Surface and driving style. Carpet, dust and hard cornering under a heavy payload push slip toward 3%; smooth moves on hard floors hold 1-2%.
• Gyro bias. Log the IMU at rest for 60 s at power-up and subtract the mean; the quadratic heading term drops about an order of magnitude.

Encoder hardware itself is the smaller half of the problem. Selection matters most when a belt or chain sits between motor and wheel, because backlash corrupts the counts — choosing wheel encoders for chain-driven odometry walks through that case.

The role each sensor plays in a SLAM stack

Scan-matching SLAM needs three services from the rest of the stack:

1. Prediction. Odometry tells the matcher where the robot probably is, at 20-100 Hz on a typical robot, so each scan is searched against a tight window instead of the whole map. Without it, repetitive walls and blank corridors offer several plausible matches and the matcher can take the wrong one.
2. Attitude between wheel updates. The IMU, at 100-1000 Hz on typical controllers, carries pitch, roll and angular rate between encoder samples and separates gravity from linear acceleration.
3. Global correction. Loop closures — from LiDAR appearance or camera features — pull accumulated drift back each time the robot revisits mapped area. With few dynamic objects, 2D scan matching does most of the work indoors and the camera adds visual loop closures where geometry alone is ambiguous: glass fronts, long blank corridors.

Wiring the encoder stream into the LiDAR side is mostly topic and frame configuration — setting up LiDAR SLAM with wheel encoder odometry goes end to end. Keep timestamps honest while you are there: a few milliseconds of skew between camera and IMU reads as fusion lag, which IMU and camera time synchronization for visual SLAM measures and fixes.

When the IMU should carry more weight

• Short gaps. If absolute updates pause for a second or two — a wheel lifts, a sunlit window blinds the camera — hold pose with the IMU and reject the wheels for that interval; the quadratic term needs minutes to matter.
• Wheels that slip by design. Omni and mecanum wheels slide sideways as part of normal motion, so encoder-only odometry under-reports lateral travel. Fixing omni-wheel odometry with encoders and an IMU shows the fusion that recovers it.
• Tracked and heavy platforms. Tracks slip under load the way omni wheels do; down-weight the wheels and close loops more often.

What never works is IMU-only position across minutes: the 18 m in the worked example is the friendly end of the range.

Adding a depth camera for visual odometry

A plain 2D camera contributes appearance — features that make good loop closures — but its motion estimate carries no metric scale on its own; what visual odometry and depth mapping cameras provide breaks that down. To make the camera side contribute odometry as well, close the scale gap with depth: a compact ToF depth camera supplies metric depth per frame, so the visual motion estimate is scaled and its loop-closure constraints carry distance information.

The 3D sensor category also holds laser profilers and structured-light stereo cameras for short-range, high-accuracy depth, and an area scan camera slots in when the same station wants high-resolution RGB as well. Depth-camera 6DOF tracking with fused IMU and depth odometry shows the fusion pattern for exactly this combination.

Checks before you trust the numbers

Run these five on the bench; each takes minutes and each attacks one term you have now quantified:

1. Static bias log. IMU at rest, 60 s: the gyro means are your biases; subtract them from every reading.
2. Scale run. 10 m measured line, odometry endpoint against the tape: radius correction to under 1%.
3. Square path. 2 m sides, five laps each direction: the return offset exposes wheelbase error, and the clockwise-versus-counter-clockwise difference separates it from diameter error.
4. Matcher cross-check. Compare odometry-only pose against scan-matched pose over a known lap; the divergence rate sets how often loop closures must fire.
5. Timestamp audit. Print one second of sensor timestamps; skew above a few milliseconds shows up as fusion lag — PTP timestamp sync for GigE cameras, LiDAR and IMU covers wired synchronization.

The decision by platform

• Office differential drive with 2D LiDAR, IMU and camera — the case in front of you: odometry as the motion model, error-state Kalman filter (ESKF) fusion of IMU and wheels, scan matching for local pose, visual loop closures for the global bound. Expect centimeter-level local accuracy and drift that stays bounded for as long as the robot keeps revisiting mapped area.
• Omni or mecanum drive — same stack, IMU weighted up, wheels trusted mainly along their roll axis, loop closures more frequent.
• Tracked or slip-prone platform — wheels carry the least weight; LiDAR matching and IMU hold pose between closures.
• No encoders fitted — add them. Per the worked example, a pair of encoders and a calibration afternoon are worth one to two orders of magnitude of drift, the largest accuracy gain per hour of work on the whole robot.

When you specify the camera side of that stack, the camera finder filters by interface, resolution and shutter, the configurator's camera step pairs the sensor with a lens, and the systems topic page collects the rest of the localization guides. If your parts list mixes inspection cameras with localization sensors, describe the build on the contact page and we will help you match them.