All simulations
Simulation · Control · PID

Inverted pendulum

A cart on a track, a pole balancing on top, and a controller trying to keep the pole vertical. Play with the gains first — then read on for the math and intuition behind why PID barely works on this problem.

controller active
θ(t) — angle from vertical
last 8s

Try Kp=0, Ki=0, Kd=0 to watch gravity win. Then slide Kp and Kd up.

The setup

x = 0xMmLθmgF
The cart-pole. The cart slides on a track; the pole pivots freely on top.

A cart of mass rolls along a track. A pole of mass and half-length is hinged to the cart by a free pivot, so the moment it tilts, gravity pulls it over. The single thing we get to control is a horizontal force on the cart. Two things to track:

  • — the cart’s position from the middle of the track.
  • — the pole’s tilt from vertical (zero = upright).

Mental picture: balancing a broom on your palm. You don’t push the broom directly — you move your hand. Same trick.

The numbers we’ll use

We’ll keep the math symbolic in what follows. When we want a concrete answer, we’ll plug these in.

SymbolValueMeaning
1.0 kgCart mass
0.1 kgPole mass
0.5 mPole half-length (CoM distance from pivot)
9.81 m/s²Gravity
20 NForce saturation (each direction)
±2.4 mTrack half-length
1/240 sIntegration step (semi-implicit Euler)
Step 1

Modeling: writing the physics down

Question · How do the cart and pole move when we push?

Newton’s laws say any acceleration must come from a net force or torque. Sum the forces on the cart, sum the torques on the pole, and keep careful track of how the pole’s rotation drags on the cart’s motion (and vice versa).

The result is a coupled pair of nonlinear equations with and in them. But for balancing, stays small, so we use the approximations and . The equations collapse into:

Read these in plain English. The first one is for the whole system. The second one says the pole’s angular acceleration depends on (a) how fast the cart is jerking (which swings the pole around) and (b) how far the pole has already tilted — because gravity on a tilted pole creates a torque that tilts it more.

That last bit, , is positive feedback. More tilt → more torque → more tilt. Left alone, this is a runaway — and the controller’s whole job is to break it.

Step 2

From equations to a transfer function

Question · Is there a single object that captures how the system behaves?

A transfer function answers one question: poke the input , what shape does the output take? Picture it as a box that takes force in and gives angle out.

F(s)G(s)plantθ(s)
Open-loop view: the plant takes a force and produces an angle.

The trick to deriving is the Laplace transform. Don’t worry about the details — just hold this fact: it turns into multiplication by a variable . Differential equations turn into algebra. Solve the linearized pair from Step 1 for :

The most important thing about a transfer function is its poles — the values of that make the denominator zero. Poles are the system’s natural modes: how it moves when nobody is controlling it. Setting the denominator to zero and solving for :

Plugging in the values from the parameters table, that’s about . Two poles, on the real axis, symmetric about the origin:

Re(s)Im(s)unstablestable+3.97−3.97units: rad/s
Pole-zero map. Anything in the right half-plane grows on its own — the +3.97 pole is gravity tipping the pole over.

A pole on the right side of the -plane means the system grows on its own — any tiny error blows up like . The time constant seconds is how long it takes for a microscopic disturbance to tip the pole noticeably. That’s gravity, written in math: a ball balanced on top of a hill.

The job of any controller is to feed force back based on what we measure, in a way that drags that right-half-plane pole into the left half — where things decay instead of blow up.

Step 3

The wrong-way trick (non-minimum phase)

Question · What makes cart-pole harder than other balancing problems?

Look back at the transfer function: . There’s a minus sign in front. It says: push the cart right, the pole tips left. Obvious in hindsight — yank a rug right, the broom on it falls left.

Now suppose the cart has drifted left and you want to bring it back to center. The naïve thing is to push right. But the moment you push right, the pole tips left — and now you have a falling pole on top of a cart still on the wrong side of the track. Worse, not better.

The maneuver that actually works is sneakier. To move the cart right, you first push left for a brief moment. That tilts the pole right. Now you chase the rightward-leaning pole by pushing right, and the cart ends up centered with the pole upright.

The system has to go the wrong way before it goes the right way.

This is called non-minimum phase. You’ve felt it:

  • A bicycle: to turn left, you steer right first (countersteering).
  • A car backing up: turn the wheel one way, the rear swings the other.
  • An aircraft pulling up: the elevator on the tail pushes down first, which makes the nose pitch up.

Every one of these needs a controller patient enough to commit to short-term wrongness in exchange for long-term rightness. As we’ll see, this is exactly what PID is bad at.

