What it does

A small DC motor with a plastic gearbox on the front and a rubber wheel that pushes on. The gearbox trades the motor’s uselessly high speed for the torque needed to actually move something.

Two of these and a castor make a robot that drives. It is the mechanical half of every wheeled project in this library, and most of what there is to learn is not electrical: it is why two identical motors do not go the same speed, and what to do about it.

Before you begin

Required parts and tools

• An Arduino Uno or compatible board.
• Two geared motor and wheel sets. This is Siratek product 7406; one set is one wheel.
• An L298N driver module, Siratek 2533.
• A separate motor supply, four to six AA cells or a 6 V pack.
• A chassis, or something to screw the motors to, and a castor or ball wheel at one end.
• A soldering iron, because the motor terminals arrive bare.

What you are getting

The Siratek photographs show the common yellow TT gear motor: a small brushed motor in a metal can, a yellow plastic gearbox, a shaft projecting from each side, and a black rubber tyre on a yellow plastic hub.

Typical figures for this type:

The stall current is the number that matters. Two motors stalled is about 2 A, which is far beyond a USB supply and more than a weak battery pack will hold up under. A robot that resets when it hits a wall is this, not a software fault.

The shaft goes through

The motor has a shaft on both sides. One takes the wheel; the other is spare, and is there so you can fit an encoder disc if you later want to know how far you have travelled.

Push the wheel on firmly. The hub is a tight fit on a D-shaped shaft and it only goes on one way round.

Solder the leads before mounting anything

The terminals are two small metal tabs with no wires attached. Solder leads on before you screw the motor to a chassis, because afterwards the tabs are awkward to reach and the heat is harder to manage.

Keep them short, use stranded wire so they flex, and add a dab of hot glue over the joint: those tabs break off easily if the wire is tugged.

Two motors will not run at the same speed

This is the thing that surprises people, so it comes before the wiring.

Give two identical motors the same voltage and the robot curves. Always. The gearboxes differ a little, the brushes differ, the friction differs, and the difference is often ten percent or more.

There are three honest responses:

Trim it in software. Measure how much each motor needs to go straight and apply a correction factor. Simple, free, and only right at one speed and on one surface.

Fit encoders. The spare shaft takes a slotted disc, and an optical sensor counts the slots. Then the sketch knows the actual speed of each wheel and can correct continuously. This is the proper answer and it is a project of its own.

Do not need it to go straight. A line-following robot corrects its heading constantly from the line itself, so the motors never need to match. That is why line following is the natural first robot: the mismatch stops mattering.

The sketch below includes the trim, because it is the first thing anyone needs.

Which way is forward

Swapping a motor’s two leads reverses it. Because the two motors face opposite ways on a chassis, one of them will almost certainly need its leads swapped for both wheels to drive the robot in the same direction.

Expect this rather than being puzzled by it: the first time you run both motors forward, one wheel will turn backwards. Swap that motor’s two wires, or invert it in code.

Pin reference

The driver’s wiring is as in Driving DC Motors with an L298N. Repeated here for one chassis:

Wiring steps

1. Solder leads to both motors before mounting them.
2. Screw both motors to the chassis, wheels on, with a castor at the opposite end.
3. Wire the L298N as in its own tutorial: enable jumpers off, six logic wires to the Uno.
4. Motors to OUT1/OUT2 and OUT3/OUT4.
5. Motor supply to +12V and GND, and join that ground to the Uno’s GND.
6. Put the robot on a stand so the wheels spin free. It will drive off the bench otherwise, and the first run is the one most likely to go in an unexpected direction.
7. Plug in the USB cable, then the motor supply.

Software and libraries

No library is required.

Minimal working example

// Siratek: prove each motor, one at a time, with the wheels off the ground.

const int enA = 10, in1 = 9,  in2 = 8;    // left
const int enB = 5,  in3 = 7,  in4 = 6;    // right

void setup() {
  int pins[] = {enA, in1, in2, enB, in3, in4};
  for (int i = 0; i < 6; i++) {
    pinMode(pins[i], OUTPUT);
  }
  Serial.begin(9600);
  Serial.println("Siratek: left forward, left back, right forward, right back.");
}

