Build a Mecanum Robot That Drives Sideways

What you are building

A four-wheel robot that can move in any direction on the floor without turning first, and can turn without changing where it is going. Push it sideways down an aisle it barely fits in; hold a camera pointed at something while orbiting it; correct 3 cm off a line by stepping 3 cm, instead of arcing out and arcing back.

This is the first robot on this site with three independently controllable velocities instead of two. It is also the first one whose drivetrain is genuinely harder than its sensors, which is why almost the whole build is motors, encoders and control loops.

The acceptance test is deliberately blunt: drive a 1 m square by strafing, and come home within 5 cm with the heading unchanged. No differential-drive robot can attempt that test at all.

The number that runs the project

Everything on this build comes back to one constant:

k = lx + ly

where lx is half the wheelbase (front axle to rear axle, halved) and ly is half the track (left wheels to right wheels, halved). On the reference build, 75 mm and 85 mm, so k = 0.160 m.

That single number couples rotation to the wheels. Get it wrong and the robot still drives — but a pure spin command creeps across the floor, and a pure strafe curves, because rotation and translation are bleeding into each other. Measure wheel centre to wheel centre, not the chassis plate, which is usually wider than you think.

The other numbers worth writing on the chassis in marker before you start:

Bill of materials

£90–170 total. The wheels and the fourfold motor count are where a two-wheel robot’s £50 becomes this.

How it all connects

        2S LiPo ──┬── 470 µF ── TB6612FNG #1 ── FL motor ── FL encoder ─┐
                  │                         └── FR motor ── FR encoder ─┤
                  ├── 470 µF ── TB6612FNG #2 ── RL motor ── RL encoder ─┼── ESP32
                  │                         └── RR motor ── RR encoder ─┘   (4 PWM,
                  └── 5 V BEC ──────────────────────────────── ESP32 ──────  8 GPIO,
                                                                   │         I²C)
                                                   MPU6050 ── I²C ─┘

Three wiring decisions that are not obvious:

• The ESP32 gets its own regulator. Four motors starting together drop the pack hard, and a controller sharing that rail browns out and reboots mid-command. It looks exactly like a firmware crash. Read the power budget tutorial before blaming your code.
• A bulk capacitor across each driver. 470 µF close to the board. H-bridges draw in bursts and the lead inductance turns those bursts into spikes.
• The IMU goes on the centre line, flat, and as far from the motors as the plate allows. Yaw drift is bad enough without a magnetic field from four motors in it.

Build it in milestones

Each one has a test. Do not carry a failure forward — on a four-motor robot they multiply.

1. Wheels on, and the X check

Bolt the four wheels on and stand directly over the robot. Follow the line of the rollers you can see on top of each wheel.

Test: those four lines aim at the middle of the robot and draw an X. If they draw a diamond, swap two wheels diagonally. Pass: an X. This is a five-second check that saves a day.

2. Each motor individually

Wire all four, and write a sketch that drives one wheel at a time at 40% for a second.

Test: call each one and confirm the right wheel turns the right way. Pass: four wheels, four correct directions, no swapped pairs. Fix wiring in hardware, not with minus signs in code — you will lose track.

3. Encoders

One revolution of each wheel, turned by hand.

Test: print the count. Pass: within 2% of 1440, and positive when the wheel turns forward. A count that jumps or runs backwards means you are interrupting on one channel instead of two, or reading a volatile long without disabling interrupts.

4. Kinematics on blocks

Put the robot on blocks and command a pure strafe.

Test: diagonal pairs oppose — front-left and rear-right go one way, front-right and rear-left the other. Pass: that exact pattern. Then command a pure spin: left side one way, right side the other. If a wheel disagrees, it is in the wrong corner and step 1 lied to you.

5. One velocity loop

Tune feedforward then PI on a single wheel, on blocks, then under load.

Test: command 0.3 m/s and press a finger on the tyre. Pass: the speed holds and the PWM visibly rises. Do this once properly; the other three are copies with their own kS and kV.

6. All four, straight line

Four loops, 100 Hz, on the floor. Drive 3 m straight.

Test: measure the lateral drift at the end. Pass: under 20 mm, and repeatable across three runs. Open loop this is typically 80–200 mm and different every time.

7. Strafe 1 m

Test: drive exactly one metre sideways and measure both the distance and the heading change. Pass: within 5 cm, heading within 3°. A consistent curve means the k constant is wrong; a random one means a velocity loop is not holding.

8. IMU and field-oriented

Bias-calibrate at boot, add the heading reset button.

Test: hold the stick forward and spin the robot by hand through a full turn. Pass: it keeps travelling the same way across the floor. Standing still, yaw drifts less than 3° per minute.

9. The square

The acceptance test. Drive 1 m forward, 1 m right, 1 m back, 1 m left, with no rotation commanded anywhere.

Test: distance from the start point, and heading change. Pass: within 5 cm and 3°.

What good looks like

That last row is honest rather than disappointing. On this drivetrain the rollers slipping is the mechanism, so the odometry is the weakest number on the robot even when everything works. Build the expectation in rather than chasing it.

Hardware notes that matter

Wheel handedness is a set property. Two singles ordered separately from the same listing are very often the same hand. Check before you drill anything.

Every roller must spin freely. Flick each one by hand before the wheels go on. A seized roller turns that corner into an ordinary wheel pointing 45° off, intermittently, which reads exactly like a software bug.

Mecanum wheels are heavy. 180–400 g each, so up to 1.6 kg of the robot is wheels, and that is rotating mass on the ends of the moment arms. It makes the robot feel sluggish and it is why the acceleration ceiling matters.

The floor is a component. Polished concrete and vinyl are around μ = 0.8. A dusty gym floor, a coat of hairspray somebody used on a different robot, or a join in the lino will halve it locally, and the robot will change behaviour as it crosses. Watch what μ = 0.25 does before you blame the tuning.

When it goes wrong

Where to take it next

Dead wheels. Two or three unpowered omni wheels on spring mounts, with their own encoders. They carry no torque so they do not slip, and they turn the worst number on this robot into the best one.

Holonomic path following. Pure pursuit and Stanley assume a robot that steers. A base that can strafe can do better — track the path position and the heading independently, because you have separate actuators for them.

A camera on a base that holds heading. The natural pairing: a vision pipeline is far easier when the camera can stay pointed at the target while the base repositions. That is the thing holonomic drive is actually for.

ROS 2. This drivetrain is the first one here where cmd_vel’s linear.y — explicitly ignored by a differential-drive robot — finally means something. Swapping the twist-to-wheels function for the four-row mecanum version is most of the work.