Tilt the beam by angle θ and a rolling ball accelerates along it at x″ = (5/7)g·sin θ — the 5/7 factor comes from a solid sphere's rotational inertia sharing the load with its linear motion. Critically, there's no damping term at all in that equation: nothing in the physics itself slows the ball down. The beam angle is driven by a simulated servo with a small response lag (τ ≈ 0.15 s), and the PID controller commands that angle from the ball's position error. If the ball leaves the beam — whether it separates mid-flight or rolls straight off the end — it becomes a real projectile under gravity and drag, and lands on the floor below with a genuine coefficient-of-restitution bounce, not a scripted animation. The whole thing is integrated with RK4, the same verified method used throughout this site.
Set every gain to zero except Kp = 6 and the ball doesn't oscillate gently — it rolls off the end of the beam at t = 0.67 s, becomes a projectile, and hits the floor bouncing. At the default 50% bounce elasticity, each bounce keeps about a quarter of the previous one's height (0.372 m → 0.093 m → 0.023 m, a ratio of ≈0.247 ≈ restitution² as the physics predicts) before coming to rest around t = 1.5 s. Add Kd = 4 and the identical proportional gain now settles smoothly at the target instead — nothing about the ball changed, only the controller's ability to react to its velocity, not just its position.
The plant is a pure double integrator (position needs two integrations from angle, with zero natural damping) — under proportional-only feedback that combination is only marginally stable in the idealised case, and the small extra lag from the simulated servo tips it into genuine instability. It's one of the cleanest classroom demonstrations of why "just add more P" doesn't always work.
Since nothing in the physical system opposes the ball's motion, the controller has to supply that damping itself. The derivative term reacts to how fast the error is changing, which is exactly the missing velocity feedback the system needs to settle instead of overshoot forever.
With a well-tuned P and D, the ball already settles very close to the setpoint — integral action mops up any small remaining steady-state offset, but too much of it (relative to P and D) can reintroduce oscillation, the same trade-off as any PID loop.
Any balancing problem built on a double integrator with no natural damping: a Segway or self-balancing robot, a rocket balancing on its thrust, magnetic levitation, or the classic inverted pendulum. Ball-and-beam rigs are a staple of university control labs precisely because they're a physical, visible version of this family of problems.
Because it genuinely shouldn't — for rolling without slipping, mass cancels out of the acceleration equation, the same reason a bowling ball and a marble roll down a ramp at the same rate. Making mass affect the on-beam physics would mean faking a result real mechanics doesn't produce. It matters once airborne instead, through air drag, which is real and mass-dependent.
It becomes a genuine projectile — real gravity, real air drag, no scripted fallback. If it re-lands within the beam's span it bounces there with the same restitution physics; if it clears the beam entirely or rolls off the end, it keeps falling until it hits the floor below, bouncing and losing energy each time until it settles.