A route is not yet a motion
Imagine you have just asked a planner for a way across a cluttered room, and it hands you back a tidy list of waypoints: go here, then here, then here, then the door. That list is a path — a purely geometric route, a curve through space with no clock attached. It tells the robot *where* to go but says nothing about *when*. The difference between a path and a real motion is the heart of this guide, and the term for it is path vs trajectory.
A trajectory is that same route with velocities and a clock bolted on: at this moment be here moving this fast, a tenth of a second later be there. A path answers "which points?"; a trajectory answers "which point at which instant, and how fast?" Only a trajectory can be handed to the motors, because a motor needs to know a target *for every tick of time*, not just a sequence of destinations.
Why does timing matter so much? Picture driving by jumping instantly from waypoint to waypoint at full speed: the robot would lurch, slam to a halt, and tip its payload over. The fix is to glide through the waypoints — accelerate smoothly, hold a comfortable cruising speed, and ease to a stop. The step that adds this clock and smooths the speeds is called time parameterization, and it is what converts a bare path into something a real machine can follow.
Bending the path into a good trajectory
Raw planner output tends to be jagged — full of sharp corners and zig-zags, because the planner only cared about avoiding obstacles, not about comfort. Trajectory optimization is the craft of bending that rough route into a smooth, low-cost curve. You write down what "good" means as a cost — penalize jerky changes, penalize getting close to walls, penalize wasted time — and then let an optimizer nudge the curve until that cost is as low as possible.
Crucially, the optimizer is not free to do anything. It works under hard limits: a top speed, a maximum acceleration, and often a cap on jerk (the rate of change of acceleration — what you feel as a sudden snap). These limits come from the motors and the mechanics, and a good trajectory respects every one of them while still getting where it needs to go. Think of it as the difference between a nervous learner stamping the pedals and an experienced driver flowing through traffic.
There is an older, beautifully intuitive cousin of this idea worth meeting: the artificial potential field. Imagine the goal as a magnet that pulls the robot toward it, and every obstacle as a hill that pushes it away. The robot simply rolls downhill along the combined force, sliding toward the goal while being repelled from walls. It is cheap and elegant, though it can get stuck in a valley that is not actually the goal — a so-called local minimum — which is one reason optimization and sampling methods are often layered on top.
Why a car cannot slide sideways
Here is where many clever paths quietly die. Not every robot can move in every direction it can point to. The distinction is holonomic vs nonholonomic motion. A holonomic robot can move instantly in any direction regardless of how it is facing — think of an omnidirectional drive platform on special wheels that can scoot directly sideways without ever turning. A nonholonomic robot cannot.
A car is the classic nonholonomic example, and you already know it in your bones. A car cannot slide straight sideways into a parallel-parking gap — it has to shuffle forward and back, swinging its nose, because the front wheels only steer; they cannot crab. That steering geometry has a name, Ackermann steering, and it forbids sideways slip. A simpler two-wheeled robot using differential drive is also nonholonomic: it can spin in place but cannot translate sideways without first rotating.
This constraint reshapes which paths are even feasible. A planner that ignores it might happily draw a sharp right-angle turn or a sideways nudge — geometrically valid, physically impossible for a car. A constraint-aware planner instead produces curves the vehicle can actually trace: gentle arcs with a minimum turning radius, and gear changes when it needs to reverse. The path stops being a free sketch and becomes something the wheels can honestly carry out.
When a clever path still cannot be driven
Put the pieces together and a sobering truth appears: a path can be geometrically perfect — shortest, clearest, most elegant — and still be undriveable. Maybe it asks for a sideways slide the car cannot make. Maybe its corners are too sharp for the steering radius. Maybe it demands an acceleration the motors cannot deliver, or a speed change so abrupt no smooth trajectory can honor it. The map said yes; the machine says no.
This is exactly why real systems split the work between a planner that finds a rough global route and a local layer that turns it into feasible, timed motion — the split known as global planner vs local planner. The global planner sketches the long route across the map; the local planner, living closer to the hardware, reshapes each short stretch into a trajectory the robot can truly execute, respecting its motion constraints and its motor limits moment by moment.
So the journey of this guide is the journey of a single trip: a planner hands you a path, you wrap it in a clock and smooth it into a trajectory, you bend that trajectory to respect speed and acceleration limits, and you double-check that it obeys how the robot is allowed to move. Only when all of that holds does the list of points finally become motion — something the wheels can carry out without a stumble.