TL;DR:
A two-wheel robot is described by two numbers: forward speed v = (vR + vL) / 2 and turn rate ω = (vR − vL) / L.
A simulator steps that model forward in small time slices, so you can test code and see mistakes before a motor ever spins.
Always check a simulation against a case you can solve by hand.
Hardware is slow to fix. A flipped wire, a wrong sign or a timing bug can cost an afternoon, and a wrong sign in a motor command can send a robot off a table. A simulator lets you find those bugs where they cost nothing.
What you will build
You will write a model of a two-wheel (differential drive) robot, drive it from the keyboard, and prove the model right by comparing it with two cases you can calculate on paper. The same control code can later be pointed at the real robot.
The benefit is speed of learning. In a simulator you can reset the robot in a fraction of a second, run a test a hundred times, and change one number at a time. On a real robot each of those costs batteries, floor space and patience.
What you need
A computer with Python 3.
Optionally a robot simulator that provides ready-made worlds and physics. Larger simulators exist, but the ideas below are the same.
Pencil and paper for the check.
The model: two wheel speeds in, motion out
Let the left and right wheels have ground speeds vL and vR in meters per second, and let L be the distance between the wheels. Then the robot's center moves and turns like this:
v = (vR + vL) / 2 forward speed, m/s
ω = (vR − vL) / L turn rate, rad/s (positive = turning left)Check the two extremes. Wheels at equal speed give ω = 0, so the robot rolls in a line. Wheels at equal and opposite speed give v = 0, so it turns on the spot with no travel. Every other pair of speeds sits between those, and the robot follows a curved path.
A quick sanity check on signs: with vR greater than vL, the right wheel is faster, so the robot curves toward the left, and ω is positive. Keep this convention written beside your code. A mirrored sign is the most common simulator bug, and the same mistake on real hardware makes the robot turn away from its target.
The code, step by step
A simulator advances time in small steps dt. In each step it updates the pose, which is x, y and heading θ, using the current v and ω.
import math
L = 0.2 # wheel separation, meters
dt = 0.05 # time step, seconds
def step(x, y, th, vl, vr):
v = (vr + vl) / 2
w = (vr - vl) / L
x += v * math.cos(th) * dt
y += v * math.sin(th) * dt
th += w * dt
return x, y, th
def run(vl, vr, seconds):
x = y = th = 0.0
for _ in range(int(seconds / dt)):
x, y, th = step(x, y, th, vl, vr)
return x, y, thTo drive from the keyboard, map keys to wheel speeds: for example W sets both wheels to 0.3, S to −0.3, A sets left −0.15 and right 0.15 to spin left, and D the opposite. Any key-reading method works. In a larger simulator the same idea is a node that turns key presses into velocity commands.
Test it against hand math
First case: both wheels at 0.4 m/s for 5 s. By hand the robot travels 0.4 × 5 = 2.0 m along x. The loop runs 5 / 0.05 = 100 steps of 0.4 × 0.05 = 0.02 m, so x = 2.0 and y = 0.
Second case: vL = 0.3, vR = 0.5, L = 0.2. Then v = 0.8 / 2 = 0.4 m/s and ω = 0.2 / 0.2 = 1.0 rad/s. The robot circles with radius v / ω = 0.4 m. One full turn takes 2π / ω ≈ 6.28 s, and the distance covered is 0.4 × 6.28 ≈ 2.51 m, which equals the circumference 2π × 0.4 ≈ 2.51 m. Run it for 6.28 s and the pose should end near the start with θ near 2π. It will miss by a little, since each step moves in a straight line, and the gap shrinks as you reduce dt.
A third check costs nothing: spin in place with vL = −0.1 and vR = 0.1. Then v = 0 and ω = 0.2 / 0.2 = 1.0 rad/s, so after π / 1.0 ≈ 3.14 s the robot should have turned half a circle, and its position should stay at the origin. If it wanders, the position update is using the wrong speed.
What a simulation does not tell you
Wheels slip, and two motors never match exactly, so a real robot drifts even when both are told the same speed.
A motor needs time to reach its speed. This model jumps to the new speed at once.
Real sensors are noisy and late. A tidy model has neither problem.
Treat the simulator as a way to catch logic errors, such as a mirrored turn or a loop that never stops. It does not replace a first slow test on the real robot.
Make it better
Add a wall and stop the robot when its distance to it falls under 0.2 m.
Add small random errors to each wheel speed and see how far a square path drifts.
Limit how fast the wheel speed may change per step to model slow motors.
Stay safe
Moving from simulator to robot: Lift the robot so the wheels spin freely for the first run of any new code, and keep a hand near the power switch. Start at low speed, since real motors respond faster and harder than a simulated one.
Frequently asked questions
Why does my simulated circle not quite close?
Each step moves in a straight line, then turns. A smaller time step reduces that error.
Do I need a big simulator for this?
No. The model above is enough to practice. A full simulator adds physics, sensors and 3D worlds when you need them.
Get started
