Holonomic Drive: Move Sideways Without Turning
You can size, wire, code and debug a four-wheel holonomic drivetrain, and say honestly what it costs you in traction and in position accuracy.
What this path is for
Every driving robot on this site so far has had the same limitation and never mentioned it: it can only move along its own nose. To get 20 cm to the left it has to turn, drive, and turn back. That is a nonholonomic constraint, and it is so normal that most people never notice it is a constraint at all.
This path removes it. At the end you will have a robot with three independently controllable velocities — forward, sideways and rotation — built from four ordinary gearmotors and four wheels with rollers in them.
It also spends a lot of its length on what that costs, because the cost is real and rarely stated: about 29% of your traction, about 29% of your top speed on a diagonal, roughly double the bill of materials, and a serious downgrade in how much you can trust your own odometry. A holonomic base is an excellent answer to a specific question. This path is also about recognising when that was not your question.
What you need
| Item | Qty | Approx. cost | Notes |
|---|---|---|---|
| Mecanum wheels, 80–97 mm | 4 | £28–70 the set | Two left-handed, two right-handed. Buy them as a set of four |
| Gearmotor with encoder | 4 | £8–14 each | Matched, 100–250 rpm at the wheel. N20 for a small base, 25 mm gearmotors for a bigger one |
| Dual H-bridge (TB6612FNG or L298N) | 2 | £3–8 each | Or one four-channel board. TB6612FNG wastes far less voltage |
| Controller with 4 PWM + 4 interrupts | 1 | £8–20 | Arduino Mega 2560 or an ESP32. An Uno does not have enough of either |
| IMU (MPU6050 or better) | 1 | £2–20 | For field-oriented driving and heading hold |
| 2S or 3S battery pack | 1 | £12–25 | Sized for four motors, not two — see the power budget tutorial |
| Chassis plate | 1 | £10–25 | Or cut your own. Measure wheel centre to wheel centre when you do |
Around £90–170 all in, against £40–70 for an equivalent two-wheel robot.
Why the path runs in this order
Choose the drivetrain before you buy anything. The first node is a comparison, not a build step, because the most expensive mistake on this path is discovering after the chassis is drilled that a differential drive would have been better.
Kinematics before electronics. The four-line matrix explains what the four motors are for, why they are asked for such different speeds, and why the wheel ratios are the steering. Nothing about the wiring makes sense until that does.
The lab before the build. Fitting a wheel backwards is the single most common mecanum error, and it produces a robot that drives forward perfectly and strafes into a spiral. Doing it once in a browser, deliberately, is what makes you recognise it on the bench in thirty seconds instead of a day.
Velocity loops before anything autonomous. On a differential-drive robot open loop is a workable starting point. Here it is not, because there is no single trim constant that can fix four ratios that change with every command.
Field orientation last of the control work, because it is a hat on top of a drivetrain that already works. Adding it to a robot whose wheels do not hold their speeds just moves the confusion somewhere harder to find.
Checkpoints
Each stage has a bench test with a pass criterion. Do not carry a failure forward — on a four-motor robot the failures multiply.
| After | Test | A pass looks like |
|---|---|---|
| Wheels fitted | Stand over the robot, follow the top rollers | Four lines aiming at the centre, drawing an X |
| Motors wired | Command each wheel forward individually | All four wheels turn the way you called forward, with no wiring swap |
| Kinematics coded | Command a pure strafe with the robot on blocks | Diagonal pairs oppose; front-left and rear-right match |
| Encoders reading | Turn each wheel one revolution by hand | Counts within 2% of the computed counts/rev, and the sign is right |
| Velocity loop | Command 0.3 m/s on blocks, then press a finger on the wheel | Speed holds; PWM rises visibly on the telemetry line |
| Four loops together | Drive a 3 m straight line on the floor | Under 20 mm of lateral drift, repeatable |
| Strafing | Drive 1 m sideways and measure | Within 5 cm, and the heading has not changed more than a couple of degrees |
| IMU | Spin the robot 360° by hand | Yaw returns within 5°, with less than 3°/min of drift standing still |
| Field-oriented | Hold the stick forward and spin the robot | It keeps going the same way across the floor |
| Squares | Drive the strafing square, then the turning square | Both close; the strafing one holds heading to within a degree |
Where this path stops
Three deliberate omissions, named so you know they are choices.
Swerve drive. The only holonomic drivetrain that does not trade traction for freedom, and it costs eight motors, a steering controller per module, and real singularities. If your robot has to be holonomic and push hard, that is where to go, and it is a bigger project than this whole path.
Knowing where you are. This path is honest that mecanum odometry drifts and tells you to add an IMU and dead wheels. It does not cover absolute localisation. For that, follow path planning and mapping, which builds up through occupancy grids to SLAM.
Holonomic path following. Pure pursuit and Stanley both assume a robot that steers by turning, and a base that can move sideways can do strictly better than either. Adapting them properly is its own topic; until then, a holonomic base following a car-like controller works fine and simply leaves capability on the table.
Next
Start at holonomic drive types and decide whether you want this at all. Then build the mecanum omnidirectional robot.
Learning roadmap
The path
Follow the nodes in order—each unlocks the next once you have done it. Your progress saves on this device.
0 / 14 done
Common questions
Frequently asked questions
Do I need to learn differential drive before holonomic drive?
It helps a great deal and this path assumes some of it. The encoder reading, the velocity loop, the power budget and the slip problem are all the same skills a two-wheel robot needs, only with four of everything. What is genuinely new here is the kinematics — a differential robot has two controllable velocities and a holonomic one has three — and the frame question that comes with it. If you have never built a driving robot at all, build a line follower or an obstacle avoider first; you will spend your time on the new ideas instead of on soldering.
How much does a mecanum base cost compared to a normal robot?
Roughly double, and the increase is in places people forget. Four mecanum wheels run two to four times the price of four plain ones. You need four motors instead of two, so four H-bridge channels and four encoder cables, and four motors is about double the current budget. The controller usually has to grow as well: four encoders want four interrupt-capable pins and four PWM channels on separate timers, which an Arduino Uno does not have, so most builds end up on a Mega or an ESP32. Budget for the controller upgrade from the start rather than discovering it after the chassis is drilled.
Can I run mecanum wheels open loop without encoders?
You can drive it, and for a hand-driven robot on a good floor it is honestly fine. What you cannot do is go anywhere specific. The kinematics work by holding ratios between four wheel speeds, and open-loop PWM does not hold ratios — as the battery sags, as one motor warms up, as the load shifts, the ratios drift and the robot curves out of every command. On a differential-drive robot you can trim that away with one constant. On a holonomic base the correct ratio changes with every command, so there is nothing to trim. Encoders are what make the maths on this path true.
Why does this path spend so much time on odometry being wrong?
Because it is the failure people do not see coming. A mecanum base looks like the most capable robot you have built, and its dead reckoning is the worst. The rollers slipping is not a fault to fix — it is how sideways motion happens — so every millimetre of sideways travel is travel the encoder measured and the floor did not necessarily give you. Two tutorials on this path exist to make sure you plan for that from the start: add an IMU for heading, add unpowered dead wheels or an external reference for position, and never write an autonomous routine that assumes the drive encoders know where the robot is.
Where does this path stop?
At a robot you can drive anywhere on a flat floor, that holds the speeds it is commanded, that knows which way it is pointing, and that is honest about not knowing exactly where it is. It deliberately leaves out three things. Swerve drive, because eight motors and a steering singularity is a different project. Absolute localisation — SLAM, beacons, vision — which is where you go next if the robot must know its position; start with the path planning and mapping roadmap. And holonomic path following, because pure pursuit and Stanley both assume a robot that steers, and adapting them to a base that can move sideways changes the controller enough to deserve its own treatment.
What can I build at the end of it?
The mecanum omnidirectional robot project on this site is the direct target: a four-wheel base with a velocity loop per wheel, field-oriented driving, and a set of bench tests that tell you whether each part is actually working. Beyond that the same drivetrain is the base for anything that has to hold a heading while repositioning — a camera platform, a small warehouse mover, an inspection robot in a tight aisle, or a competition robot that needs to line up on something without pointing at it.