Path Following for Robots: A Learning Roadmap

Planning and following are different problems, and most robotics material teaches only the first. A* gives you a route; nothing in it tells the wheels what to do. This path is that missing rung — everything between a list of waypoints and a robot that actually drives them.

Work through the nodes in order. Each one is a thing the next assumes, and skipping any of them produces a robot that wanders for a reason you cannot isolate.

Before you start

You need a differential-drive robot you can already command — two motors, a driver, and a loop that runs at a steady rate. The motor control path covers all of that and this one expects it first. No control theory is required; pure pursuit is geometry, not a PID.

What you will be able to do

• Convert wheel encoder counts into a pose, and say how far that pose drifts per metre driven on your own floor.
• Fuse a gyro with an absolute reference into a heading that does not walk away over a mission.
• Implement pure pursuit from the curvature formula, in about a dozen lines, and explain every one of them.
• Choose a lookahead distance from your robot’s measured control lag rather than by trial and error, and schedule it on speed.
• Measure cross-track error against ground truth and report RMS, worst case, and where along the path the error lives.
• Say why the same controller is fourteen times worse on a raw GPS fix, and fix it without changing the controller.

Where people get stuck

Tuning the controller when the estimate is the problem. If the robot thinks it is on the path, it reports zero error and steers confidently into a hedge. Measure against something external before touching a gain — a tape measure counts.

Believing a simulation with no lag. A perfectly kinematic pure pursuit gets better as the lookahead shrinks, so a lag-free model recommends the one setting that oscillates on real hardware. Put a steering time constant and a sensing delay into any model you tune against.

A global nearest-point search. It is the obvious implementation and it fails silently on any path that doubles back, matching a segment the robot drove a minute ago. Track arc length, search a window around it, and never let progress run backwards.

Resolving a vertex tie to the incoming segment. Past a corner, both adjacent segments project to the same point at the same distance. Keep the wrong one and a controller that steers on heading and lateral error sees approximately zero of both while driving straight off the course. It is the quietest bug on this page.

Build it as the GPS waypoint rover, which follows this sequence exactly — indoors on encoders first, outdoors on a fused fix second.

What you need

Why the path runs in this order

This path is unusual in that the first five nodes are not about steering at all. They build the pose estimate, because a path controller acting on a wrong pose fails in a way that looks exactly like a badly tuned controller — the robot reports zero error while driving into a hedge. Getting the estimate right first means that when you finally tune a gain, you can believe what you measure.

Encoders, then odometry, then slip, in that order. Each corrects the previous one’s optimism. Encoders tell you the wheel turned; odometry turns two wheel motions into a pose; slip tells you how much of that pose is fiction, and specifically that systematic error grows linearly with distance while random error grows only as its square root.

The IMU joins before the controller because heading is the part of the pose that matters most to a path follower and is the part wheels are worst at. A pivot turn scrubs both tyres almost by definition, so the one manoeuvre that changes heading most is the one odometry measures worst. A complementary filter fuses a gyro’s good short-term rate with an absolute reference’s good long-term average, and the result is a heading that does not walk away.

Motion profiles come before pure pursuit because a path follower commands speed continuously, and a speed command that steps produces a robot that lurches and slips — re-introducing exactly the odometry error you just spent three nodes controlling.

Pure pursuit, then the lab, then cross-track error. The controller is about a dozen lines and its geometry is easy; what is hard is choosing the lookahead and knowing whether the result is good. The lab exists so you can watch the lookahead trade-off happen, and the cross-track node exists so “it drives well” becomes a number with an RMS and a worst case.

GPS last, and only last. It changes nothing about the controller and everything about the estimate. Doing it last means that when tracking gets fourteen times worse, you already know for certain that the controller is not the reason.

Checkpoints: how to know a stage landed

Where this path stops

This path takes a given path and drives it. It does not produce the path — that is path planning and mapping, and the two together are the complete navigation stack.

It also stops short of three things. Obstacle avoidance while following — reacting to something that appears on a path you already committed to — needs a local planner running underneath the follower, and that is a genuinely harder problem than either half alone. Ackermann and omnidirectional steering change the geometry: pure pursuit adapts to a car-like robot readily, but the curvature-to-wheel-speed step here is specifically differential drive — for a base that can strafe, start at holonomic drive, and note that a holonomic robot can do strictly better than either controller here because it can correct position without spending heading. And RTK GPS, which brings the outdoor fix from metres to centimetres, is the thing that makes outdoor path following genuinely precise — worth knowing exists before you conclude that outdoor navigation is simply inaccurate.