Trajectory Generation & Motion Profiles — Robotics Reference

Scope. This note covers the time-parameterisation layer of robot motion: how to turn a geometric path or set of waypoints into a smooth, executable $\mathbf{q}(t),\dot{\mathbf{q}}(t),\ddot{\mathbf{q}}(t)$ stream that a tracking controller ([[Robotics/pid-control]], computed-torque, MPC) can follow without faulting the drives. Geometric path planning — RRT, PRM, A*, configuration-space collision checking — is the predecessor note [[Robotics/path-planning]].

1. At a glance

A trajectory is a time-parameterised curve in configuration space (or task space). It is strictly more than a path:

• Path = a geometric curve $\mathbf{q}(s)$ with $s\in [0,1]$ (collision-free, kinematically reachable).
• Trajectory = path + time, i.e. $\mathbf{q}(t)$ with $t\in [0,T]$, plus all derivatives the actuator needs to follow it (velocity, acceleration, often jerk).

Output of a trajectory generator: a triple (or quadruple) at every sample of the control loop.

Signal	Used by	Why
$\mathbf{q}(t)$	Position PID, impedance ctrl	Setpoint reference
$\dot{\mathbf{q}}(t)$	Velocity FF, D-on-PV	Feedforward; removes lag
$\ddot{\mathbf{q}}(t)$	Computed-torque, MPC	Drives $M(\mathbf{q})\ddot{\mathbf{q}}$ feedforward
$\stackrel{...}{\mathbf{q}}(t)$	Jerk-limited drives	Mechanical lifetime; passenger comfort

Why trajectory generation matters in robotics:

• The tracking error of any controller is dominated, at high speeds, by feedforward quality — and feedforward quality is dominated by the smoothness of the trajectory. A discontinuous $\ddot{\mathbf{q}}$ creates a jerk impulse that the actuator cannot reproduce, which the controller sees as a tracking error and over-reacts to. Smooth in, smooth out.
• Gearbox and harmonic-drive lifetime is governed by the integral of jerk at zero crossings of acceleration — bang-bang trapezoidal profiles wear gear teeth visibly faster than equivalent S-curve profiles on the same duty cycle (typical 2–5× ratio observed in cobot field-return data).
• A correctly time-parameterised trajectory respects every actuator constraint everywhere on the path — velocity limit, acceleration limit, torque limit, jerk limit. A naively-fast trajectory faults on the slowest axis.

Common variants (full taxonomy in §2):

• Trapezoidal velocity profile — accel / coast / decel. C¹, infinite jerk at corners. Default in most legacy CNC.
• S-curve (7-segment) jerk-limited profile — C², finite jerk. Default in modern industrial robots, cobots, and high-end CNC.
• Polynomial (cubic / quintic / septic / minimum-snap) — explicit closed-form coefficients from boundary conditions. Default for drone waypoints.
• Cubic / B-spline — piecewise polynomials with continuity at knots. Default for CNC contour machining and medical robotics.
• Time-optimal along path (TOPP-RA) — fastest time-parameterisation that respects all constraints; convex.
• Online jerk-limited generation (Reflexxes / Ruckig) — real-time, replans every cycle from arbitrary initial state.

First ask before picking a profile:

1. What’s downstream — joint controller or task-space tracker? (Joint trajectories are simpler; task-space needs IK at each sample.)
2. What’s the dominant constraint — velocity, acceleration, or torque? (Determines whether TOPP is worth the complexity.)
3. Single point-to-point move or multi-waypoint? (Single PtP is a closed-form polynomial; multi-waypoint needs splines or blending.)
4. Pre-computed once or replanned every cycle? (Offline → quintic / TOPP-RA; online → Ruckig.)
5. Will the controller saturate? (If yes — must respect actuator limits at generation time; tracking-loop saturation produces unbounded windup despite anti-windup in [[Robotics/pid-control]].)

2. First principles

Where trajectory generation sits in the motion stack

A typical robotic motion stack has five layers stacked from slow to fast:

1. Mission / task planner (1–10 Hz). Behaviour tree, state machine, LLM-driven planner. Outputs symbolic goals: “pick part A, weld seam B.”
2. Geometric path planner (1–10 Hz). RRT, PRM, A*, CHOMP, MoveIt. Outputs a collision-free configuration-space path $\mathbf{\sigma }(s)$, $s\in [0,1]$.
3. Trajectory generator (100–1000 Hz). Time-parameterises the path: $\mathbf{q}(t),\dot{\mathbf{q}}(t),\ddot{\mathbf{q}}(t)$. This note.
4. Joint controller (250 Hz–1 kHz). PID + feedforward; tracks the trajectory. See [[Robotics/pid-control]].
5. Motor current loop (8–40 kHz). FOC PI on $i_d,i_q$. See [[Robotics/motors-electric]].

Layers communicate by signal shape: planner $\to$ trajectory generator passes a path; trajectory generator $\to$ controller passes a stream of $(\mathbf{q},\dot{\mathbf{q}},\ddot{\mathbf{q}})$; controller $\to$ motor passes a torque or current command. Each layer must produce signals smooth enough that the next layer’s bandwidth is not the bottleneck.

Path vs trajectory — the time parameter

Given a geometric path $\mathbf{\sigma }:[0,1]\to \mathcal{C}$ (configuration space), a trajectory adds a time scaling $s(t):[0,T]\to [0,1]$ with $s(0)=0$, $s(T)=1$. The trajectory is then

$\mathbf{q}(t)=\mathbf{\sigma }(s(t)),\dot{\mathbf{q}}(t)={\mathbf{\sigma }}^{\prime }(s)\dot{s},\ddot{\mathbf{q}}(t)={\mathbf{\sigma }}^{\prime \prime }(s){\dot{s}}^2+{\mathbf{\sigma }}^{\prime }(s)\ddot{s}$

The decoupling matters: geometric constraints (collision, joint limits) live in $\mathbf{\sigma }$; dynamic constraints (velocity, accel, torque) live in $s(t)$. TOPP exploits exactly this split — fix $\mathbf{\sigma }$, optimise $s(t)$ to be time-optimal subject to dynamic constraints.

Continuity classes

Class	What’s continuous	What’s discontinuous	Typical use
$C^0$	position	velocity	Pose teleport (avoid)
$C^1$	position, velocity	acceleration	Linear interp, simple PtP
$C^2$	through acceleration	jerk	Trapezoidal (transitions only)
$C^3$	through jerk	snap	S-curve, quintic; modern industrial
$C^4$	through snap	crackle	Minimum-snap drones; CNC contouring

A robotics rule of thumb: make the trajectory smooth two derivatives deeper than the actuator can respond. Encoder-resolved $\ddot{\mathbf{q}}$ feedforward demands $C^2$; an electromechanical drive’s torque rise time (~1 ms) demands $C^3$ if you want clean jerk-limited motion at 1 kHz.

Joint-space vs Cartesian-space trajectories

• Joint-space: time-parameterise $\mathbf{q}$ directly. Cheap, smooth in joints, but the TCP path is curved in task space.
• Cartesian-space: time-parameterise $(\mathbf{p}(t),\mathbf{R}(t))$ in $SE(3)$. Straight-line tool motion (welding, laser cutting, dispensing, surgery require this) at the cost of an IK at every sample, plus singularity handling along the path.

The orientation part of a Cartesian trajectory is non-trivial: $\mathbf{R}(t)$ must lie on $SO(3)$. Two common parameterisations:

