Path-tracking comparison Lab — run PP, APP, RPP, Stanley and MPC under the same conditions

Contents — find the section you need

Change parameters and verify

Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.

Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.

Open experiment panel in a new tab

Download reproduction source

Run five approaches together

Run "Gentle curve · 3 m/s · 1 m offset". PP, APP, RPP, Stanley and MPC follow the same path from the same position, and the trajectories and four time plots (cross-track error, heading error, steering, speed) are overlaid. The approaches are told apart by both colour and dash pattern (PP solid, APP dashed, RPP dotted, Stanley dash-dot, MPC long dash).

Under this condition all five pass the endpoint. In the table, Stanley has the smallest steering-rate RMS but the largest cross-track RMS, and RPP, which slows itself with curvature, has the lowest mean speed and arrives last. Which approach is "better" depends on which metric you weigh.

What is shared

The vehicle is the rear-axle, forward-only kinematic bicycle model shared with the earlier Labs. The path, initial position and heading, wheelbase, steering limit (and the vehicle's 0.8 rad/s steering-rate limit), target speed, 0.05 s steps up to 30 s, and the endpoint and off-path tests are the same for every approach.

All metrics come from the shared simulator with the same definitions. Cross-track and heading errors use the rear axle, and RMS is the square root of the trapezoidal time integral of the squared samples divided by elapsed time. For smoothness the table shows steering-rate RMS and steering total variation (the sum of absolute steering changes per cycle). Mean speed is distance travelled divided by elapsed time.

What is not like-for-like

Apart from the one parameter shown on screen (PP lookahead, APP/RPP lookahead time, Stanley gain, MPC horizon steps), each approach uses the initial values of its own Lab. Those values were not tuned against each other, so the results compare these particular settings.

RPP lowers its own speed with curvature and distance to the endpoint, so completion time and speed are not like-for-like. When RPP slows down, its velocity-scaled lookahead also shrinks. Only MPC has a prediction horizon, and its computation time is not compared here (see the MPC Lab). Stanley steers from front-axle error, while the metrics here use the rear axle.

Strengths that swap with conditions

In "2 m/s (RPP fails)", only RPP stops with "controller failed". When RPP slows down its lookahead shrinks to the 0.5 m minimum, and from a 1 m offset it can no longer find a target point ahead on the path. This is the behaviour of this Lab's vehicle model, which only has a forward-recovery rule.

In "4 m/s (PP fails)", PP with a fixed 2 m lookahead fails partway, while APP and RPP, whose lookahead grows with speed, complete. In "Tight curve (outcomes differ)", APP, RPP and Stanley complete, PP fails and MPC leaves the path. "Tight curve · 0.3 rad limit (all fail)" is a case where the limit is below the roughly 0.46 rad needed for the 5 m radius, and no approach can make the turn. Changing the control law cannot exceed the limits set by the vehicle and its constraints.

Suggested order

Compare the five trajectories and metrics under the nominal condition and save it as A.
Change the speed to 2 m/s and 4 m/s, and read which approach fails and why.
Use the two tight-curve presets to separate differences between approaches from the vehicle's limit.
Change PP lookahead, Stanley gain and MPC horizon one at a time and look at the difference from A.

Do not rank runs with different completion states or elapsed times by cross-track RMS alone. The completion time of an approach that did not finish is "—". Everything runs in your browser, with A/B comparison, reset, sharing and JSON download.