Build pathAdvancedTwo or three weekends

Build a GPS Waypoint Rover That Drives Itself

A rover that drives a saved list of GPS waypoints across a field on its own, holding a line to within a metre, and stops itself if it leaves the geofence.

Build a GPS Waypoint Rover That Drives Itself technical schematicLOOKAHEADGOAL POINTCOMMANDED PATH

What you are building

A robot you hand a list of coordinates to, put on the grass, and walk away from.

Every other mobile robot on this site reacts to what is directly in front of it — a line, a wall, an obstacle, a border. This one executes a plan, in a world with no landmarks, using a sensor that lies to it a few times a minute. That combination is what makes it the hardest mobile build here and the one that teaches the most.

The three things that decide it

The follower is the easy part. Pure pursuit is twelve lines and one knob. With a perfect position estimate it holds 0.09 m of RMS error on the lab course.

The position estimate is the whole project. The same controller, given a 1 Hz GPS fix with metre-scale noise, holds 1.25 m — fourteen times worse, and spending four and a half times the steering to do it. The controller contributes under a tenth of the final error.

So the build order is: follower indoors, estimate outdoors. Prove the steering where position is nearly exact, then go and fight the sensor. Doing both at once produces a robot that wanders for reasons you cannot separate.

Bill of materials

Part Qty Approx. cost Notes
Arduino Uno or Mega 1 $5–12 A Mega is worth it: four interrupt pins for full ×4 encoder decoding, plus spare UARTs
GPS module (NEO-6M) 1 $8–12 A NEO-M8N is the single best upgrade here — multi-constellation, better geometry
MPU-6050 1 $2 Heading between fixes. Without it the rover cannot know which way it faces
N20 encoder motors 2 $16 Encoders are not optional on this build
TB6612FNG 1 $3
2WD chassis 1 $10–20 Bigger wheels help outdoors; grass is unkind to a 65 mm wheel
Battery pack 1 $10 2×18650 protected, or 3S with a regulator
Tall antenna mount 1 $2 The patch antenna needs sky, not a view — metal above it costs satellites

Total: roughly $55–80.

The one that changes the project most is the receiver. A NEO-6M works and is what most tutorials assume; a NEO-M8N sees GPS plus GLONASS and Galileo, which improves satellite geometry and therefore HDOP. Near buildings and trees — where a rover actually drives — that is a bigger real-world improvement than the accuracy specification suggests.

Do not skip the encoders to save $12. This whole project is dead reckoning corrected by occasional fixes; without encoders there is nothing to dead reckon with, and the rover simply chases GPS noise.

Build order

1 — Tune the follower in the simulator. An hour in the path following lab at the speed you intend to drive. Find the lookahead where the error curve bottoms out; note that it moves when you change the speed.

2 — Build the drivetrain and get odometry working. Encoders into differential-drive odometry, then drive a 2 m square and see how far from the start it finishes. That number is your indoor budget.

3 — Fuse a heading. A gyro at the loop rate, corrected by something absolute. Heading error is the term both controllers weight most, and it is the first thing odometry loses — the complementary filter that stabilises a balancing robot does the same job here.

4 — Follow a taped course indoors. No GPS. Tape a path on the floor, run pure pursuit on the encoder estimate, and measure the cross-track error with a ruler at ten points. If it is not under 10 cm indoors it will not be under a metre outdoors.

5 — Add the receiver and do not connect it to the controller yet. Log fixes for ten minutes while the rover sits still, and plot them. You will see the noise, the occasional excursion, and how HDOP tracks both. That plot is worth more than any datasheet figure.

6 — Fuse, do not follow. Dead reckon at the loop rate; pull the estimate gently toward each good fix. The arithmetic and the gating are here. Reject anything with a void status or HDOP above about 2.5.

7 — Geofence, then go outside. Maximum distance from the start, mission timeout, physical cutoff. Then a short mission, on grass, with you walking beside it.

Hardware notes that matter

Mount the antenna on top, facing sky, away from everything. A ceramic patch under a chassis plate loses satellites, and lost satellites are bad geometry rather than no fix — a confident wrong answer instead of an obvious failure.

Bigger wheels than your indoor instinct. Grass, gravel and a lawn edge are all wheel-diameter problems. They also change your odometry scale factor, so recalibrate on the surface you will actually drive.

Keep the magnetometer away from the motors, or skip it. Motor current produces a field that swamps the Earth’s. If you cannot get 15 cm of separation, use gyro plus course-over-ground and avoid the problem.

Log the mission. An outdoor failure you did not record is a failure you cannot debug — the robot was 40 m away and you were not watching the serial port. An SD card or a Wi-Fi log of pose, fix, HDOP and cross-track error turns each run into evidence.