• SLERP (spherical linear interpolation, Shoemake 1985) between two quaternions ${\mathbf{q}}_0,{\mathbf{q}}_1$: $\mathbf{q}(s)=\frac{\sin ((1-s)\Omega )}{\sin \Omega }{\mathbf{q}}_0+\frac{\sin (s\Omega )}{\sin \Omega }{\mathbf{q}}_1,\cos \Omega ={\mathbf{q}}_0\cdot {\mathbf{q}}_1$ SLERP gives constant angular velocity; differentiate to get $\mathbf{\omega }(t)$.
• Lie-group exponential in $SO(3)$: $\mathbf{R}(s)={\mathbf{R}}_0\exp (s\log ({\mathbf{R}}_0^T{\mathbf{R}}_1))$. Identical curve, cleaner derivatives.

For derivatives in $SO(3)$ see [[Robotics/kinematics-dh]] §2 (geometric Jacobian).

Trapezoidal velocity profile

The classical profile: constant acceleration $a_{\max }$ until velocity $v_{\max }$, constant velocity, constant deceleration $-a_{\max }$.

Three regimes for a move of length $d$:

1. Triangular ($d<v_{\max }^2/a_{\max }$): never reach $v_{\max }$. Peak velocity $v_p=\sqrt{d{a}_{\max }}$, total time $T=2\sqrt{d/a_{\max }}$.
2. Trapezoidal ($d\ge v_{\max }^2/a_{\max }$): three-phase profile. Acceleration time $t_a=v_{\max }/a_{\max }$, constant-velocity time $t_c=d/v_{\max }-t_a$, total $T=t_c+2t_a$.
3. Edge ($d=v_{\max }^2/a_{\max }$): the triangle just touches $v_{\max }$ at one instant.

Pros: simple, time-optimal under velocity + acceleration limits, closed-form. Cons: infinite jerk at four transition points — every gearbox tooth feels each transition as a hammer blow.

S-curve (7-segment) jerk-limited profile

Add jerk-limited acceleration. The full trajectory has seven segments:

1. Jerk +J (accel ramp up) for $t_j$
2. Constant accel $a_{\max }$ for $t_{a1}$
3. Jerk −J (accel ramp down) for $t_j$
4. Constant velocity $v_{\max }$ for $t_v$
5. Jerk −J (decel ramp up)
6. Constant decel $-a_{\max }$
7. Jerk +J (decel ramp down)

Phase durations (symmetric profile):

• $t_j=a_{\max }/J$ (time to ramp acceleration from 0 to $a_{\max }$)
• $t_a=v_{\max }/a_{\max }-t_j$ (constant-accel segment length)
• $t_v=d/v_{\max }-v_{\max }/a_{\max }-a_{\max }/J$

When $t_a<0$ or $t_v<0$, segments collapse; full Biagiotti-Melchiorri (2008) decision tree has 15 cases for arbitrary initial / final state. Ruckig (Berscheid & Kröger 2021) handles them all online in <20 µs.

S-curve adds $\sim 10$–$20\%$ to total move time vs trapezoidal but extends gearbox life $2$–$5\times$ and removes audible “clack” at transitions. Universal in modern industrial robots and high-end CNC.

Polynomial profiles

For a single PtP move of duration $T$ with boundary conditions at $t=0$ and $t=T$:

• Cubic (4 BCs: position + velocity at both ends): $C^1$, sufficient for simple PtP.
• Quintic (6 BCs: position + velocity + acceleration at both ends): $C^2$, the industry standard for joint PtP when explicit accel BCs matter.
• Septic (8 BCs: position + vel + accel + jerk): $C^3$, used in high-precision applications (surgical, optical).
• Minimum-snap (Mellinger & Kumar 2011): $C^4$, drone-specific; minimises $\int |{\mathbf{q}}^{(4)}{|}^{2}dt$ to align with the differentially-flat quadrotor dynamics (snap $\propto$ motor angular acceleration).

The quintic from ${\mathbf{q}}_0,{\dot{\mathbf{q}}}_0,{\ddot{\mathbf{q}}}_0$ to ${\mathbf{q}}_f,{\dot{\mathbf{q}}}_f,{\ddot{\mathbf{q}}}_f$ in time $T$:

$q(\tau )=q_0+{\dot{q}}_{0}T\tau +\frac{1}{2}{\ddot{q}}_0{T}^2{\tau }^2+(10\Delta -6{\dot{q}}_{0}T-4{\dot{q}}_{f}T-1.5{\ddot{q}}_0{T}^2+0.5{\ddot{q}}_f{T}^2){\tau }^3+\dots$

with $\tau =t/T$, $\Delta =q_f-q_0$. Full coefficient table in Spong §5.4.

Splines

For multi-waypoint trajectories $\{{\mathbf{q}}_0,{\mathbf{q}}_1,\dots ,{\mathbf{q}}_n\}$ at times $\{t_0,\dots ,t_n\}$:

• Cubic spline: piecewise cubic with $C^2$ continuity at knots. Closed-form via tridiagonal solve, $O(n)$. Default for CNC g-code blending.
• Quintic spline: piecewise quintic with $C^4$ continuity. Heavier solve; needed when accel BCs at each knot must match.
• B-spline / NURBS: piecewise polynomial in Bernstein/de Boor basis. Local control — moving one knot affects only the adjacent few segments. NURBS adds rational weights for exact conics. Default for CNC contour interpolation since the early 2000s (Siemens 840D, Fanuc 30i NURBS option).

Time-optimal path parameterisation (TOPP)

Given a fixed geometric path $\mathbf{\sigma }(s)$, the time-optimal trajectory is the fastest $s(t)$ that respects all dynamic constraints (velocity, acceleration, torque) along the path. Bobrow, Dubowsky & Gibson (1985) and Shin & McKay (1985) independently showed the answer is bang-coast-bang in $\ddot{s}$: maximum forward acceleration until a constraint binds, switch to backward integration from the goal, intersect at the “switching point.” The construction handles only velocity and accel limits cleanly; torque constraints require multiple switching points and zero-inertia traps.

TOPP-RA (Pham 2014, 2017) reformulates the same problem as a second-order conic program on ${\dot{s}}^2(s)$ — convex, robust, and handles velocity / acceleration / torque / centripetal / dynamic-friction constraints uniformly. Open-source Python implementation at hungpham2511/toppra. Default time-parameteriser in MoveIt 2 since Iron Irwini.

Online jerk-limited generation (Reflexxes / Ruckig)

The original Reflexxes Motion Libraries (Kröger 2011, commercial) and their open-source successor Ruckig (Berscheid & Kröger 2021, BSD) solve a different problem: given arbitrary current state $(\mathbf{q},\dot{\mathbf{q}},\ddot{\mathbf{q}})$ and target $({\mathbf{q}}_f,{\dot{\mathbf{q}}}_f,{\ddot{\mathbf{q}}}_f)$ plus $(v_{\max },a_{\max },j_{\max })$, compute the next sample of a time-optimal jerk-limited trajectory in $<20\mu$s. Replan every cycle; handles tele-op, external triggers, and arbitrary mid-motion target changes.

Ruckig is the default trajectory generator in MoveIt 2 (Humble onwards), Franka FCI servo control, and several ROS 2-based cobot stacks.

Frenet-Serret framing for path-following on mobile bases

For non-holonomic mobile robots (Ackermann cars, differential drive), the natural decomposition is arc-length $s$ along the path + lateral / heading error. The Frenet-Serret frame at point $s$ on a planar path is