void leftMotor(int speed) {
  digitalWrite(in1, speed >= 0);
  digitalWrite(in2, speed < 0);
  analogWrite(enA, abs(speed));
}

void rightMotor(int speed) {
  digitalWrite(in3, speed >= 0);
  digitalWrite(in4, speed < 0);
  analogWrite(enB, abs(speed));
}

void loop() {
  Serial.println("left forward");
  leftMotor(200); delay(1500); leftMotor(0); delay(500);

  Serial.println("left back");
  leftMotor(-200); delay(1500); leftMotor(0); delay(500);

  Serial.println("right forward");
  rightMotor(200); delay(1500); rightMotor(0); delay(500);

  Serial.println("right back");
  rightMotor(-200); delay(1500); rightMotor(0); delay(2000);
}

Watch which way each wheel turns when the sketch says “forward”. If one is wrong, swap that motor’s two wires at the terminal block, or swap its two digitalWrite() lines. Either is fine; doing it in the wiring keeps the code honest.

Driving, with the trim

// Siratek: the two motors, with a correction for their mismatch.

// Measured, not guessed. See the procedure below.
const float LEFT_TRIM  = 1.00;
const float RIGHT_TRIM = 0.92;

// Below this, the motors hum instead of turning.
const int MINIMUM_SPEED = 70;

void drive(int left, int right) {
  left  = (int) (left  * LEFT_TRIM);
  right = (int) (right * RIGHT_TRIM);

  leftMotor(constrain(left, -255, 255));
  rightMotor(constrain(right, -255, 255));
}

void forward(int speed)  { drive(speed, speed); }
void backward(int speed) { drive(-speed, -speed); }
void spinLeft(int speed) { drive(-speed, speed); }
void spinRight(int speed){ drive(speed, -speed); }
void halt()              { drive(0, 0); }

Measuring the trim

Two minutes on the floor, and it replaces a guess with a number.

1. Mark a straight line on the floor, two or three metres long.
2. Run forward(180) and let the robot travel the whole length.
3. Note which way it veers.
4. Reduce the trim on the side it veers away from, by about 0.05.
5. Repeat until it runs reasonably straight.

Veering left means the right wheel is faster, so lower RIGHT_TRIM.

Two things worth knowing about the result. It is only right at that speed: trim at 180 and the robot will curve at 120. And it changes as the batteries drain, which is one of the reasons encoders exist.

The starting speed

As on the L298N page: at low PWM values the motors hum and do not turn, because the average torque cannot overcome the gearbox friction. On these motors the threshold is often around 60 to 80.

void startMoving(int speed) {
  drive(255, 255);          // a brief full-power kick
  delay(60);
  drive(speed, speed);
}

Find your own minimum by stepping the value up from a standstill until both wheels turn reliably. Then never ask for less than that from rest.

Expected result

With the wheels off the ground, each motor turning both ways in turn, smoothly, with an audible change as the speed changes.

On the floor, a robot that drives roughly straight after trimming, turns on the spot when the wheels are driven in opposite directions, and does not reset when it bumps into something.

A reset on contact is the stall current, and the answer is a better motor supply rather than anything in the sketch.

Troubleshooting

Next steps

• Easier first: Driving DC Motors with an L298N, which this page assumes.
• Related products: the four-way tracking sensor, which gives the robot something to follow, and the HC-SR04, for noticing obstacles.
• Next project: a line following robot, where the constant steering correction means the motor mismatch stops mattering.

Sources and attribution

All text, wiring guidance and code in this tutorial are original Siratek work.

• The yellow TT-type gearbox, the dual-sided shaft and the push-fit wheel were read from the Siratek product photographs for item 7406.
• Driver wiring, the enable jumpers and the bridge voltage drop are as set out in Driving DC Motors with an L298N.

Gear ratio, current and speed figures are typical for this motor type rather than from a datasheet for this specific part, and the tutorial gives procedures for measuring the trim and the starting duty cycle rather than asserting values. Siratek product 7406 is one motor and wheel; a driving robot needs two. No third-party tutorial text, diagrams, photographs or code has been reproduced here.