Φferromotion · textbook · chapter 7 rust → wasm · on-device
Give a robot a path to follow and ask it to do so in the least possible time, and the answer is never a single speed — it must crawl through the corners and floor it on the straights. This page computes that time-optimal schedule with the same Rust solver the native tools use.
Suppose the shape of a motion is already decided — a planner handed you a path around the obstacles, or it traces a weld seam or a brush stroke. What is left is the timing: how fast to move along it at each point. Go too fast into a corner and you exceed what the motors can do; go slow enough for the corner everywhere and you crawl the straights for no reason. Somewhere between is the fastest traversal the hardware permits.
Below, two dots run the same path. The green one uses the time-optimal schedule; the grey one uses the single fastest speed that is safe everywhere — which is set by the tightest corner, so it is stuck crawling the whole way. Watch the green pull ahead on the straights and ease through the turn. The path itself is tinted by speed.
the lower plot is speed along the path: the time-optimal curve rides right under the velocity ceiling, dipping only where the path bends
What makes this solvable exactly is a change of variable. Write everything in terms of x = ṡ², the squared path speed. Then the joint velocities are linear in √x and the joint accelerations are linear in (s̈, x) — so every velocity and torque limit becomes a straight line in this space. Velocity limits put a ceiling on x — the maximum-velocity curve you see in the plot — and acceleration limits give, at each point, an interval of allowed path acceleration.
For a straight move the optimum is the textbook trapezoid — accelerate at the limit, cruise at top speed, brake at the limit — with a duration you can write down by hand. On load, this page solved that case and compared:
| TOPP duration (straight move, L=2, v=1, a=2) | … |
| analytic optimum L/v + v/a | … |
| agreement | … |
A geometric planner decides where to go; time-optimal parameterization decides how fast to go along it — squeezing every bit of speed the motors can give while never asking for more than they have.
The two halves compose cleanly, which is why they are usually separate. A sampling planner routes around the obstacles without worrying about dynamics; then this pass lays the fastest feasible timing onto that route. Loosen the acceleration limit above and the whole schedule speeds up; tighten it and the corners bite harder — but at every setting the traversal is provably the fastest the limits allow, not a hand-tuned guess. It is the same theme as the rest of this series: turn a hard problem into a place where the answer is forced, and then just read it off.
What you just drove: topp and ToppPath from ferromotion-control, compiled to WebAssembly — the same code the native tools link against. The path's derivatives are taken by finite differences; the solver runs a backward reachability pass and a greedy forward sweep in the x = ṡ² variable. Nothing precomputed — every slider move re-solves it.
Verified in the library: a straight move matches the analytic trapezoidal optimum, a short one the triangular optimum · the optimum is bang-bang — pinned to a limit >95% of the way · varying the speed beats any single safe speed · tighter limits take longer. Each is a test in cargo test, not a claim in prose. See also ch.1 · ch.2 · ch.3 · ch.4 · ch.5 · ch.6.
Institute for Physical AI · the Rust library · crates.io