$\hat{\mathbf{t}}(s)={\mathbf{\sigma }}^{\prime }(s),\hat{\mathbf{n}}(s)=R_{90°}\hat{\mathbf{t}},\kappa (s)=\det [{\mathbf{\sigma }}^{\prime }{\mathbf{\sigma }}^{\prime \prime }]$

with $\kappa$ the path curvature. A vehicle tracking the path is described by its arc-length progress $s$, lateral offset $e_y$, and heading error $e_{\psi }$. Time parameterisation then chooses $\dot{s}(t)$ (longitudinal speed profile) and a lateral controller (pure-pursuit, Stanley, or MPC) closes the loop on $e_y$ and $e_{\psi }$. The longitudinal $\dot{s}(t)$ uses the same trapezoidal / S-curve / TOPP machinery as joint trajectories, with the extra centripetal-accel constraint ${\dot{s}}^2\kappa \le a_{\text{lat,max}}$.

Direct trajectory optimisation (collocation, DDP, sequential convex)

When the trajectory must respect a dynamic model and a task cost simultaneously — typical in legged locomotion, agile drone manoeuvres, and humanoid whole-body motion — the right formulation is a trajectory-optimisation OCP:

${\min }_{\mathbf{q}(\cdot ),\mathbf{u}(\cdot )}{\int }_0^T\ell (\mathbf{q},\dot{\mathbf{q}},\mathbf{u})dt+\varphi (\mathbf{q}(T))\text{s.t.}M(\mathbf{q})\ddot{\mathbf{q}}+h(\mathbf{q},\dot{\mathbf{q}})=\mathbf{u},\mathbf{u}\in \mathcal{U},\mathbf{q}\in \mathcal{C}$

Three solvers dominate:

• Direct collocation (Hargraves & Paris 1987; Drake Dircol): polynomial parameterisation of $\mathbf{q}(t)$ and $\mathbf{u}(t)$ at collocation points; constraints enforce dynamics. NLP solved by SNOPT / IPOPT.
• Differential dynamic programming (DDP) / iLQR (Mayne 1966; Tassa 2012): forward-rollout + backward-Riccati. Used in MuJoCo MPC and Crocoddyl.
• Sequential convex / SCP (e.g. SCvx, Mao 2018): linearise + trust region + convex subproblem. Used by SpaceX-style rocket trajectory; growing footprint in robotics.

These are not drop-in replacements for the time-parameterisation methods above — they synthesise both the geometric path and the time parameterisation. Use them when separating path planning from trajectory generation drops crucial dynamic information (e.g. cartwheels, jumps, dynamic grasps).

3. Practical math

Worked example A — Quintic polynomial joint trajectory

Move joint from $q_0=0$ to $q_f=\pi /2$ rad in $T=2.0$ s with zero velocity and zero acceleration at both endpoints.

Quintic ansatz $q(t)=a_0+a_{1}t+a_2{t}^2+a_3{t}^3+a_4{t}^4+a_5{t}^5$. The six BCs are $q(0)=0$, $\dot{q}(0)=0$, $\ddot{q}(0)=0$, $q(T)=q_f$, $\dot{q}(T)=0$, $\ddot{q}(T)=0$. Solving:

• $a_0=0,a_1=0,a_2=0$
• $a_3=10q_f/T^3=10(1.5708)/8=1.963$ rad/s${}^3$
• $a_4=-15q_f/T^4=-15(1.5708)/16=-1.473$ rad/s${}^4$
• $a_5=6q_f/T^5=6(1.5708)/32=0.2945$ rad/s${}^5$

Peak velocity at $t=T/2$: ${\dot{q}}_{\max }=15q_f/(8T)=15(1.5708)/16=1.473$ rad/s.

Peak acceleration at $t=T(1\pm \sqrt{3/5})/2\approx 0.225T$ or $0.775T$: ${\ddot{q}}_{\max }=10q_f/(\sqrt{3}{T}^2)=10(1.5708)/(1.732\cdot 4)=2.267$ rad/s${}^2$.

Peak jerk at $t=T/2$: ${\stackrel{...}{q}}_{\max }=60q_f/T^3=60(1.5708)/8=11.78$ rad/s${}^3$.

Sanity check against actuator limits. A Maxon EC-90 flat with 100:1 harmonic drive on a Franka-class joint has ${\dot{q}}_{\max }\approx 2.6$ rad/s, ${\ddot{q}}_{\max }\approx 15$ rad/s${}^2$ at the joint output — the quintic above sits comfortably under all three limits.

Worked example B — Trapezoidal profile sizing

Move 1.0 m linear axis with $v_{\max }=2.0$ m/s, $a_{\max }=5.0$ m/s${}^2$.

Acceleration time $t_a=v_{\max }/a_{\max }=0.4$ s. Distance during accel (one phase) $d_a=\frac{1}{2}{v}_{\max }{t}_a=\frac{1}{2}(2.0)(0.4)=0.4$ m. Both accel and decel phases together cover $2d_a=0.8$ m. Remaining $d-2d_a=0.2$ m at constant velocity → $t_c=0.2/2.0=0.1$ s.

Total move time $T=2t_a+t_c=0.8+0.1=0.9$ s.

Check the triangular case: minimum-distance for full trapezoidal is $d_{\min }=v_{\max }^2/a_{\max }=4.0/5.0=0.8$ m. Our $d=1.0$m exceeds it → trapezoidal applies. ✓

If we had asked for $d=0.5$ m, the profile would degenerate to triangular with $v_p=\sqrt{0.5\cdot 5.0}=1.58$ m/s and $T=2\sqrt{0.5/5.0}=0.632$ s.

Worked example C — S-curve (7-segment) sizing

Same 1.0 m move, same $v_{\max }=2.0$ m/s, $a_{\max }=5.0$ m/s${}^2$, plus jerk limit $J=50$ m/s${}^3$.

Phase durations (Biagiotti–Melchiorri, symmetric full-profile case):

• Jerk ramp time $t_j=a_{\max }/J=5.0/50=0.1$ s.
• Constant-accel time $t_a=v_{\max }/a_{\max }-t_j=2.0/5.0-0.1=0.3$ s.
• Distance during one accel block (jerk-up + const + jerk-down): $d_{\text{acc}}=v_{\max }\cdot (t_a+t_j)/2\cdot 2\approx 0.5v_{\max }(t_a+2t_j)$. Plugging in: $d_{\text{acc}}=\frac{1}{2}(2.0)(0.3+0.2)=0.5$ m.
• Both accel and decel blocks: $2d_{\text{acc}}=1.0$ m → equals $d$ → constant-velocity phase $t_v=0$.

Total move time $T=2(t_a+2t_j)+t_v=2(0.5)+0=1.0$ s. About $11\%$ longer than trapezoidal but $C^2$ in acceleration and jerk-bounded.

In real production (Ruckig, ros2_control trajectory_msgs), the algorithm checks all 15 degenerate cases (jerk-limited triangular, no constant-accel phase, no constant-velocity phase, asymmetric initial state) and returns the right one.

Worked example D — Time-optimal $s(t)$ for a 6-DOF arm along a fixed Cartesian path

A welding arm must traverse a 0.50-m straight-line seam at constant orientation. The geometric path $\mathbf{\sigma }(s)={\mathbf{p}}_0+s({\mathbf{p}}_1-{\mathbf{p}}_0)$, $s\in [0,1]$, is fixed. Each joint has ${\dot{q}}_{\max }=3.14$ rad/s and ${\ddot{q}}_{\max }=15$ rad/s${}^2$.