Step 4

The controller: PID

Question · What's the simplest feedback rule we can try?

A controller is a rule: look at the system, decide what force to apply. To use it, we wrap it around the plant in a feedback loop — measure the output, compare against where we want it, feed the difference into the controller.

θref= 0+ePIDFG(s)plantθmeasured θ (feedback)
Closed-loop view. The controller drives the error e = θ_ref − θ to zero by commanding force F.

For us the reference is “pole upright” — i.e. , so the error is just . Now: what goes inside the controller box?

PID — proportional, integral, derivative — is the most common answer in industry. It is three opinions about the same error, added together.

eKpP · proportionalKi / sI · integralKd · sD · derivativeΣF
Inside the PID box. Each branch answers a different question about the error e.
  • P · Proportional — “How wrong is it now?” Push back proportionally to the current error. Like a spring. Term: .
  • I · Integral — “How long has it been wrong?” Sum the error over time. If something keeps the pole leaning by a hair, the integral grows until it overpowers the bias. Term: .
  • D · Derivative — “How fast is it getting worse?” Push back against the rate of change. Like a shock absorber. Term: .

Add the three voices together:

But this only fights tilt. The pole could be perfectly upright while the cart slides off the end of the track. So we add a second, gentler piece of feedback that pulls the cart back toward the middle:

Defaults you can play with above: , with cart gains fixed at . The output is clipped to and the integrator is clamped to so it can’t run away.

Tuning intuition: turn up → stiffer, but the pole overshoots. Add → damping, oscillations die down. Add only if a small steady lean won’t go away on its own.

Step 5

Where PID falls short

Question · Why does this controller barely work, and how does it fail?

PID is famous because it works well enough on a huge fraction of real systems. Cart-pole is one of those systems where it just barely works, and the seams show. Each issue below is reproducible in the sim above.

It only knows about “upright”

We tuned the gains assuming , only true near . Once the pole tips past about 30–60°, stops applying the right amount of force in the right direction, and gravity wins. The sim flags the pole as fallen at 60° because nothing the linearized PID does will bring it back from there. Recovering from a fallen pole would need a different controller — a swing-up policy — entirely.

It can’t recenter the cart

The non-minimum-phase trap from Step 3, biting back. To bring the cart home, the controller has to deliberately tip the pole the wrong way for a moment. But the angle PID is doing its job — the instant any tilt appears, it slams it back to zero. That kills the very wrong-way move that would have recentered the cart.

The position term and the angle term play tug-of-war: the position term wants to drag the cart back, but it can only do so by goingthroughthe angle, which the angle PID won’t allow. The cart settles wherever those two forces happen to balance — often uncomfortably close to a wall. Try the Nudge button and watch.

It treats one variable at a time

The cart-pole really has four states — — and they affect each other in subtle ways. PID looks at one error (angle), decides one force. The position bit is a separate, weaker afterthought we bolted on. A more honest controller (LQR, pole placement, MPC) picks all four feedback gains together so the wrong-way trick is built into the design, not fought against.

Saturation and integrator windup

Real actuators don’t have infinite force. We cap at 20 N. While the actuator is maxed out, the integral keeps adding up unaddressed error. When the system finally responds, the over-built integrator hugely overshoots. The fix — clamping the integrator (“anti-windup”) — is what we do, but it’s a band-aid PID needs precisely because it has no awareness that the actuator was saturated in the first place.

It doesn’t know the model

The deepest limitation. PID never sees . It can’t predict what’s about to happen — it only reacts to what already has. For systems that are slow, friendly, and well-instrumented, that’s plenty. For systems with delays, non-minimum-phase coupling, multiple coupled inputs, or hard constraints, controllers that do know the model — LQR, model-predictive control (MPC), and modern learned policies — eventually win.

None of this means PID is bad. It is the right tool for thermostats, motor speed loops, drone attitude — single-input, single-output problems where the dynamics are mild. Cart-pole is the canonical “PID can just barely” demo. That’s exactly why it’s the standard teaching system: it shows you everything PID can do, and the cliff where the next chapter of control theory starts.

Things to try

  • Open loop: turn the controller off. The pole falls, the cart rolls — gravity and the right-half-plane pole in action.
  • Kp only: set and watch the pole oscillate forever. No damping = no settling.
  • Too much Kp: push it past 100 with no derivative and watch the cart slam into the track edges.
  • Nudge: kick the pole mid-flight. See how fast it recovers — and notice the cart drift afterward, the non-minimum-phase cost being paid in real time.