Expect the first outdoor run to end early. That is what the geofence is for, and it is a success.

What good looks like

Measurement Raw GPS following Fused with odometry
Cross-track error, RMS 3–5 m 0.3–0.6 m
Cross-track error, worst case 8–12 m 1.0–1.5 m
Steering activity Constant, large corrections Smooth, occasional
Waypoint arrival tolerance 5 m, and even that is optimistic 0.5–1 m
Static position wander, stationary 2–4 m cloud N/A — odometry holds it still

That first column is not a badly built rover; it is what a 2.5 m CEP fix at 1 Hz does to a controller that trusts it. The order-of-magnitude improvement in the second column comes from the estimator, not the controller — the same pure pursuit code, fed a fused pose.

Before writing any navigation code, do this once: leave the receiver stationary outdoors for ten minutes and log every fix. The cloud you get is several metres across, and nothing moved. That plot is the single most useful thing you can look at on this project, because it explains why following raw fixes cannot work and why the fix is upstream of the controller.

When it goes wrong

Symptom Usually
Weaves down a straight outdoors, fine indoors Following raw fixes instead of fusing them
Weaves indoors too Lookahead too short for the lag; retune in the lab
Rounds off every corner Lookahead too long — the trade, not a bug
Confident position tens of metres out Bad satellite geometry; you did not gate on HDOP
Drives the wrong way from a standing start No usable heading; course-over-ground is noise below ~1 m/s
Drifts steadily to one side Odometry scale or track width wrong for this surface
Nothing happens for the first two minutes GPS cold start. Show it, do not assume the origin
Left the field The geofence was not written before the test

Six of those eight are sensing rather than control — the same distribution as the micromouse and the coverage robot, and for the same reason: the algorithm is the small part.

For the whole sequence in order, follow the path following roadmap; for the indoor version of the same problem, the room coverage robot needs a plan and no absolute position at all.

Project roadmap

The build path

Follow the tech tree from parts to a robot that follows a taped line. Each node unlocks when its prerequisites are done, and your progress saves on this device.

0 / 20 done

100%
Learning path

Path following and navigation

Learning path

Open path
Build

Follow a path indoors first

Build

Build

Fence it before the first field test

Build

Goal

Drive a mission on its own

Goal

Components

Tutorials in this path

Practise before you wire

Tune it in the live simulator

The build path routes through a browser lab. Find gains that follow the track cleanly here, then transfer them to the real robot.

Frequently asked questions

Why build the follower indoors before adding GPS?

Because if you build both at once and it wanders, you cannot tell which half is wrong. Indoors on encoders the position estimate is good to a few centimetres over a taped course, so any error you see is the controller. Get the lookahead right there, measure the cross-track error with a ruler, and only then introduce a sensor that is noisy, late and occasionally confidently wrong. Every hour spent on this order is repaid twice.

How accurate can a hobby GPS rover actually be?

About a metre of cross-track error on a good day, which is set by the receiver rather than by your controller. Measured with the same pure pursuit on the same course, a perfect position estimate gives 0.09 metres of RMS error and a 1 Hz fix with metre-scale noise gives 1.25 — so the controller contributes under a tenth of the total. If you need better, the upgrade is a faster and multi-constellation receiver, then RTK, not more tuning.

Do I need a magnetometer as well as the gyro?

You need some absolute heading reference and you have three options. A magnetometer gives it standing still but needs hard- and soft-iron calibration and hates being near the motors. A gyro is excellent for tens of seconds and then drifts. GPS course-over-ground is absolute and free but only meaningful above about a metre per second. The usual rover answer is a gyro for the loop rate, corrected by course-over-ground whenever the robot is moving fast enough to trust it — which is what this build does, and it avoids the calibration entirely.

What speed should it drive?

Slower than the motors allow, and the simulator will tell you why. The best achievable cross-track error grows with speed no matter how you tune: 0.05 metres at 1 m/s becomes 0.23 at 3 m/s in the lab with a perfect position estimate. Outdoors the receiver dominates anyway, so there is little to gain from speed and a great deal to lose in the first field test. Start at 0.5 m/s.

What stops it driving into a road or a pond?

A geofence you write before the first outdoor run: a maximum distance from the mission start, checked at the very top of the loop, that stops the motors unconditionally. Add a mission timeout and a physical cutoff you can reach — a bump switch on the top deck works and needs no radio link. This is ten lines of code and it is the difference between a bug and a robot in the water.

Can I use an ESP32 instead of an Uno?

Yes, and for this project it is the better choice. You get a second hardware serial port for the GPS without software serial, far more memory for a waypoint list, floating-point maths that is not painful, and Wi-Fi for logging the mission back to a laptop — which is the single most useful debugging tool an outdoor robot can have. The Uno works; the ESP32 removes three annoyances.