Mapping path-velocity to joint-velocity via the inverse Jacobian: $\dot{\mathbf{q}}={\mathbf{J}}^{-1}(\mathbf{q}(s)){\mathbf{\sigma }}^{\prime }(s)\dot{s}$. The joint-velocity limit becomes

${\dot{s}}_{\max }(s)={\min }_i\frac{{\dot{q}}_{i,\max }}{|[{\mathbf{J}}^{-1}{\mathbf{\sigma }}^{\prime }{]}_i(s)|}$

This is a path-dependent velocity ceiling; near a wrist singularity ${\dot{s}}_{\max }(s)\to 0$. Joint-accel translates similarly into a constraint on $\ddot{s}$ as a function of $(s,\dot{s})$ (Pham 2014, eq. 12). TOPP-RA solves the resulting convex programme on ${\dot{s}}^2(s)$; output: $\dot{s}(s)$ profile, integrate to get $t(s)$, invert to get $s(t)$.

Concretely: for a wrist-aligned welding path 0.5 m from the shoulder, joint 5 dominates the velocity bound at the seam midpoint; TOPP-RA returns $T\approx 0.95$ s vs the naïve constant-velocity assumption $T=d/v_{\max }=0.16$ s. The 6× gap is the cost of singularity awareness — without it, the controller faults mid-weld.

Worked example E — Joint-space vs Cartesian-space PtP comparison

Move a UR5e from TCP pose $(0.4,0.0,0.5)$ m at $\mathbf{R}=\mathbf{I}$ to pose $(0.4,0.4,0.5)$ m at $\mathbf{R}=\mathbf{I}$, holding orientation. Distance in task space: 0.4 m straight line in $+\hat{\mathbf{y}}$.

Joint-space quintic. IK at both endpoints gives ${\mathbf{q}}_0=(0,-1.57,1.57,-1.57,-1.57,0)$ and ${\mathbf{q}}_1=(\pi /2,-1.57,1.57,-1.57,-1.57,0)$. The dominant change is ${\theta }_1$ sweeping $\pi /2$ rad while the other joints hold. The quintic produces a TCP path that is a circular arc of radius $\approx 0.4$ m, not the straight line we asked for — but it’s smooth and fast (~0.4 s at default UR speeds).

Cartesian-space linear. Interpolate $\mathbf{p}(s)={\mathbf{p}}_0+s({\mathbf{p}}_1-{\mathbf{p}}_0)$, $s\in [0,1]$, with $s(t)$ a trapezoidal profile. At each control sample, run IK to get $\mathbf{q}(t)$. The TCP path is now a straight line, at the cost of: (a) IK overhead, ~50 µs × 1000 Hz = 5% CPU on the UR; (b) need to check the path doesn’t cross a wrist singularity (it doesn’t, in this example); (c) per-sample IK can return different IK branches, causing “elbow flip” — pin the configuration.

The Cartesian linear move is the right answer for welding, dispensing, scribing; the joint quintic is the right answer for fast re-positioning between operations.

4. Design heuristics

• Profile by use case.
  • Joint PtP, low duty cycle: cubic polynomial — cheapest, $C^1$, fine for assembly robots cycling once per minute.
  • Joint PtP, high duty cycle: quintic polynomial or S-curve — $C^2$ saves gearboxes.
  • Cartesian linear (welding, dispensing, scribing): linear in $\mathbf{p}$ with SLERP in $\mathbf{R}$, time-parameterised by trapezoidal or S-curve in $s$.
  • CNC contour: B-spline / NURBS in path with feed-rate-optimised $s(t)$. Look-ahead window of 100–1000 blocks.
  • Drone waypoint flight: minimum-snap polynomial (Mellinger & Kumar 2011). Aligns with the differentially-flat structure.
  • Surgical / tele-op: online Ruckig from teleoperator hand pose; jerk limit set conservatively for tissue interaction.
• Joint vs Cartesian. Default joint-space for PtP without geometric constraint; switch to Cartesian only when straight-line tool motion is part of the spec. Cartesian costs ~10× more compute (IK at every sample) and forces explicit singularity handling.
• Blending. At a waypoint where two segments meet, the controller can either pause (stop_then_move) or blend through. Parabolic blending (Khalil & Dombre §10) inserts a quadratic segment of length $r$ between the two linear pieces; the TCP cuts the corner by $\sim r^2/8R$ where $R$ is the corner radius. Industrial controllers expose this as blend_radius, Z-tolerance, CNT-value, or T_FINE/T_COARSE (Fanuc, ABB, KUKA respectively).
• Velocity scaling at runtime. Pre-compute a trajectory at nominal speed, then expose a scalar speed_override ∈ [0, 1.5] that re-parameterises $t\to t/\alpha$. Caution: $\dot{\mathbf{q}}$ scales linearly, $\ddot{\mathbf{q}}$ quadratically, $\stackrel{...}{\mathbf{q}}$ cubically — at 150% override, jerk is 3.4× higher. ros2_control’s time_factor clamps to 1.0 by default for this reason.
• Synchronise multi-axis moves. For a multi-joint PtP, compute each joint’s minimum time given its own $v_{\max },a_{\max }$; pick the slowest and stretch the others by scaling $T$. All joints then arrive simultaneously. Without this, fast joints finish early, then the controller holds them in position while slow joints catch up — visible as a jerky two-phase motion.
• Avoid singularities in Cartesian trajectories. Pre-screen $\det (\mathbf{J}(\mathbf{q}(t)))\cdot {\mathbf{J}}^T(\mathbf{q}(t)))$ along the path; if manipulability drops below threshold, re-time the trajectory to slow through the singular region (TOPP-RA accepts a manipulability constraint) or re-plan in joint space.
• Drone minimum-snap intuition. Differentially flat → position $(x,y,z,\psi )$ plus its first four derivatives uniquely determine motor angular accelerations. Minimising $\int \Vert {\mathbf{r}}^{(4)}{\Vert }^{2}dt$ along a polynomial path therefore minimises motor torque ripple → smooth, energy-efficient flight. Mellinger’s QP formulation: minimise snap subject to position / velocity continuity at waypoints. Solved at startup; in-flight replan with a polynomial reset.
• TOPP for fastest legal motion. When the path is fixed (CNC, surgical, taught teach-pendant move) and the actuators are the bottleneck, run TOPP-RA. Typical speed-up over hand-tuned constant-velocity: 2–4× cycle time reduction.
• Real-time generation in a 1 kHz loop. Quintic in joints: trivial closed-form, ~1 µs. Cubic spline: ~5 µs. Ruckig: 15–20 µs on Cortex-A72 (Berscheid benchmark). TOPP-RA: 5–50 ms — not real-time; pre-compute and replay.
• Constraint sources.
  • Joint position / velocity: datasheet (UR e-series: ${\dot{q}}_{\max }=3.14$ rad/s for axes 1–3; 6.28 rad/s for 4–6).
  • Joint acceleration: usually set by drive thermal limit, not gear; estimate from peak motor torque ÷ joint inertia at worst-case pose.
  • Joint jerk: rarely on datasheet; pick conservatively. Industry typical 30–100 m/s${}^3$ on prismatic, 50–200 rad/s${}^3$ on revolute.
  • Torque: from [[Robotics/dynamics-rigid-body]] — $\mathbf{\tau }=M(\mathbf{q})\ddot{\mathbf{q}}+C(\mathbf{q},\dot{\mathbf{q}})\dot{\mathbf{q}}+\mathbf{g}(\mathbf{q})$.
