Motor Control for Robots: A Learning Roadmap
Drive two motors with precise speed and direction, read how far they have turned, and steer a differential-drive robot.
Motors are where a robot’s decisions become motion. This roadmap builds motor control from the ground up: first switch real motor current safely with an H-bridge and PWM, then close the loop by reading encoders so you know how far and how fast each wheel has turned, and finally combine two wheels into differential-drive steering and odometry.
Work through the nodes in order—each unlocks the next once you have done it. By the end you can command a robot’s wheels with real precision, the foundation for line following, maze solving, and autonomous navigation.
Before you start
You need to be comfortable wiring a breadboard and reading a voltage, and you need a microcontroller you can already flash — an Arduino Uno is the usual choice. No control theory is required; that is what the PID path is for, and it expects this one first.
What you will be able to do
- Drive a brushed DC motor in both directions at a commanded speed, without the driver or the board getting warm.
- Explain why a motor sits still at 15% duty and starts moving at 30%, and measure that threshold for your own hardware instead of guessing it.
- Convert raw encoder pulses into millimetres travelled and millimetres per second, including getting the ×4 quadrature factor right.
- Turn “pivot left 90°” into a left and right wheel speed, and predict where the robot ends up from wheel motion alone.
- Size a gearmotor from your robot’s own mass and wheels, rather than buying the one in the kit and finding out on the carpet.
- Measure your gearbox’s backlash in degrees, and say what it costs your odometry.
- Work out the largest force your robot can put on the floor, and say whether the motors or the tyres are the thing stopping you.
Where people get stuck
Powering the motors from the controller’s 5 V rail. This is the single most common failure on a first robot. The regulator cannot supply motor current, so the rail dips, the board browns out and resets, and the symptom looks like a software bug. Motors get their own supply; only the driver’s logic side shares the board’s 5 V — the power budget page has the arithmetic and the measurement.
No common ground. The driver and the controller must share a ground reference or the direction pins mean nothing. Everything looks wired correctly and nothing moves.
Expecting odometry to stay true. Wheel odometry drifts without bound — every slip and every millimetre of wheel-diameter error accumulates and is never corrected. It is excellent over a metre and worthless over a hundred. That limitation is the reason the mapping path exists.
Counting encoder edges inconsistently. A quadrature encoder gives four countable edges per cycle. Counting one and using the datasheet’s ×4 figure puts every distance out by a factor of four, which reads as a wildly miscalibrated wheel.
Blaming the controller for the gearbox. Error that changes sign with direction is mechanical, not a tuning fault. A gear train has play, it is charged once at every reversal, and an encoder mounted on the motor shaft cannot see any of it.
What you need
| What | Why this path needs it | Notes |
|---|---|---|
| Two DC gearmotors | The subject of the whole path | Encoder versions cost a little more and save a rebuild later |
| A motor driver | An H-bridge, so a logic pin can command motor current | L298N if it came in the kit, TB6612FNG if you are buying |
| A separate motor battery | The rail the motors pull down must not be the one the board runs on | Any pack that can supply stall current |
| A multimeter | Measuring stall current and supply sag | Current mode matters here, not just volts |
| A tape measure | Checking that “drive 1 m” produced 1 m | The cheapest and most honest instrument on the bench |
Why the path runs in this order
Sizing comes before wiring on purpose. Almost every “my robot is too slow” or “my driver burned out” question is a sizing decision made by accident, months earlier, by using whatever motor was in the box. Working out the torque your own robot needs takes twenty minutes and settles questions the rest of the path would otherwise keep raising.
Traction comes immediately after sizing because it sets the second ceiling, and on a small robot it is the lower one. Stall torque says what the motor can produce; friction says what the floor will accept. A light robot on a smooth floor hits the traction limit at roughly a quarter of stall torque, which means the last three-quarters of your motor’s capability cannot reach the ground at all. Sizing without traction gives you a robot that is strong on paper and spins its wheels in practice.
PWM comes before encoders because an open-loop motor is the simplest thing that can be wrong, and it is much easier to debug a wiring fault when there is no control loop layered on top of it. Get both wheels turning both directions at a commanded duty first.
Encoders come before differential drive because differential drive is arithmetic on top of measured wheel motion. Without encoders you can steer, but you cannot say where the robot went, and the odometry half of that node has nothing to work with.
Profiles and the two loss nodes come last because each is a correction to something the earlier nodes let you believe. Motion profiles correct the idea that you can command a position directly. Wheel slip corrects the idea that the encoder measures the ground. Backlash corrects the idea that the encoder measures the wheel. All three are disappointments, and all three are cheaper to learn here than on a robot you are trying to finish.
Checkpoints: how to know a stage landed
| Stage | The check | What a pass looks like |
|---|---|---|
| Motor sizing | Compute required torque from your robot’s mass, wheel radius and target acceleration | A number in N·m you can compare against a datasheet — and you know your motor’s stall current |
| Traction limit | Hold the robot still against a kitchen scale at full throttle | The reading plateaus well below the motor’s stall force, and the wheels are turning |
| PWM control | Sweep duty from 0 to 255 in steps of 5 on each wheel | You can name the duty at which each wheel first turns, and the two numbers differ |
| Direction control | Command forward, reverse, and brake on both channels | All six states behave, and you can explain what brake does differently from coast |
| Encoders | Push the robot exactly 1 m by hand and read the counts | Counts convert to 1000 mm ± 20 mm, using the ×4 quadrature factor |
| Differential drive | Command a 90° pivot, measure with a protractor | Within a few degrees, and repeatable — a consistent error is backlash, a random one is slip |
| Motion profiles | Command a short move and a long one with the same limits | The short move never reaches top speed, and you can say why from the profile shape |
| Backlash | Rotate the wheel by hand to the point of resistance in each direction | You have a number in degrees, and it is not zero |
Where this path stops
This path stops at commanding motion accurately. It does not close a loop around an external goal — no line to follow, no wall to hold, no setpoint to converge on. That is PID control, and it assumes everything here.
Three deliberate omissions worth naming. Brushless motors and ESCs are a different control problem, and almost no small ground robot needs one. Stepper motors trade the encoder for open-loop position at the cost of torque and speed, which is the right trade for a printer and the wrong one for a rover — they have their own path in precision motion with steppers. Holonomic drivetrains — mecanum and omni wheels that can move sideways — need four independently controlled wheels and a different set of kinematics, and they have their own path in holonomic drive. And current sensing — measuring what the motor is actually drawing, rather than what you commanded — is the professional way to detect a stall, and it is genuinely useful, but it needs hardware most starter drivers do not have.
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 / 13 done
Common questions
Frequently asked questions
What do I need to learn to control a robot's motors?
Four layers, in order. First, sizing: turning your robot's mass and wheel diameter into the torque and RPM you actually need, so the motor is chosen rather than inherited from a kit. Second, switching: an H-bridge and PWM, which let a logic pin control a current it could never supply. Third, measurement: an encoder, so the robot knows how far each wheel turned instead of assuming. Fourth, combination: differential drive, which turns two wheel speeds into a heading and a position. Everything after that—line following, PID, navigation—is built on those four.
Why does my motor not move until about 30% PWM duty?
Static friction and gearbox stiction have to be overcome before anything turns, and below that threshold the motor just sits there humming. The value is a property of your specific hardware—gearbox ratio, bearing condition, temperature, and how much weight is on the wheels—so it has to be measured, not looked up. Ramp the duty up in steps of 5 and note where each wheel first turns. Robots often have two different thresholds, one per side, and a robot that veers at low speed is usually showing you that difference rather than a steering bug.
How accurate is wheel odometry?
Excellent over a metre and worthless over a hundred. Odometry integrates wheel motion, so every error it makes is permanent—there is no measurement that ever corrects it. Random slip grows as the square root of distance, which is survivable, but systematic error such as a wheel diameter that is 1% off grows linearly, which is not. The practical consequence is that odometry is the right tool for closing a control loop over the next few seconds, and the wrong tool for knowing where you are after five minutes.
L298N or TB6612FNG — which motor driver should I use?
TB6612FNG for almost any small robot. Its MOSFET output stage drops around 0.5 V against the L298N's roughly 2 V, and on a 6 V motor that difference is a third of your supply burnt as heat before the motor sees it. The L298N earns its place when you need more than about 1.2 A per channel continuously, or when the motor supply is above the TB6612FNG's 13.5 V limit. It is also what most kits ship with, so it is worth knowing well even if you replace it.
Do I need encoders on a beginner robot?
Not for a line follower, which steers from its line sensor and never needs to know how far it has gone. You need them the moment the robot has to travel a set distance, turn a set angle, or hold a speed that does not sag when the battery drops or the carpet gets thicker. A line-maze solver needs them; a first line follower does not. Adding them later means changing motors, so if you expect to get there, buy motors with encoders already fitted.
Why does my robot's turn overshoot by a consistent amount?
Error that is consistent and changes sign with direction is mechanical, not a tuning problem. Every gear train has backlash—free play that has to be taken up before the output moves—and it is charged once at every reversal. An encoder mounted on the motor shaft sits on the wrong side of the gearbox and cannot see any of it, so the controller believes the move completed. Measure the play in degrees at the wheel, and either compensate for it in software or stop reversing mid-move.