M5-T7 — When Tracking Goes Wrong

Learning objectives

After this lesson, you should be able to:

• Recognise oscillation, corner cutting, saturation and lag from cross-track error plots and logs.
• Relate oscillation to latency and lookahead, and corner cutting to lookahead and speed.
• Compute whether a bend can be driven within the turn-rate or steering limit.
• Tell a planner problem from a controller problem with an ideal-follower replay.

The intuition

Picture the cross-track error plotted against time. A flat line near zero is good. A line that swings regularly from side to side, and never dies away, is an oscillation. A bump on every bend that returns to zero is corner cutting. A line that grows on a tight bend and stays large because the command is already at its limit is saturation. A line that is small but a robot that is always a metre behind its timetable is lag.

The shape of the error says more than its size. And when the shape is not enough, take the controller out of the picture: drive the same path with a perfect follower. If a perfect follower cannot do it, no retuning of the real controller will help.

The mathematics

Signatures and usual causes

Latency and lookahead

A command takes the latency τ to act. During that time the robot moves v·τ. If the lookahead is not several times v·τ, each correction arrives late and overshoots, and the error rings (lab M5-L3):

A lookahead rule that holds at one speed does not hold at another, which is why it is a function of speed.

Saturation

A unicycle with turn-rate limit ω_max can drive a bend of radius R at speed v only if v / R ≤ ω_max. A car-like robot is limited by its steering: R ≥ L / tan δ_max. Beyond the limit, the controller commands what the robot cannot do, the error grows, and with an integral term it winds up.

Planner or controller?

1. Replay. Drive the path in simulation with a perfect pose, no delay and no limits. The error should be near zero.
2. If it is not, the path is the problem: plot its curvature against the robot’s limit, look for kinks and for jumps between consecutive plans.
3. If it is, add one real effect at a time (latency, then limits, then noise) until the failure appears. That effect is the cause.

A worked example

Weaving, in numbers. Scout drives at 1.2 m/s with 0.4 s of latency, so it moves v·τ = 0.48 m before a command acts. In the simulation of lab M5-L3 it starts 0.5 m off a straight line with pure pursuit:

With the latency set to zero the same lookaheads of 0.35, 0.6 and 1.2 m do not weave at all: it is the delay, combined with a short lookahead, that does it. That is the incident of lab M1-L1, stage 2, where a lookahead of 0.35 m met 0.48 m of travel.

Saturation. Scout has ω_max = 1.0 rad/s and meets a bend of radius 0.8 m at 1.2 m/s. It needs ω = v/R = 1.2 / 0.8 = 1.5 rad/s, 50 % more than it has. The fastest it can take the bend is v = ω_max · R = 0.8 m/s. At 1.2 m/s the robot turns as fast as it can and runs wide, and no controller gain changes that. The cure is in the speed profile.

Corner cutting. At 0.3 m/s the corner cut grows from 0.13 m with L = 0.5 m to 0.40 m with L = 1.5 m and 0.67 m with L = 2.5 m (lesson M5-T4). A lookahead tuned for cruising speed is far too long for a crawl.

The replay. A cross-track plot shows a 0.4 m spike at x = 7.2 m on a path that the ideal follower also misses by 0.4 m. The path has a kink there: two consecutive plans disagreed and the path jumps sideways. Retuning the controller cannot fix a path that jumps.

Engineering implications and limitations

Log the right things

Log the reference pose, the measured pose, the command and the limits every cycle. Cross-track error, heading error, command and saturation flag are enough to name most failures from a plot.

Change one thing, then replay

Keep a fixed test route with a straight, a bend, a start offset and a stop, and run it after each change in simulation (lesson M9-T3 covers simulation). Retuning on the real robot in a corridor with people is a way to learn only one thing per day.

Check the timestamps

The latency that matters is the whole loop: sensing, estimation, planning and actuation. A clock offset between the pose and the command reads as latency. Measure it, do not guess it.

Where the planner is to blame

Replans that change the path under the robot, paths hugging obstacles, paths with a curvature above the limit and paths that start behind the robot are planner and smoothing faults (lesson M5-T2). The controller will follow them faithfully, and badly.

Safety first

If error and command saturate for more than a moment, the safe response is to slow down or stop and replan, not to push on. The recovery behaviours of lesson M7-T6 handle that.

Common misconceptions

Engineering takeaways

1. The shape of the error names the failure: sign changes mean oscillation, a bump on bends means corner cutting, a growing error at the limit means saturation.
2. Latency turns into distance (v·τ); keep the lookahead at several times that and at least about a second of travel.
3. A bend is drivable only if v/R ≤ ω_max, or R ≥ L/tan δ_max; slow down before it.
4. Replay the path with an ideal follower first: if it also fails, fix the path; if not, add real effects one at a time.
5. Log reference, pose, command and limits so the plot can answer.

References and further reading

Feedback with delay, the regulated pure pursuit paper, and the path-tracking comparison.

• K. J. Åström and R. M. Murray, “Feedback Systems: An Introduction for Scientists and Engineers”, Princeton University Press, 2008.
• S. Macenski, S. Singh, F. Martín and J. Ginés, “Regulated Pure Pursuit for Robot Path Tracking”, Autonomous Robots, 2023.
• J. M. Snider, “Automatic Steering Methods for Autonomous Automobile Path Tracking”, Carnegie Mellon University Robotics Institute, Technical Report CMU-RI-TR-09-08, 2009.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

Next module: reacting to what the map did not know.

Related content

Nothing below is required to finish this lesson.

• Before
  M5-T6: LQR and MPC for Path Tracking

  Describe how a linearised error model gives LQR gains and how MPC adds constraints and a horizon.

• Lab
  M5-L3: Tune Pure Pursuit

  Scout cuts corners at speed and weaves at low speed: choose a lookahead that works at both.