• Pre-screen for collisions, then time-parameterise. The separation principle: do collision-aware planning in $\mathcal{C}$ (the path planner’s job), do dynamics-aware time-parameterisation on the resulting path (this note’s job). If the path planner returns a piecewise-linear C-space path, run a one-pass smoother (e.g. shortcut iteration: pick two random points on the path, replace the section between with a quintic, accept if collision-free) before time-parameterisation — saves 20–60% of cycle time on typical industrial pick-and-place paths.
• Use $C^2$ everywhere a torque feedforward is consumed. A controller running computed-torque or model-based feedforward ${\mathbf{\tau }}_{\mathrm{ff}}=M(\mathbf{q}){\ddot{\mathbf{q}}}_{\mathrm{ref}}+h(\mathbf{q},{\dot{\mathbf{q}}}_{\mathrm{ref}})$ needs ${\ddot{\mathbf{q}}}_{\mathrm{ref}}$ continuous. A trapezoidal velocity profile has $\ddot{\mathbf{q}}$ as a square wave — the feedforward then drives a torque step into the drive every transition, exactly what jerk-limiting was supposed to avoid. Pair feedforward control with $C^2$ or smoother profiles.
• Tune the lookahead window to the controller’s settling time. CNC fine-block lookahead is 200–1000 blocks; an industrial robot’s “blend” is over 10–50 ms of motion. Too short → corner overshoot; too long → unnecessary memory, slower replanning. Rule of thumb: lookahead window = $5\times$ controller closed-loop rise time.
• Decouple the planner from the time-parameteriser. A well-architected stack has three layers: (1) symbolic / behaviour-tree mission planner; (2) geometric path planner (OMPL, MoveIt); (3) time-parameteriser (Ruckig, TOPP-RA, custom). Each is independently testable; each can be swapped. The 2018 MoveIt 1 → 2 transition is exactly this refactor.
• Don’t reinvent the wheel for jerk-limited online generation. Ruckig is BSD, well-tested, and ports to embedded targets (Cortex-M7 demonstrated). Reflexxes is now closed but its successor is the open-source default. Custom 7-segment solvers tend to ship with bugs in the rare degenerate cases (Biagiotti–Melchiorri lists 15; most homebrew solvers cover 3–5 cleanly).

5. Components & sourcing

Open-source trajectory libraries

Library	Language	License	What it does	Source
Ruckig (Berscheid & Kröger 2021)	C++ / Python	MIT	Online jerk-limited generation; arbitrary initial state; <20 µs	github.com/pantor/ruckig
TOPP-RA (Pham 2017)	C++ / Python	MIT	Convex time-optimal path parameterisation with torque + velocity + accel	github.com/hungpham2511/toppra
MoveIt 2	C++ / Python	BSD-3	Full motion planning + post-process to time-optimal trajectory	moveit.ros.org
OMPL (Şucan, Moll, Kavraki 2012)	C++ / Python	BSD-3	Sampling-based path planners; trajectory wrapper separate	ompl.kavrakilab.org
Drake (TRI / MIT)	C++ / Python	BSD-3	Direct collocation / DDP / sequential convex; full trajectory optim	drake.mit.edu
CHOMP / STOMP / TrajOpt	C++ / Python	BSD	Gradient-based trajectory optimisation for arms	github.com/ros-industrial-consortium/trajopt
MuJoCo MPC	C++ / Python	Apache-2	Real-time trajectory optimisation on MuJoCo plant model	github.com/google-deepmind/mujoco_mpc
Crocoddyl (LAAS-CNRS)	C++ / Python	BSD-3	DDP / FDDP for legged + arm robots	github.com/loco-3d/crocoddyl
toppra-MoveIt2 plugin	C++	BSD-3	TOPP-RA integration into MoveIt’s TimeParameterization	moveit.ros.org docs

Commercial / closed-source

• Reflexxes Motion Libraries (Kröger, acquired by Pilz then ABB; RML4 Type II = position+velocity, Type IV = jerk-limited). Original commercial precursor to Ruckig — still embedded in some Stäubli, ABB, KUKA, Pilz controllers.
• B&R Industrial Automation Motion Studio — S-curve and 5th-order polynomial generators with NC-block lookahead; deeply integrated with B&R servo drives.
• Siemens SINUMERIK 840D / ONE — NURBS interpolation, jerk-limited dynamic block (FFW + jerk + accel filtering); the de-facto reference in machine-tool CNC.
• Fanuc R-30iB / R-30iB Plus — internal time-optimal trajectory plus high-speed contouring options (CNT, T_FINE, ITP fine-rate up to 4 kHz).
• KUKA KSS / iiQKA.OS — spline interpolation (SPL, CIRC, LIN with $C^2$ blend), $C^3$ option for KUKA.SmartPad-touch cobots.
• Universal Robots URScript — movej (joint, jerk-limited), movel (linear, jerk-limited), movec (circular). User-tunable $a$ (rad/s${}^2$), $v$ (rad/s), blend radius r.

Hardware sourcing (rare — trajectory generation is mostly software)

Trajectory generation is the software stack on top of the actuator. The only hardware-specific elements are lookahead buffer depth (how many segments ahead the controller can see — Fanuc 80–500, Siemens 1000+, Heidenhain TNC 2000+) and interpolation rate (250 µs to 2 ms typical, 125 µs on the highest-end CNC). These influence what trajectory smoothness is useful: a $C^4$ trajectory is wasted on a 5 ms interpolator.

6. Reference data tables

Profile comparison

Profile	Continuity	Min duration (PtP)	Compute	Jerk-limited?	Use case
Trapezoidal	$C^1$	$T_{\min }=v_{\max }/a_{\max }+d/v_{\max }$	<1 µs	No	Legacy CNC, simple drives
S-curve 7-seg	$C^2$	$T_{\min }+2a_{\max }/J$	<5 µs	Yes	Industrial robots, cobots
Cubic poly	$C^1$	User-specified $T$	<1 µs	No	Joint PtP, education
Quintic poly	$C^2$	User-specified $T$	<1 µs	No (limited indirectly)	Joint PtP, surgical
Septic poly	$C^3$	User-specified $T$	<2 µs	Yes (boundary)	Optical, precision
Minimum-snap	$C^4$	QP solve	0.1–10 ms	No (snap-limited)	Drones
Cubic spline	$C^2$ knot-by-knot	${\sum }_i{T}_i$	$O(n)$	No	CNC blocks
B-spline / NURBS	$C^{k-1}$ for order $k$	${\sum }_i{T}_i$	$O(n)$ per eval	Indirectly	CNC contours
TOPP-RA	depends on path	Optimal	5–50 ms (offline)	Yes (via constraint)	Industrial cycles
Ruckig	$C^2$	$T_{\min }$ (jerk-bounded)	10–20 µs	Yes	Online tele-op, MoveIt 2

Typical 90° per-axis move time (1 kg payload, mid-workspace, ambient temp)

Robot	Trap (rad/s, rad/s²)	S-curve time	Quintic time
UR5e axis 2	$v=3.14,a=15$	0.43 s	0.50 s
KUKA Agilus KR6 axis 2	$v=6.28,a=30$	0.22 s	0.26 s
Franka Panda axis 4	$v=2.62,a=10$	0.55 s	0.62 s
ABB IRB 1200 axis 2	$v=4.36,a=20$	0.31 s	0.36 s

(Approximate; depends on payload, ambient, controller version. Use as starting estimate, not spec.)

Jerk limits by application

