Why is my robot oscillating? A practical guide to controller tuning

Your robot follows the path, but it keeps swinging from one side to the other. A line follower that snakes, a mobile robot that zig-zags, a joint that buzzes around its target: it is the same problem, and it has the same few causes.

The same robot, the same path, the same starting offset. Only the controller gains differ.

What oscillation is

A feedback controller measures an error, how far the robot is from where it should be, and commands a correction. Oscillation is a loop of over-corrections:

error → large correction → overshoot → error changes sign → correction in the opposite direction → overshoot again

Every real robot has some delay between the command and the effect: motors need time to spin up, the body has inertia, and position estimates arrive a little late. If the controller pushes hard, the correction is still growing when the robot reaches its target, so it sails past. The harder it pushes, the further it overshoots.

How to recognise it in a plot

Plot the tracking error against time. The signatures are easy to read once you know them:

What the error plot shows	What it usually means
The error changes sign again and again, and the swings do not shrink	Too little damping for the amount of gain: sustained oscillation
The error changes sign a few times, with each swing smaller	Underdamped but stable: more damping would settle it faster
The error creeps slowly toward zero without crossing it	Stable but slow: too little gain, or too much damping
Tiny, very fast wiggles and a command that jumps between its limits	Gains so high that the controller reacts to small changes and delays

Always look at the control signal too. If the turn-rate command slams from one limit to the other, the controller is asking for more than the robot can do.

The two knobs that matter most

Kp, the proportional gain, sets how strongly the robot reacts to the current error. More Kp means a faster response, and eventually more overshoot and oscillation. Turning it up is the most common reaction to a sluggish robot, and the most common way to create an oscillating one.

Kd, the derivative gain, reacts to how fast the error is changing. When the robot rushes back toward the path, the error shrinks quickly and the derivative term eases off the correction before the robot arrives. That braking effect is damping. Too much of it makes the robot sluggish, and with noisy sensors or delays it makes the command jittery.

A practical tuning procedure

Run the robot and save the plot. Never tune without a baseline to compare against.
If it oscillates, do not raise the gains. Add derivative action in small steps until the swings die out.
If it is now calm but slow, raise Kp a little, then add a bit more Kd if the overshoot returns.
Change one gain at a time and compare with the previous run.
Test the result against a disturbance, such as a different start or a bump, before you trust it. Gains that only just work in one scenario usually fail in the next.

Try fixing the robot yourself in the interactive lab. A mobile robot zig-zags around its path. Diagnose it from the plots, tune Kp and Kd, and pass a robustness test. Free, in your browser.

Fix the oscillating robot

When tuning is not the answer

If no combination of gains gives a response that is both fast and calm, the limitation is usually physical: too much delay in the sensing pipeline, motors that saturate, a mechanism with backlash, or a control loop that runs too slowly. Reducing latency often helps more than any gain change. For more on gain tuning with integral action, see Lab 02: tune a PID controller.