Inverted Pendulum Balancing

How balancing an inverted pendulum works

Stand a broomstick on your open palm and you already know the algorithm. The moment the stick tips, you slide your hand toward the lean — putting the support back under the falling top. The stick straightens, you've moved, and you do it again, dozens of times a second, without thinking. An inverted-pendulum controller is exactly that reflex written as math and run on a microcontroller.

The classic laboratory version is the cart-pole: a pole hinged at its base to a motorized cart that slides along a rail. The only thing the controller can command is the force on the cart — it cannot grab the pole directly. To stop the pole falling to the right, it accelerates the cart to the right, swinging the pivot under the center of mass. That single coupling — cart force in, pole angle out — is what makes the problem subtle and famous.

What makes it genuinely hard is that the plant is open-loop unstable. A normal hanging pendulum has a restoring torque: disturb it and it swings back. Invert it and the torque flips sign. The further the top-heavy mass leans, the harder gravity pulls it sideways, so the lean accelerates — error feeds on itself. There is no passive equilibrium to fall back to; the only thing keeping the pole up is the controller, running fast enough to catch the fall before it runs away.

The loop is the standard feedback shape. A sensor (an encoder on the hinge, or a gyroscope-plus-accelerometer pair fused by a Kalman filter) measures the tilt angle θ and its rate θ̇. The controller compares θ to the setpoint of zero, computes a corrective force, and the motor applies it. Run that comparison 100 to 1000 times a second and the pole holds vertical on a base that is constantly nudging itself.

The math

The cart-pole equations of motion come from the Lagrangian of a cart (mass M) carrying a pole (mass m, length to center of mass ℓ, so the full pole is 2ℓ). With θ measured from vertical and F the applied cart force:

Cart:   (M + m) ẍ + m ℓ θ̈ cos θ − m ℓ θ̇² sin θ = F
Pole:   ℓ θ̈ + ẍ cos θ − g sin θ = 0

Symbols:
  θ    pole angle from vertical (0 = upright)
  x    cart position along rail
  F    control force on cart (the only actuation)
  g    9.81 m/s²,  ℓ ≈ half the pole length

These are nonlinear and coupled, but near the upright equilibrium (θ small, so sin θ ≈ θ, cos θ ≈ 1, θ̇² ≈ 0) they linearize to a clean, instructive form:

Linearized pole dynamics (cart held, simple-pendulum limit):
L = effective pendulum length (pivot → center of mass, the ℓ above)

  θ̈ = (g / L) θ      →      poles at s = ± √(g / L)

One pole sits at +√(g/L) in the RIGHT half-plane → UNSTABLE.

Fall time constant:   τ = √(L / g)
  Pencil   (L = 0.30 m):  τ = 0.175 s   (very hard to balance)
  Broom    (L = 1.5 m):   τ = 0.39 s    (easy by hand)
  Segway   (L ≈ 1.0 m):   τ = 0.32 s

That right-half-plane pole is the whole story: a positive real pole means any tiny error grows like e^(t/τ). The controller's job is to move that pole into the left half-plane (stable) by feeding back the measured state. A textbook full-state law is:

F = −(k₁ θ + k₂ θ̇ + k₃ x + k₄ ẋ)

  k₁, k₂  stabilize the pole (angle + rate → like a PD controller)
  k₃, k₄  pull the cart back toward center (so it doesn't run off the rail)

A PID controller is the special case that uses only the angle terms (k₁ proportional, k₂ derivative, plus an integral term for steady bias). LQR computes all four gains at once by minimizing the cost ∫(xᵀQx + uᵀRu)dt — Q penalizes state error, R penalizes control effort — and is the standard optimal answer for the cart-pole.

Worked example: how fast must the loop run?

Take a two-wheeled balancing robot with its center of mass 0.25 m above the axle — a stout, pencil-like geometry. The effective pendulum length is L ≈ 0.25 m, so:

Fall time constant:   τ = √(0.25 / 9.81) = 0.16 s

Starting from a 1° lean (0.0175 rad), the angle grows like θ(t) = θ₀ e^(t/τ).
Time to reach a 10° lean (0.175 rad), where small-angle control breaks down:

  0.175 = 0.0175 · e^(t/0.16)
  e^(t/0.16) = 10  →  t = 0.16 · ln(10) = 0.37 s

So the controller has about a third of a second before a 1° wobble becomes an uncontrollable 10° topple. A control loop must sample, filter, and command many times within that window to react smoothly — which is why balancing robots run their inner loop at 200 to 500 Hz (every 2 to 5 ms), and Segway-class machines specify a redundant gyro/motor architecture that can ride out a single sensor or battery dropout long enough to set the rider down.

Now flip the length: a 1.5 m broomstick has τ = 0.39 s and time-to-10° of about 0.9 s — over twice as long. That extra margin is exactly why humans, with reaction times around 0.2 s, can balance a broom on a fingertip but not a pencil.

PID vs LQR vs swing-up control

	PID on angle	LQR (full-state)	Pole placement	Energy swing-up
State used	θ, θ̇ (+ ∫θ)	θ, θ̇, x, ẋ	θ, θ̇, x, ẋ	Total energy E, θ̇
Handles cart drift	No (drifts off rail)	Yes (penalizes x)	Yes	N/A (positioning phase)
Operating region	Near upright (≤ ~15°)	Near upright	Near upright	Full swing, hanging → top
Tuning	3 gains by hand / Ziegler-Nichols	Q, R weights → solve Riccati	Pick desired poles	1 energy gain
Optimality	None (heuristic)	Minimizes quadratic cost	None (places poles)	Minimum-time-ish
Nonlinear coverage	Poor	Poor (linearized)	Poor (linearized)	Good (designed for it)
Typical use	Hobby balancing bots	Segways, research carts	Teaching, simple plants	Acrobot, pendubot, demos

In practice the two are combined: an energy-shaping or bang-bang law swings the pole up from hanging, and once it's within roughly 15° of vertical the software switches to LQR or PID to catch and hold it. This hybrid switching controller is what every "pendulum swings itself up and balances" demo video is running.

Real-world examples

System	"Cart"	"Pole"	Notes
Segway / hoverboard	Two driven wheels	Rider + chassis	Inner loop ~100+ Hz; lean forward → wheels roll to chase the center of mass
Two-wheeled balancing robot	Motorized wheels	Robot body	IMU + complementary/Kalman filter; classic Arduino/STM32 hobby build
Human / humanoid standing	Ankle torque + feet	Whole body about the ankle	Human quiet standing is a real inverted pendulum stabilized by ankle muscles
Rocket on the pad / ascent	Gimbaled engine (thrust below CoM)	The vehicle	Thrust-vector control balances a pole pushed from the bottom — same instability
SpaceX-style booster landing	Gimbaled thrust + grid fins	The descending stage	Balances a tall body on a point of thrust — a moving-base inverted pendulum
Reaction-wheel cube (ETH Cubli)	Spinning flywheels	The cube balancing on an edge/corner	No cart at all — torque from braking a reaction wheel rights it
Acrobot / Pendubot	One actuated joint	Double pendulum, underactuated	Research benchmark for nonlinear and swing-up control

The reason the cart-pole shows up in every controls course is that it is the simplest system that is both unstable and underactuated — one actuator, more degrees of freedom than actuators. Master it and you have the conceptual toolkit for rocket thrust vectoring, legged-robot balance, and quadrotor attitude control, all of which are inverted pendulums wearing different hardware.

When the inverted-pendulum model applies

• A top-heavy body must hold an unstable orientation against gravity. Standing robots, Segways, and a person balancing on a slackline all reduce to a mass above a pivot.
• The actuator sits below or away from the center of mass. A rocket's gimbaled engine pushes from the bottom; correcting the lean means commanding a thrust angle, just as the cart commands a force.
• You can sense tilt fast and cheaply. MEMS gyros and accelerometers (a few dollars) plus sensor fusion gave hobby robotics the same state estimate that used to need a lab encoder — this is why balancing robots became a weekend project after about 2010.
• The fall is slow enough to catch. If τ = √(L/g) is comfortably larger than your loop period and actuator response time, stabilization is feasible. If the body is short and the motors slow, no controller can keep up.

Reach for a different model when the system is statically stable (a four-wheeled rover doesn't need balancing), when the actuation can directly cancel the disturbance (a gimbal stabilizer holding a camera is a regulation problem, not an unstable-balance problem), or when the body has a wide base and a low center of mass so it simply can't tip.

Common misconceptions and failure modes

• "A balancing robot stands still." It never does. Holding an unstable pole up requires continuous acceleration of the base, so the wheels perpetually dither and creep. A perfectly motionless balancing robot would already be falling.
• "Just use a bigger proportional gain." Crank k₁ too high and the cart slams under the pole, overshoots, and the system oscillates or saturates the motor. Real controllers need the derivative (rate) term to add damping — pure proportional balancing rings like a bell. This is the same lesson the PID controller teaches everywhere.
• The non-minimum-phase trap. To move forward, a balancing robot must first roll its wheels backward to tip the body forward, then chase it. Command position too aggressively and it lurches the wrong way first. This right-half-plane zero limits how fast the position loop can be — a fundamental, not a tuning, limit.
• Running out of rail (or floor). A pure angle controller will happily balance while the cart drifts off the end of the track. The position-feedback gains (k₃, k₄) or the LQR cart-position penalty must be present, and they trade off against disturbance rejection — the cart that returns to center fastest is also the one that tolerates the smallest shove.
• Linearizing too far. The small-angle model is only good to about 15° to 20°. Past that, sin θ ≈ θ fails, the real torque is larger than the model predicts, and an LQR gain set tuned at θ = 0 will under-correct and let the pole escape. Big disturbances need a nonlinear or gain-scheduled controller.
• Sensor lag and quantization. A cheap gyro with 10 ms of filtering delay eats a big slice of a 160 ms fall budget. Phase lag from over-filtering the angle estimate is a leading cause of "it balances for a second then oscillates and dies." Fast, low-lag state estimation (complementary or Kalman fusion) is as important as the control law itself.