Application	Typical jerk limit	Source
Industrial 6-DOF arm joint	50–200 rad/s³	Manufacturer recommended (UR, Franka)
Cobot, payload-on-end	20–80 rad/s³	Conservative; passenger comfort analog
Delta robot (high-accel pick)	200–1000 rad/s³	ABB FlexPicker, Codian
CNC milling axis	50–500 m/s³	Siemens 840D defaults
CNC HSM (high-speed machining)	1000–5000 m/s³	Heidenhain TNC 640
Surgical robot (Da Vinci-class)	5–30 rad/s³	Tissue-trauma minimisation
Drone attitude inner loop	100–500 rad/s³	PX4 default MC_ROLLRATE_K
Automotive seat-comfort	0.5–2 m/s³	ISO 2631; passenger comfort limit
Elevator (cab acceleration)	1.5–2.5 m/s³	KONE, Otis comfort spec

Library function map

Need	ROS 2 / MoveIt 2	Native C++	Python
Joint PtP jerk-limited	JointTrajectoryController + Ruckig adapter	ruckig::Ruckig<7>	ruckig.Ruckig(7, 0.001)
Quintic poly joint	IterativeParabolicTimeParameterization (deprecated)	hand-rolled	numpy.polyfit w/ BCs
Time-optimal w/ torque	TimeOptimalTrajectoryGeneration (Pham 2017 wrapper)	toppra::Solver	toppra.algorithm.TOPPRA
Cartesian linear	compute_cartesian_path	moveit::core::CartesianInterpolator	move_group.compute_cartesian_path
Multi-waypoint spline	RobotTrajectory + smoothing pass	bspline_eval (Eigen-based)	scipy.interpolate.CubicSpline
Drone min-snap	mav_trajectory_generation	mav_trajectory_generation	nlopt + polynomial

S-curve closed-form relations (Biagiotti–Melchiorri 2008, symmetric case)

For a rest-to-rest move of distance $d$ with limits $(v_{\max },a_{\max },J)$:

Quantity	Formula
Jerk phase time	$t_j=a_{\max }/J$
Const-accel time	$t_a=v_{\max }/a_{\max }-t_j$ (valid iff $\ge 0$)
Const-velocity time	$t_v=d/v_{\max }-(v_{\max }/a_{\max }+t_j)$ (valid iff $\ge 0$)
Total time (full profile)	$T=t_v+2t_a+4t_j$
Peak acceleration	$a_{\max }$
Peak jerk	$J$
Min distance for full profile	$d_{\min }=v_{\max }(v_{\max }/a_{\max }+t_j)$
Min distance for accel-cap reached	$d_{\mathrm{acc}}=a_{\max }{t}_j^2+a_{\max }^2/J$ ($=2a_{\max }^2/J$ symmetric)

When $t_a<0$ the constant-accel phase vanishes; when $t_v<0$ the constant-velocity phase vanishes; when both are negative we are in a pure jerk-limited triangular profile. Each of the 8 sign-combination cases × 2 initial-state asymmetries gives Biagiotti–Melchiorri’s 15 degenerate variants.

Quintic polynomial peak relations (rest-to-rest, zero accel at boundaries)

For $q_0,{\dot{q}}_0=0,{\ddot{q}}_0=0\to q_f,{\dot{q}}_f=0,{\ddot{q}}_f=0$ in time $T$, with $\Delta =q_f-q_0$:

Quantity	Formula	Where
Peak velocity	${\dot{q}}_{\max }=15\Delta /(8T)$	$t=T/2$
Peak acceleration	${\ddot{q}}_{\max }=10\Delta /(\sqrt{3}{T}^2)$	$t=T(1\pm \sqrt{3/5})/2$
Peak jerk	${\stackrel{...}{q}}_{\max }=60\Delta /T^3$	$t=T/2$
Snap at boundary	$q^{(4)}(0)=q^{(4)}(T)=0$	(cubic spline cannot achieve this)

Inverting: to hit a given ${\dot{q}}_{\max }$, set $T=15\Delta /(8{\dot{q}}_{\max })$. To hit a given ${\ddot{q}}_{\max }$, set $T=\sqrt{10\Delta /(\sqrt{3}{\ddot{q}}_{\max })}$. The binding constraint is whichever yields the larger $T$.

Cubic polynomial peak relations (rest-to-rest, no accel BC)

For $q_0,{\dot{q}}_0=0\to q_f,{\dot{q}}_f=0$ in time $T$:

Quantity	Formula
Peak velocity	${\dot{q}}_{\max }=3\Delta /(2T)$ at $t=T/2$
Peak acceleration	${\ddot{q}}_{\max }=6\Delta /T^2$ at $t=0$ and $T$ (step)
Jerk	$-12\Delta /T^3$ (constant; $C^1$ only)

The cubic’s acceleration is a step at boundaries — the cubic is $C^1$ but not $C^2$. Use quintic when this matters.

Common discretisation rates

Layer	Rate	Notes
Motor current loop	8–40 kHz	FOC PI; not a trajectory consumer
Joint velocity loop	1–4 kHz	Sees ${\dot{\mathbf{q}}}_{\mathrm{ref}}$
Joint position loop	250 Hz–1 kHz	Sees ${\mathbf{q}}_{\mathrm{ref}},{\dot{\mathbf{q}}}_{\mathrm{ref}}$
Cartesian / TCP loop	100–250 Hz	Sees $({\mathbf{p}}_{\mathrm{ref}},{\mathbf{R}}_{\mathrm{ref}})$
Trajectory generation	100–1000 Hz	Ruckig online; can be slower if pre-computed
Motion planning	1–10 Hz	RRT, OMPL; not in tight loop
Mission / task	0.1–10 Hz	Behaviour-tree / state-machine

7. Failure modes & debugging

Most trajectory-generation bugs manifest in the layer above (controller, motor drive, gearbox) and look like tracking, vibration, or thermal problems. The diagnostic discipline is: log ${\mathbf{q}}_{\mathrm{ref}}(t),{\dot{\mathbf{q}}}_{\mathrm{ref}}(t),{\ddot{\mathbf{q}}}_{\mathrm{ref}}(t)$ alongside the controller’s measured response, and check the reference itself before chasing the controller. A surprising fraction of “PID tuning” sessions turn out to be “fix the trajectory” sessions.

