Blog · 2026-08-15 · Stability
Robots fall over in four distinct ways, and each has its own threshold, warning signs and fix. Knowing which one is about to happen to your robot is the difference between designing margin in and discovering the limit the expensive way.
Every tip-over is the same underlying event — the line of gravity through the centre of mass escapes the polygon of ground contact points — but the ways of getting there are different enough to be worth treating separately. Static slope, cornering, braking and obstacle strikes each have their own equation, and crucially, each interacts differently with traction. This article walks through all four, and then through the fixes that actually help.
Before the four cases, one idea that shapes all of them. A robot pushed hard sideways can do one of two things: slide, when the tyres run out of grip, or tip, when geometry runs out of margin. Whichever threshold is lower wins.
sliding threshold: a = g × µ
tipping threshold: a = g × (half spacing ÷ CoG height)
With rubber on a hard floor, µ is around 0.8, so the sliding threshold is about 7.8 m/s². A robot with a 180 mm track and a 90 mm CoG height has a tipping threshold of 9.8 m/s² — higher, so that robot slides first. Improve the grip (carpet, µ ≈ 1.0 → 9.8 m/s²) or raise the CoG a little, and the ordering flips.
The simplest. Park a robot on a ramp and increase the angle; it tips when the slope equals its static stability angle, atan(half spacing ÷ CoG height). Pointing up or down the ramp uses half the wheelbase; sideways across it uses half the track width — and since most robots are wider than they are long between contact points, or vice versa, one orientation is always worse. A robot crossing a slope diagonally is at its most vulnerable.
In practice sliding usually intervenes: on a µ = 0.8 surface, a robot starts sliding down at about 39°, so a robot whose tip angle is 45° will slide before it topples. On a grippy surface with a tall robot, the reverse happens. Real ramps also aren't the only concern — a robot climbing onto a doorway threshold is briefly on a very steep local slope.
Turning generates lateral acceleration, and lateral acceleration acts exactly like tilting the world sideways.
lateral acceleration a = v² ÷ R
maximum safe speed v = √( a_limit × R )
The square in that first equation is what catches people. Doubling speed quadruples the lateral force. A robot that corners a 500 mm radius comfortably at 1 m/s experiences four times the force at 2 m/s — which is why tip-overs so often happen the first time someone raises the speed limit in code, and why they feel like they come out of nowhere. Tight turns are worse for the same reason: halving the radius doubles the acceleration at the same speed.
Differential drive robots have a specific hazard here: commanding a hard turn at speed produces the tightest radius the robot can achieve, which is also its highest lateral acceleration. Rate-limiting how fast the commanded turn rate can change — rather than allowing an instant step from straight to full turn — costs almost nothing and removes most cornering tip-overs. The wheel speeds involved come out of the Differential Drive Calculator.
Same physics, rotated 90°. Hard braking transfers weight forward and can pitch the robot over its front contact points; hard acceleration does the reverse. The threshold is g × (half wheelbase ÷ CoG height), using the fore-aft dimension.
Two things make this worse than it looks. Differential-drive robots often have a short effective wheelbase — the distance from the drive axle to the caster — so the fore-aft margin can be much smaller than the sideways one. And motors braking abruptly (or reversing) generate very high decelerations; an aggressive stop command is a genuine tip hazard on a tall robot. It's also, incidentally, the biggest current spike your power system will see, which links this to voltage sag and brownouts — the same abrupt stop that threatens a tip can also brown out the controller.
The one no equation covers cleanly. Hitting a wall, a table leg or a raised threshold stops the wheels almost instantly while the robot's mass keeps moving, producing a deceleration far beyond anything the motors could generate. Robots that survive every calculated scenario tip here.
The mitigations are mostly not mathematical. Bump sensors and forward-facing distance sensors let the robot slow before contact. A compliant bumper spreads the impulse over a longer time, which is exactly what reduces peak deceleration. And keeping approach speeds modest near obstacles is free. If a robot must operate in cluttered space, the obstacle case — not the cornering case — is usually what sets the real speed limit.
1. Lower the centre of gravity. It appears in the denominator of every threshold in this article, so it improves all four cases simultaneously. Moving the battery to the baseplate is often worth 10–20° of stability angle for zero cost — the practical procedure is in Robot Centre of Gravity.
2. Widen the track or lengthen the wheelbase. Equally effective mathematically, and often easier mechanically than relocating mass. Adding a trailing caster to extend the effective wheelbase specifically addresses the braking case.
3. Limit acceleration in software. Ramp velocity commands rather than stepping them, and rate-limit turn commands. This is the cheapest fix on the list and the one most often skipped; it also improves odometry (less wheel slip) and reduces current spikes.
4. Cap speed as a function of turn radius. Rather than a single global speed limit, compute the lateral acceleration the current command implies and scale speed down for tight turns. A handful of lines of code that eliminates the entire cornering category.
5. Detect tilt and react. An IMU reporting roll and pitch lets the robot notice it's on a slope or beginning to tip, and respond by slowing, straightening or stopping. On robots that operate unattended, this is the difference between a near-miss and a repair.
Take a robot with a 180 mm track, 200 mm wheelbase, CoG 90 mm high, rubber wheels on vinyl. Sideways tip angle: 45°. Fore-aft: 48°. Sliding threshold: 7.8 m/s²; lateral tipping threshold: 9.8 m/s² — it slides first, good. Maximum cornering speed on a 500 mm radius: √(7.8 × 0.5) ≈ 1.98 m/s, comfortably above anything this robot will do. Now raise the CoG to 150 mm by putting the battery on an upper deck: the tip angle falls to 31°, the tipping threshold drops to 5.9 m/s², it now tips before it slides, and safe cornering speed falls to 1.7 m/s with a much worse failure mode. One component, moved 60 mm, changed the robot's entire safety character.
Not directly — they raise the chassis and therefore the CoG, which hurts. They help with obstacle clearance, which reduces the fourth case. Net effect depends on which problem you actually have.
Its support polygon is larger and better shaped, so yes for the same dimensions — a three-wheel robot's polygon is a triangle, and the direction toward the single wheel is much weaker than the others. But CoG height still dominates both.
Only low down. Ballast on the baseplate lowers the average CoG and helps; the same mass on a deck makes things worse. Weight itself never appears in the tipping equations — only its position does.
Calculated thresholds are predictions; it's worth confirming them once, on purpose, in conditions you control. The tilt test is the easiest: place the robot on a board and slowly raise one end until it either slides or lifts a wheel. Note the angle — a phone's inclinometer works fine — and compare it to the calculated figure. A large discrepancy usually means your centre of gravity estimate is off, which is useful to know before relying on it.
The cornering test needs space and a spotter. Run a fixed-radius circle and increase speed in small steps, watching the inside wheels. A wheel that begins to unload — visible as the robot leaning, or as that wheel losing traction — is the warning shot before a tip. Stop there and note the speed; that's your real limit, and it's usually somewhat below the calculated one because the calculation assumes rigid suspension and perfectly even loading.
Do both tests over something soft, with the robot's expensive components either protected or temporarily removed, and with a hand ready. The point is to learn where the edge is while a tip costs nothing — because the alternative is finding out during a demo, on a hard floor, with an audience.
Four cases, one ratio underneath all of them, and five fixes in descending order of value. Run your geometry through the Robot Stability Calculator to see which limit you hit first — and if the numbers look tight, finding and lowering your centre of gravity is where to start.