Kinematics is the geometry of motion — how the turning of wheels or the angles of joints become movement through space, without worrying about forces yet. This lesson gives you the working intuition you need for a first robot: how a two-wheeled robot's wheel speeds turn into driving straight, turning, and spinning; what forward and inverse kinematics mean for an arm; and why every real robot drifts and needs correction. You will not need heavy maths — just the ideas and a few formulas you can actually use.
- Explain how differential drive turns two wheel speeds into motion
- Convert a desired forward and turning speed into left and right wheel speeds
- Distinguish forward from inverse kinematics for a robot arm
- Understand why odometry drifts and must be corrected
Differential drive: two wheels, all the moves
The most common wheeled robot has two driven wheels and a caster to balance — a differential drive. Everything it does comes from the two wheel speeds. Drive both wheels forward at the same speed and it goes straight. Drive the left faster than the right and it curves right. Drive them in opposite directions and it spins in place around its own centre. That is the whole vocabulary of motion for this robot: forward speed comes from the *average* of the two wheels, and turning comes from the *difference* between them. Once you see motion as 'average plus difference', controlling the robot becomes simple.
- Both wheels equal, forward → drive straight.
- Left faster than right → curve toward the right.
- Wheels opposite directions → spin in place.
- Average of the two speeds → forward speed; difference → turn rate.
From 'go and turn' to wheel speeds
In code you usually want to command the robot in human terms — a forward speed v and a turning rate w (how fast to rotate) — and let the maths work out each wheel. For a differential drive with wheel separation L, the two wheel speeds are the forward speed plus or minus a term for turning. This little conversion is the heart of driving a robot: you decide 'move forward and curve left', and it produces the left and right wheel commands. It is what sits between a joystick, or a navigation decision, and the motors.
def wheel_speeds(v, w, L):
"""Forward speed v and turn rate w -> left/right wheel speeds.
L is the distance between the wheels."""
left = v - (w * L / 2.0)
right = v + (w * L / 2.0)
return left, right
# straight ahead
print(wheel_speeds(1.0, 0.0, 0.3)) # (1.0, 1.0)
# spin in place to the left
print(wheel_speeds(0.0, 2.0, 0.3)) # (-0.3, 0.3)
# forward while curving left
print(wheel_speeds(1.0, 1.0, 0.3)) # (0.85, 1.15)Forward and inverse kinematics of an arm
A robot arm is a chain of joints, and there are two questions you can ask about it. Forward kinematics asks: given the joint angles, where is the hand? This is always solvable — you just follow the chain, adding up each link's rotation and length, and out comes the hand's position. Inverse kinematics asks the harder, more useful question: given a target position for the hand, what joint angles get it there? This can have several answers (elbow up or elbow down), or none if the target is out of reach, which is why it is the harder problem. For a simple two-joint arm you can solve it with trigonometry; for complex arms, libraries and numerical solvers do it. The key idea to carry: forward is 'angles to position' and easy; inverse is 'position to angles' and is what you actually need to make an arm reach a point.
A memory hook: forward kinematics answers 'where is my hand given these angles?' (easy, one answer). Inverse kinematics answers 'what angles put my hand there?' (harder, maybe several answers or none).
Odometry: estimating where you are
If you know how far each wheel has turned (from encoders), you can add up the little movements to estimate the robot's position and heading over time — this is odometry. Each short interval, the average wheel movement moves the robot forward and the difference rotates it, and you accumulate these into an (x, y, heading) estimate. Odometry is cheap and updates fast, and it is the backbone of a robot knowing roughly where it is between bigger position fixes.
But odometry drifts. Every reading has a tiny error — a wheel slips, the diameter is not exact, the floor is uneven — and because you keep adding, the errors accumulate and never go away. After a few metres the estimate can be well off, especially the heading, and a small heading error throws off everything after it. That is why odometry alone is never trusted for long: it is corrected by an absolute reference (a sensor that sees the world, covered in the SLAM lesson). Understanding that odometry is a good short-term guess but a bad long-term truth is the whole lesson.