• Velocity-limit fault mid-move. Symptom: drive faults with “speed exceeded” near peak velocity. Cause: trajectory generated assuming joint ${\dot{q}}_{\max }$ at output, but at output the gear-ratio scaling was missed. Fix: cross-check trajectory $\dot{\mathbf{q}}$ against the output-side datasheet limits; remember UR / Franka publish joint-output limits, while raw motor specs are gear-ratio higher.
• Torque-limit fault at start of fast move. Symptom: drive faults with “torque exceeded” in the first few ms. Cause: ${\ddot{\mathbf{q}}}_{\max }$ in trajectory exceeds what $M({\mathbf{q}}_0)\ddot{\mathbf{q}}+\mathbf{g}({\mathbf{q}}_0)$ allows at the starting configuration. Fix: TOPP-RA with torque constraint, or hand-derate $a_{\max }$ by the worst-case inertia (typically 2–10× ratio across workspace).
• Joint-limit violation at midpoint. Symptom: trajectory passes through a joint limit even though endpoints are inside. Cause: Cartesian quintic in task space ignored joint configuration; or polynomial overshoot in joint space at high speed. Fix: pass intermediate waypoints; or generate in joint space; or use Ruckig with joint position limits enabled.
• Singularity crossing in Cartesian trajectory. Symptom: end-effector velocity is bounded but joint velocity spikes near the wrist-singularity region. Cause: ${\mathbf{J}}^{-1}$ blow-up. Fix: damped least squares in the trajectory generator, or replan to avoid the wrist-aligned subset of $SE(3)$. See [[Robotics/kinematics-dh]] §3.
• End-of-trajectory vibration. Symptom: ringing for 100–500 ms after a fast move completes. Cause: low-damped under-tuned PID over-reacts to a near-step in $\ddot{\mathbf{q}}$ at the final segment boundary. Fix: increase profile smoothness ($C^2\to C^3$); raise notch filter on D; tune controller damping ratio.
• Jerky Cartesian motion from joint-space quintic. Symptom: $\mathbf{q}(t)$ is smooth but the TCP path looks lumpy on a laser tracker. Cause: smooth $\mathbf{q}$ ≠ smooth ${\mathbf{T}}_0^n(\mathbf{q})$ — the Jacobian’s curvature distorts the task-space path. Fix: if straight-line TCP matters, generate in Cartesian space; else this is a feature, not a bug.
• Self-collision from joint-space planning. Symptom: trajectory generator returns success, but the simulated arm passes a link through itself. Cause: trajectory generator only respects single-joint constraints, not collision. Fix: add a collision-aware post-check (MoveIt’s IsoStateValidityChecker) or move the collision check to the path-planning stage.
• Long planning time on repetitive cycles. Symptom: pick-and-place cell idles 200 ms per cycle waiting for plan. Cause: re-planning every iteration of an identical motion. Fix: cache the trajectory, replay with a velocity-override scalar; only replan when the pick or place pose moves outside a small tolerance.
• Multi-axis arrival mismatch. Symptom: joint 1 reaches target 50 ms before joint 3. Cause: each axis generated independently with its own $T$. Fix: synchronise — compute per-axis $T_i$, take $T={\max }_i{T}_i$, regenerate every axis at the slower $T$.
• Blending overshoot. Symptom: end-effector cuts the corner more than expected. Cause: blend radius too large vs $v_{\max }$. Fix: shorten blend radius or reduce velocity through the corner.
• Discrete-time sampling mismatch. Symptom: trajectory generator outputs at 100 Hz, controller runs at 1 kHz; the controller sees a staircase reference. Cause: missing interpolation between trajectory samples. Fix: linear (or cubic-spline) interpolation between trajectory points inside the controller.
• Floating-point drift on long-running trajectories. Symptom: a 12-hour continuous trajectory drifts cumulatively. Cause: t += dt accumulates rounding. Fix: use t = k * dt from a step counter, not t += dt.
• Over-smooth trajectory hides controller bandwidth issue. Symptom: tracking RMSE drops to <0.1 mm at slow speeds but blows up at full speed; user concludes “the controller is fine, the path is just hard.” Cause: trajectory smoothness mask is hiding controller bandwidth limits. Fix: re-tune controller with a step input to reveal closed-loop bandwidth; raise gains or add feedforward; don’t paper over a control problem with a smoother trajectory.
• Quaternion sign flip in SLERP for Cartesian orientation. Symptom: orientation rotates the “long way” around between two near-equal quaternions. Cause: quaternion double-cover ($\mathbf{q}\equiv -\mathbf{q}$). Fix: at every waypoint check ${\mathbf{q}}_0\cdot {\mathbf{q}}_1<0$; if so, negate one. Standard fix; production code in Eigen, ROS tf2, and Drake.
• Reverse motion at start of an S-curve. Symptom: with nonzero initial velocity opposite to motion direction, the 7-segment profile briefly accelerates backward before turning around. Cause: this is mathematically correct for arbitrary initial state and a jerk limit — Ruckig handles it. Fix: if the application can’t tolerate the reverse phase, either (a) tighten the initial-velocity setpoint to zero before issuing the move, or (b) raise the jerk limit so the reversal is shorter.

8. Case studies

Three production systems that exercise the full taxonomy: a closed-source cobot SDK (UR), an open-source ROS 2 stack (MoveIt 2 + Ruckig), and a consumer drone (DJI Phantom 4). A fourth — Siemens 840D sl — covers high-end CNC NURBS.

Universal Robots URScript — movej, movel, movec with built-in blending

The UR e-series controller exposes three motion primitives:

• movej(q, a, v, r) — joint-space PtP, jerk-limited 7-segment profile. a is acceleration in rad/s², v is velocity in rad/s, r is blend radius in m.
• movel(pose, a, v, r) — Cartesian linear, jerk-limited in $s$; SLERP in orientation. a is m/s², v is m/s.
• movec(pose_via, pose_to, a, v, r) — circular arc through pose_via to pose_to.

Default values: $v_{\max }=1.05$ rad/s (60°/s), $a_{\max }=1.4$ rad/s², jerk internally limited to keep transitions smooth. Operators tune $v$ and $a$ by feel — increase until the next link doesn’t visibly wobble on stop. The blend radius $r$ trades cycle time against path accuracy; $r=0$ pauses at the waypoint, $r=$ link-length blends smoothly. Public docs at universal-robots.com/articles/ur/programming/.

The closed-form joint trajectory generation runs in ~50 µs per axis on the controller’s Cortex-A53 — fast enough to replan every 8-ms control cycle when an external sensor changes the target mid-motion.

MoveIt 2 + Ruckig — the modern ROS 2 default

Since MoveIt 2 Humble (May 2022), the default TrajectoryProcessor in JointTrajectoryController is Ruckig. The pipeline:

1. OMPL or pilz_industrial_motion_planner produces a path in configuration space.
2. TimeOptimalTrajectoryGeneration (Pham 2017 algorithm, MoveIt’s name for TOPP-RA-style processing) adds a time-optimal $s(t)$ respecting joint velocity + accel limits.
3. Ruckig smooths the output to be jerk-limited and replans online to absorb tracking error or external commands.

The Ruckig step replaced the legacy IterativeParabolicTimeParameterization because the parabolic blend introduced visible cusps at waypoints — the jerk-limited Ruckig output is visibly smoother on a laser-tracker measurement.

The full chain runs in <50 ms for an 8-waypoint, 7-DOF arm trajectory — fast enough for interactive replanning in user-facing applications. Source: moveit2/moveit_ros/move_group/src/default_capabilities/ and the Ruckig integration PR #1248.

DJI Phantom 4 / Mavic — minimum-snap waypoint flight

DJI’s mission-planning app lets a user place waypoints on a satellite map; the drone’s onboard planner (a derivative of Mellinger & Kumar 2011) generates a piecewise-polynomial trajectory through the waypoints, minimising the integral of $\Vert {\mathbf{r}}^{(4)}{\Vert }^2$ subject to position + velocity + acceleration continuity at each waypoint. The QP is solved once on flight start (a 10-waypoint mission takes <100 ms); subsequent in-flight target updates retrigger a partial resolve.

The chosen profile is then handed to a cascaded controller: outer position loop tracks $\mathbf{r}(t)$, attitude inner loop tracks the desired thrust vector implied by $\ddot{\mathbf{r}}(t)+g\hat{\mathbf{z}}$, and the angular-rate innermost loop closes at 1 kHz. The differentially-flat structure means the polynomial trajectory provides exact feedforward for the entire stack — visible flight-test result: position tracking RMSE <0.5 m at 15 m/s through 90° corners. Public reference: DJI Onboard SDK 4.x and Mellinger’s original PhD thesis (UPenn 2012).

Siemens SINUMERIK 840D sl — NURBS toolpath + dynamic block lookahead

