pure pursuit vs guiding vector fields

context

when we made it to the first world championships, we knew we wanted a consistent autonomous routine.

we didn't have much time, but we eventually got it to a state where it worked consistently every match. along the way we ran two different path followers: adaptive pure pursuit, and then a guiding vector field. this is about both, and why we ended up switching.

pure pursuit

pure pursuit follows a path by always steering toward a point a fixed distance ahead of the robot. that distance is the lookahead, and the target is wherever the lookahead circle crosses the path.

the problem is the lookahead. if it's too big, the circle can grab a point that's physically close but actually much farther along the path. on a tight path the robot locks onto the wrong segment and cuts straight across instead of following the route.

drag the lookahead up and watch pure pursuit (left) cut across, while the vector field (right) stays on the path. nudge start offset if you want both bots starting off the centerline.

we can somewhat fix this by scaling the size of the circle based off the robot's current velocity (this is the "adaptive" part), but that does not fully fix the issue. here the circle shrinks through the turn, but because that shrink lags, it still cuts across on the way in:

this can be frustrating, especially in a game where we need to consistently open the gate to intake or feed our partners.

our goals

we wanted to shoot more balls in auto than we managed at our state championship. to do that, we optimized gate intaking so we could grab from the gate sideways, without cutting into the number of balls we hand off to our partners.

so we switched to a guiding vector field.

the guiding vector field

a guiding vector field flips the idea around. instead of chasing a single point ahead of us, every point in the plane gets a desired heading, so there's no lookahead to mistune and no wrong segment to lock onto.

for a path defined implicitly by $\varphi(x, y) = 0$, the field assigns a desired velocity at every point in the plane. one term drives the robot along the path, and the other pulls it back onto the path when it drifts off:

$\tau$ rotates the gradient by $90^\circ$ so it points along the path, and $k_e$ is the convergence gain: how hard off-path points get pulled back in. the heading we actually command is $\theta = \operatorname{atan2}(v_y, v_x)$.

arrows are the commanded heading at each point. click to drop a robot onto the field and drag $k_e$: at zero they only ride the tangent; raise it and they snap harder onto the curve.

reducing oscillation

to reduce oscillation further, we attached a velocity profile to a regression. we took inspiration from 18438 wolfpack machina in power play, who used a similar system to smooth out their stopping.

the way it works: using a calculated motor curve for each wheel (as in, if we cut all power to the wheel, what would happen?) along with our current velocity, we predict where we'll stop. if we think we'll stop at the end position, we cut power to the wheels and glide into place, instead of forcing ourselves in and then oscillating.

a secondary positional pid then corrects onto the end point after the robot has stopped.

you can tune a pid controller a lot, but the simplicity of this solution means you don't need to spend as much time tuning a pid to get there.

notes

• pure pursuit is simple and works, but the lookahead is one more thing to tune, and it fails ugly on tight paths.
• a guiding vector field sidesteps that entirely: the target is the whole path, not a single point on it.
• tuning $k_e$ trades cornering aggression for stability.

credits & references

• Implementation of the Pure Pursuit Path Tracking Algorithm
• Guiding vector fields for the distributed motion coordination of mobile robots
• Worlds Autonomous Explanation - Wolfpack 18438 FTC
• Wolfpack Movement Breakdown - 18438 FTC