AI Glossary / Mathematics and optimization / Intermediate
Trajectory optimization
Definition
Trajectory optimization chooses a time-varying sequence of states and controls that minimizes a specified cost while satisfying dynamics and other constraints. It can optimize how a system moves between conditions, balancing quantities such as effort, duration, or tracking error. A valid trajectory must respect the mathematical model, not merely draw an attractive path between endpoints.
What it means
A path describes geometric locations, while a trajectory also specifies how the system evolves through them over time. A vehicle cannot generally follow any drawn curve at any speed: acceleration, control limits, and its equations of motion matter.
The optimizer may choose positions, velocities, control inputs, and sometimes duration. Its objective defines what “best” means. Minimizing time can produce a different movement from minimizing squared control effort. The resulting plan is normally an open-loop reference unless feedback or repeated replanning is incorporated separately.
How it works
Specify initial and terminal conditions, state dynamics, permitted controls, state constraints, and the cost. Convert the continuous or discrete-time problem into a finite optimization representation when necessary.
Direct shooting chooses controls and obtains states by forward simulation. Direct transcription includes states and controls as decision variables and imposes dynamic consistency constraints. Direct collocation represents trajectories with interpolating functions and enforces dynamics at selected points.
The optimization may be convex in special cases, but nonlinear dynamics and obstacle avoidance often create nonconvexity. Initial guesses and discretization can affect the solution found. After solving, independently check dynamics, constraints between sample points, and sensitivity to model error. A numerically feasible discretized plan is not automatically a validated continuous-time or real-world motion.
Three practical examples
1. Robot movement: choose actuator commands that move a mechanism between poses while respecting modeled limits and collision constraints.
2. Process control: plan a sequence of inputs that brings a system to a desired operating condition with a specified effort or tracking objective.
3. Simulation studies: compare feasible maneuvers under different duration, energy-proxy, or control-limit assumptions before testing a physical controller.
Think of it this way
Think of planning a journey with both a route and an itinerary that accounts for how quickly you can change speed. The shortest-looking route may not yield the fastest or least demanding journey.
The analogy does not replace dynamics. In an optimization model, the permitted changes are determined by equations and constraints. Real disturbances can also disrupt the planned itinerary, which is why a reference plan and a feedback controller serve different roles.
Worked example
Consider an original two-step discrete system xnext=x+u. Start at x0=0, require x2=3, and constrain each control to 0≤u≤2. Minimize the effort proxy J=u0²+u1².
The terminal condition requires u0+u1=3. Substituting u1=3−u0 gives J=u0²+(3−u0)²=2(u0−1.5)²+4.5. The minimum is therefore attained at u0=u1=1.5, both within the control limits.
The state trajectory is x0=0, x1=1.5, x2=3. Its cost is 4.5. The feasible alternative controls (1,2) produce states (0,1,3) and cost 5, so they are worse under this particular objective.
Now add an intermediate requirement x1≤1. Because x1=u0 and u1≤2 while their sum must be 3, the only feasible controls are u0=1 and u1=2. The optimum becomes 5. This shows how a state constraint can change both the movement and its minimum cost.
The calculations solve this small discrete model exactly. Squared controls are an assumed effort proxy here, not a demonstrated physical energy measurement. No robot execution or numerical solver run is claimed.
Illustrative case study
Fictional case: Vale Automation plans a demonstrator's movement using a dynamics model and actuator bounds. Its first optimizer output looks smooth, but a denser simulation reveals a constraint violation between the chosen time samples.
The team refines the representation, rechecks the continuous trajectory, and tests a feedback controller against model perturbations. It treats solver success as one part of validation rather than permission to assume the motion is reliable. The case illustrates an engineering review process and does not claim a tested physical safety outcome.
Common misconceptions and mistakes
A trajectory is not merely a list of geometric waypoints. Timing and dynamic feasibility distinguish it from a path.
Solver convergence does not always imply a global optimum, particularly in nonconvex problems. Nor does satisfying constraints at a sparse set of nodes guarantee that interpolated segments satisfy them everywhere.
Do not confuse an open-loop plan with a policy that responds to disturbances. Model predictive control can repeatedly solve a trajectory problem, but the surrounding feedback, estimation, and real-time execution requirements are additional parts of the system.
Business use
Trajectory optimization can make trade-offs explicit and expose whether desired motion is feasible under a model. It also gives a reference against which simpler controllers or manual plans can be compared.
Select objectives with meaningful units and weights, and document any proxy such as squared control. Report terminal error, constraint margins, discretization settings, and solver status. Assess computational deadlines and fallback behavior where replanning is required. A good deployment validates the model and execution system as well as the optimization formulation.
People also ask
Does trajectory optimization always minimize travel time?
No. The objective can involve effort, tracking error, duration, or a chosen combination.
Can duration be a decision variable?
Yes, in suitable formulations with necessary bounds and constraints.
Is direct collocation exact?
It is a numerical representation of the continuous problem. Accuracy depends on the model, interpolation, mesh, and validation, even when optimization tolerances are small.
Check your understanding
Why does adding x1≤1 force controls (1,2) in the worked problem?
Answer: The first state equals u0, so u0≤1. Reaching x2=3 with u1≤2 requires u0≥1. Together they give u0=1 and u1=2.
Related terms
- Path planning
- Optimal control
- state trajectory
- control input
- direct shooting
- direct transcription
- direct collocation
- model predictive control
- dynamic feasibility
Learn next
Solve the two-step example with different terminal targets and control limits, checking feasibility before minimizing cost. Then add a velocity state to see how dynamics restrict the plan. Study discretization and shooting versus collocation before applying a nonlinear solver to a more complex motion problem.
More in Mathematics and optimization
- Absolute error loss - Absolute error loss measures a numerical prediction's error as the absolute difference between its predicted and reference values: L(y,y-hat)=|y-y-hat|.
- Active-set method - An active-set method is an optimization approach that works with a changing subset of constraints believed to be tight at the solution.
- Adjoint state method - The adjoint state method computes how a chosen objective changes when the parameters of a mathematical model change.
- Σ-algebra
- Algebraic connectivity - Algebraic connectivity is the second-smallest eigenvalue of a graph's Laplacian matrix.
- Algorithm IMED - Algorithm IMED, short for Indexed Minimum Empirical Divergence, is a method for choosing actions in a stochastic multi-armed bandit problem.
Sources
Primary source: Russ Tedrake's MIT Underactuated Robotics notes, “Trajectory Optimization”, https://underactuated.mit.edu/trajopt.html . Direct shooting, transcription, continuous-time discretisation, and collocation discussions were read. The two-step optimization and added-constraint analysis are original exact calculations, not a reported implementation or physical experiment.
Previous: Trajectory Next: Transaction data