A high-end 5-axis machining centre running on Siemens 840D sl controllers does not run polynomial joint trajectories — it runs NURBS toolpaths delivered as g-code (G6.2 / BSPLINE). The CAM (Mastercam, Fusion 360, PowerMill) outputs a sequence of NURBS control points, knots, and weights; the controller’s interpolator evaluates the curve at the servo rate (250 µs or 125 µs on ONE), with feed-rate $\dot{s}(t)$ optimised to respect machine-axis velocity, acceleration, and jerk limits.

The 840D’s “Look Ahead” function reads 200–1000 blocks of upcoming g-code, identifies sharp curvature regions (corners, contour reversals, kinematic singularities of the 5-axis mechanism), and pre-slows $\dot{s}(t)$ before reaching them. The S-curve DYNNORM / DYNROUGH / DYNFINISH mode trades smoothness vs throughput, with DYNFINISH enforcing the tightest jerk limit (~30 m/s³) for surface-finish-critical regions.

Why NURBS instead of cubic splines: NURBS represent conics exactly (a circle is a degree-2 NURBS with rational weights), and they have local control — moving one control point only affects a few adjacent segments. The trade-off vs polynomials is computational: NURBS evaluation needs the de Boor recursion, ~20 multiplications per sample vs ~5 for a cubic. On modern hardware (the 840D ONE uses a Sitop with 4-core x86-64) this fits comfortably in the 125-µs interpolator budget.

Public reference: Siemens SINUMERIK 840D sl Programming Manual rev 11/2023, sections “Spline interpolation (BSPLINE)” and “Dynamic Block Lookahead (LOOKAH)“.

9. Cross-references

• [[Robotics/kinematics-dh]] — Cartesian-space trajectories need IK at every sample; trajectory-side singularity handling.
• [[Robotics/dynamics-rigid-body]] — torque limits along the trajectory: $\mathbf{\tau }=M(\mathbf{q})\ddot{\mathbf{q}}+\dots$; consumed by TOPP-RA as a constraint.
• [[Robotics/pid-control]] — the consumer of trajectory $\mathbf{q}(t),\dot{\mathbf{q}}(t),\ddot{\mathbf{q}}(t)$; tracking quality depends on smoothness.
• [[Robotics/path-planning]] — planned sibling note; produces geometric path that this note time-parameterises.
• [[Robotics/state-space-lqr]] — planned sibling; LQR + feedforward consumes the same trajectory.
• [[Robotics/manipulator-design]] — planned sibling; joint inertia / gearbox lifetime considerations that justify jerk-limited profiles.
• [[Robotics/motors-electric]] — drive torque and current limits at the actuator end of the trajectory.
• [[Robotics/sensors-pose-motion]] — encoder bandwidth bounds the usable trajectory smoothness.
• [[Engineering/classical-control]] — Laplace / Bode foundations; explains why filtered derivative + smooth reference avoid spectral excitation.
• [[Engineering/digital-control]] — discretisation, anti-aliasing, sample-rate selection.
• [[Languages/Tier3/robotics-control]] — ROS 2 trajectory_msgs/JointTrajectory, URScript, KRL trajectory primitives.
• [[Languages/Tier3/industrial-automation]] — planned sibling Tier 3 for g-code and NURBS toolpaths.

10. Citations

1. Bobrow, J.E., Dubowsky, S. & Gibson, J.S. “Time-Optimal Control of Robotic Manipulators Along Specified Paths.” International Journal of Robotics Research, 4(3):3–17, 1985. The canonical TOPP paper; bang-coast-bang construction.
2. Shin, K.G. & McKay, N.D. “Minimum-time control of robotic manipulators with geometric path constraints.” IEEE Transactions on Automatic Control, 30(6):531–541, 1985. The other independent TOPP derivation.
3. Pham, Q.-C. “A General, Fast, and Robust Implementation of the Time-Optimal Path Parameterization Algorithm.” IEEE Transactions on Robotics, 30(6):1533–1540, 2014. The numerically robust precursor to TOPP-RA.
4. Pham, H. & Pham, Q.-C. “A new approach to time-optimal path parameterization based on reachability analysis.” IEEE Transactions on Robotics, 34(3):645–659, 2018. The TOPP-RA convex reformulation.
5. Mellinger, D. & Kumar, V. “Minimum Snap Trajectory Generation and Control for Quadrotors.” IEEE International Conference on Robotics and Automation (ICRA 2011), 2520–2525. The minimum-snap formulation; cornerstone of modern drone trajectory generation.
6. Berscheid, L. & Kröger, T. “Jerk-limited Real-time Trajectory Generation with Arbitrary Target States.” Robotics: Science and Systems (RSS 2021). The Ruckig algorithm paper; superseded Reflexxes as the open-source standard.
7. Kröger, T. On-Line Trajectory Generation in Robotic Systems. Springer Tracts in Advanced Robotics 58, 2010. The original Reflexxes Type IV derivation; the most thorough treatment of online jerk-limited generation.
8. Biagiotti, L. & Melchiorri, C. Trajectory Planning for Automatic Machines and Robots. Springer, 2008. ISBN 978-3-540-85628-3. Encyclopaedic reference on profile design; the 15-case S-curve decision tree.
9. Constantinescu, D. & Croft, E.A. “Smooth and time-optimal trajectory planning for industrial manipulators along specified paths.” Journal of Robotic Systems, 17(5):233–249, 2000. Jerk-bounded TOPP variants.
10. Khalil, W. & Dombre, E. Modeling, Identification and Control of Robots. Hermes Penton, 2002. ISBN 978-1-903996-66-9. Canonical industrial-robot motion control reference; parabolic blending derivation.
11. Lynch, K.M. & Park, F.C. Modern Robotics: Mechanics, Planning, and Control. Cambridge University Press, 2017, chapter 9. Free PDF at hades.mech.northwestern.edu/index.php/Modern_Robotics.
12. Spong, M.W., Hutchinson, S. & Vidyasagar, M. Robot Modeling and Control, 2nd ed., Wiley, 2020. ISBN 978-1-119-52399-3. Chapter 5 on trajectory generation.
13. Siciliano, B., Sciavicco, L., Villani, L. & Oriolo, G. Robotics: Modelling, Planning and Control. Springer, 2010. ISBN 978-1-84628-642-1. Chapter 4 on trajectory planning; the European reference.
14. LaValle, S.M. Planning Algorithms. Cambridge University Press, 2006. Free online at lavalle.pl/planning/. Chapter 14 on differential constraints and trajectory.
15. Shoemake, K. “Animating rotation with quaternion curves.” SIGGRAPH 1985 Proceedings. The original SLERP paper; standard for $SO(3)$ trajectory orientation.
16. MoveIt 2 documentation. PickNik Robotics / Open Source Robotics Foundation, https://moveit.picknik.ai/. Current rev tracks ROS 2 Lyrical (2026).
17. Ruckig documentation. Berscheid & contributors, https://docs.ruckig.com/. Rev 0.14 (2026).
18. TOPP-RA documentation. Pham et al, https://hungpham2511.github.io/toppra/. Rev 0.7 (2025).
19. OMPL — The Open Motion Planning Library. Şucan, Moll, Kavraki, https://ompl.kavrakilab.org/. Rev 1.6 (2025).
20. URScript Manual. Universal Robots A/S, rev 5.13, 2023-10. movej, movel, movec specifications.
21. Siemens SINUMERIK 840D sl Programming Manual. Siemens AG, rev 11/2023. NURBS interpolation (G6.2), jerk-limited dynamic block (DYNNORM).
22. PX4 Autopilot Documentation — Multicopter Position Controller. PX4 Dev Team, https://docs.px4.io/. Rev v1.15 (2026).