Trajectory Planning in Robotics: A Practical Guide for Manipulators and Mobile Robots

What Trajectory Planning Robotics Actually Solves

Your Franka Panda picks parts flawlessly on Tuesday. On Wednesday someone slides the parts bin 4 cm to the left, swaps the gripper payload from 1 kg to 3 kg, and the same motion that ran for six months starts overshooting, vibrating audibly, and tripping protective stops every fourth cycle. You open the MoveIt2 documentation looking for the fix and find fourteen planner options — RRTConnect, PRM, CHOMP, STOMP, TrajOpt, and a dozen variants — with no clear guidance on which one solves your actual problem.

Trajectory planning robotics is the layer that decides this — and most teams misdiagnose where their motion problems actually live. This guide covers what trajectory planning solves, the three algorithmic families you'll encounter, how to integrate them into ROS2 and MoveIt2, the real-world constraints that invalidate naive plans, and when to skip planning entirely in favor of pre-trained skills.

The scale matters. According to the International Federation of Robotics, 553,000 new industrial robots were installed globally in 2022, and North America alone installed 44,303 units, up 12% year-over-year. Every one of those arms runs a trajectory planner. Most of them run a poorly-tuned one.

Table of Contents

• What Trajectory Planning Robotics Actually Solves
• The Three Algorithm Families
• Integrating Trajectory Planning into ROS2 and MoveIt2
• Real-World Constraints That Break Naive Plans
• Pre-Trained Skills vs. Custom Trajectory Planning
• Benchmarking Your Trajectory Planner
• FAQ — Implementation and Troubleshooting
• Pre-Deployment Validation Checklist

---

What Trajectory Planning Robotics Actually Solves

Motion stacks operate as a four-layer hierarchy: Task Planning → Path Planning → Trajectory Planning → Trajectory Following (Control). Each layer owns a distinct piece of the problem, and confusing them is the most common source of deployment delay. Sebastian Castro's MathWorks framing of this hierarchy is the cleanest summary available.

The definitions matter more than they appear:

• A path is a geometric curve in configuration space parameterized by an abstract scalar s ∈ [0,1]. It contains no time information.
• A trajectory is a path plus a time scaling s(t) mapping t ∈ [0,T] to s — adding velocity, acceleration, and (optionally) jerk profiles.
• Motion control is the closed-loop feedback that drives joints to follow the trajectory reference.

Kevin Lynch states this directly in Modern Robotics, Section 9.1: "A path can be turned into a trajectory by defining a function s(t)… This function is called a time scaling. The time scaling controls how fast the path is followed."

The concrete failure case: a Franka manipulator using MoveIt2's RRTConnect planner finds a collision-free path in 0.5–3 seconds on a 7-DOF arm, with success rates of 96–100% for typical pick-and-place scenarios, per Chitta et al.'s MoveIt benchmark. But the raw RRT path is jagged. Joint trajectories have discontinuous velocity at every sample node. Without time-parameterization (trapezoidal or S-curve profile), the controller either rejects the trajectory outright or executes it with audible vibration and 2–3× slower cycle time than necessary.

Trajectory planning owns the timing, not the geometry — confusing the two delays deployment by weeks and produces robots that move correctly but move badly.

What trajectory planning owns:

1. Time-scaling the geometric path under joint velocity limits — typical industrial 6-DOF: 100–250°/s per the KUKA KR Agilus datasheet.
2. Respecting joint acceleration limits of 100–400°/s² depending on payload.
3. Smoothing jerk (rate of acceleration change) to reduce mechanical vibration and extend gearbox life.
4. Ensuring the parameterized motion stays inside collision-free corridors established by the path planner.

What trajectory planning does not own:

• Finding the path itself — that's the sampling-based or grid-based path planner.
• Closing the loop on tracking error — that's the joint controller, typically PID, computed-torque, or impedance.
• Reacting to dynamic obstacles in under 10 ms — that's reactive control or MPC, not classical planning.

The deployment implication is direct: if your robot is slow, jerky, or hitting protective stops, the fix may not be your planner. It may be your time-parameterization, your URDF joint limits, or your controller gains. Misdiagnosing this costs weeks. Teams routinely swap RRTConnect for CHOMP hoping to fix vibration, when the real problem is IterativeParabolicTimeParameterization commanding infinite jerk at every waypoint.

---

The Three Algorithm Families

Every trajectory planner you'll encounter — in MoveIt2, in proprietary industrial stacks, in research papers — belongs to one of three families: sampling-based, optimization-based, or analytic interpolation. Choosing wrongly doesn't cost milliseconds. It costs deployment cycles.

Criterion	Sampling-Based (RRT, RRT*, PRM, RRTConnect)	Optimization-Based (CHOMP, STOMP, TrajOpt)	Analytic / Interpolation (cubic, quintic, S-curve)
Typical planning time	0.5–3 s on 7-DOF	100s of ms to several s	<10 ms
DOF scalability	Excellent — probabilistically complete	Good, degrades in clutter	Limited — needs collision-free path
Output smoothness	Poor — requires post-smoothing	High — explicit jerk cost terms	High — closed-form C¹ or C²
Handles obstacles natively	Yes	Yes, via cost functions	No
Sensitivity to initialization	Low	High — local minima common	None
Real-time replanning	Marginal	Rarely	Yes
Compute budget	Jetson Orin Nano (40 TOPS, 7–15 W)	T4000/T5000 or workstation	Microcontroller-class
Best fit	Cluttered manipulation, novel geometries	Repetitive precision tasks	Mobile robots, real-time sync

Sampling-based planners are the MoveIt2 default through OMPL. They are probabilistically complete — they will find a path if one exists, given enough samples — but LaValle is explicit in Planning Algorithms: "Sampling-based planners are typically aimed at finding feasible paths; they do not in general attempt to optimize any criterion such as path length or smoothness." This is why RRTConnect's output is always post-processed by a time-parameterization stage — typically MoveIt's IterativeParabolicTimeParameterization — before execution. Skip that post-processing and the trajectory is unusable on real hardware.

Optimization-based planners reverse the trade-off. CHOMP, STOMP, and TrajOpt produce smooth, near-time-optimal trajectories by minimizing a cost functional with constraints. But Ratliff et al.'s original CHOMP paper documents that the method "can get trapped in local minima and is sensitive to initial trajectories" in cluttered scenes. Practical mitigation: warm-start the optimizer with a sampling-based seed. This is the hybrid that ships in modern MoveIt2 pipelines and is almost always the right configuration in production.

Analytic methods — cubic polynomials (C¹ continuity), quintic polynomials (C² continuity), trapezoidal velocity profiles, and jerk-limited S-curves — are the workhorse of industrial controllers. They're real-time, deterministic, and require no iterative solver. Della Santina et al.'s survey reports that on-line polynomial interpolation can meet cycle times below 100 ms on 6-axis arms. Their hard limitation: they assume the path is already collision-free. They cannot avoid obstacles; they only smooth motion between known waypoints.

Sampling-based planners find a path; analytic profiles make it executable; optimization makes it elegant — production stacks use all three, layered.

The pragmatic production stack: sampling-based planner generates the path → analytic time-parameterization (typically S-curve) produces the trajectory → joint controller tracks it. Optimization replaces the middle stage only when smoothness or dynamics matter more than planning latency.

---

Integrating Trajectory Planning into ROS2 and MoveIt2

MoveIt2 is the de facto open-source motion planning framework for ROS2 manipulators. The six integration steps below determine whether your planner works in two hours or fails for two weeks.

1. Author your URDF and SRDF correctly.

The URDF must include accurate joint limits via <limit lower upper effort velocity> tags — MoveIt2 reads these directly for time-parameterization. Pull velocity and acceleration values from the vendor datasheet (UR5e, KUKA KR Agilus). The SRDF defines planning groups, end-effector links, and disabled self-collision pairs. The most common failure: missing self-collision exclusions cause 5–10× slower planning because OMPL spends most of its samples rejecting impossible self-intersections. Verify with check_urdf and visualize collision geometry in RViz before you ever call move_group.

2. Choose your OMPL planner deliberately.

RRTConnect is the default and the fastest for typical 6–7 DOF pick-and-place — median 0.5–3 s per the MoveIt benchmark. PRM* is better for repetitive queries in the same workspace because you precompute the roadmap once and reuse it. For smooth output, layer CHOMP or STOMP as a post-processor on the sampled path, not as a replacement for sampling. Replacing sampling with pure optimization in cluttered scenes is how teams discover local-minima failures in production.

3. Configure collision checking resolution.

MoveIt2's longest_valid_segment_fraction (default 0.05) trades safety for speed. Setting it to 0.01 roughly doubles planning time but catches thin-obstacle collisions that 0.05 misses. Tune per workspace clutter density. Use convex decomposition (V-HACD) for collision meshes — not raw visual meshes, which can carry 10,000+ triangles and slow collision checks by roughly 50×. This single change accounts for more "MoveIt2 is slow" complaints than any other configuration mistake.

4. Pick a time-parameterization algorithm.

IterativeParabolicTimeParameterization is the default — trapezoidal, fast, but can violate acceleration limits at waypoints with sharp angles. TimeOptimalTrajectoryGeneration (TOTG) respects both velocity and acceleration limits strictly and is the right default for production. RuckigSmoothing produces jerk-limited S-curves with the lowest mechanical wear and vibration; use it for any cobot subject to ISO/TS 15066 force limits.

5. Validate in simulation before deployment.

Gazebo or Ignition give you full physics but slow iteration. PyBullet is lighter and better for batch testing. Cloud simulation pipelines that capture workspace geometry from LiDAR scans into simulation directly — the real-to-sim approach used by platforms like OpenKinematics — narrow the sim-to-real gap that breaks naive plans. Log planning time, trajectory duration, max joint velocity, max joint acceleration, and max jerk for every test run.

6. Deploy and instrument.

Stream planned vs. actual joint positions over /joint_states and /joint_trajectory_controller/state. Compute tracking error (RMS) per joint. NIST IR 8267 recommends measuring both planned and actual motion times because controller cycle times add tens of milliseconds of latency that simulation does not show. The instrumentation work feels redundant until the first protective stop you cannot explain.

---

Real-World Constraints That Break Naive Plans

A trajectory that passes simulation can fail on hardware within the first five executions. The failures cluster into four categories — and each maps to a specific URDF, controller, or environment fix.

Actuator and dynamic constraints

• Joint velocity and acceleration limits in your URDF are often vendor catalog maximums — achievable only at zero payload. Adding a 3 kg gripper plus payload can reduce safe acceleration by roughly 40–60% on a UR5e-class arm. Re-derive limits from the manufacturer's payload chart and rewrite the URDF before planning.
• Russ Tedrake's caution from Underactuated Robotics applies directly: "If your actuators can't realize the commanded torques or your friction model is wrong, the 'optimal' solution can fail dramatically on hardware."
• Trapezoidal profiles command instant acceleration changes — the resulting infinite jerk excites mechanical resonance modes. Switch to S-curve (Ruckig or quintic) for any payload above 1 kg.

Environmental uncertainty and sensor latency

• MoveIt2's planning scene is a snapshot. If your perception pipeline updates the scene every 200 ms but a human reaches in at 1 m/s, the planner sees a 20 cm stale obstacle position.
• NIST IR 8267 documents that planning algorithms commonly "assume perfect knowledge of the environment and robot state" — an assumption that fails in any production factory. This is also where mobile robot trajectory planning diverges most sharply from manipulator planning: the base motion itself invalidates the scene.
• Static collision maps decay. Chip trays move, debris accumulates, fixtures shift. Re-scan the workspace daily, or use a real-to-sim LiDAR pipeline to refresh the planning scene without manual remodeling.

A trajectory that works in simulation and fails on hardware is not a planning bug — it is a constraint that lived only in your real workspace and never made it into the URDF.

Hardware compliance and kinematic drift

• Cable-driven arms (Kinova, some collaborative designs) exhibit 1–3 mm tip compliance under load — invisible to the URDF kinematic model. Trajectories planned to ±0.05 mm path repeatability (ISO 9283 spec for rigid industrial arms) will not achieve that on a compliant platform.
• Calibration drift: thermal expansion shifts joint zeros by 0.1–0.3° over a shift. Trajectories that clear obstacles by 5 mm in CAD may scrape them after four hours of continuous operation.
• The fix is not a better planner; it is closed-loop perception that recomputes the collision scene between cycles.

Safety standard coupling for collaborative robots

• ISO/TS 15066 defines maximum allowed contact forces — as low as 65 N for sensitive body regions per the Pilz application guide.
• For a cobot in power-and-force-limited mode, your trajectory planner must cap end-effector speed (typically 250 mm/s in shared workspace) and deceleration profile, not just joint speeds. ISO 10218-1/2 requires the trajectory layer to enforce stop categories at planning time, not delegate to runtime monitoring.
• Collision avoidance trajectory planning in shared workspaces is therefore not just geometric — it is force-limited from the planner outward.

---

Pre-Trained Skills vs. Custom Trajectory Planning

Classical trajectory planning is one path to deployment. A second path — learned skill policies built on reinforcement learning or imitation learning — sidesteps the planner entirely by mapping perception directly to joint commands. The choice between them is rarely binary, and the hybrid is where most production deployments converge.

Factor	Custom Trajectory Planning (MoveIt2 + OMPL)	Pre-Trained Skill Policy	Hybrid (Policy + Planner)
Time to first working skill	4–12 weeks	<60 min on managed platforms	1–3 weeks
Generalization to novel objects	High — replans for any geometry	Low — bound to training distribution	Medium
Sim-to-real robustness	High — geometric reasoning	Fragile without domain randomization	Improved
Real-time replanning latency	100s of ms to seconds	<50 ms policy inference	Mixed
Compute requirement	Jetson Orin Nano for 6–7 DOF	Jetson Orin Nano (40 TOPS)	Orin Nano to T4000
Team expertise required	Motion planning + ROS2	Platform operation (no ML PhD)	Both, lighter on each
Best fit	Variable workspaces, R&D	Repetitive in-distribution tasks	Production with task variability

The custom planning path remains the right answer for tasks where geometry varies between every execution — kitting with mixed SKUs, machine tending across multiple fixture types, mobile manipulation in unstructured spaces. The MoveIt2 + OMPL + TOTG stack will, with 4–12 weeks of integration, handle these tasks indefinitely without retraining. The cost is the integration timeline itself, which competes directly with the customer's patience.

Pre-trained skill policies — the category platforms like Covariant, Physical Intelligence, Skild, and OpenKinematics operate in — collapse that timeline to under 60 minutes for tasks inside the training distribution. The trade-off is the distribution boundary. Andrychowicz et al. document that policies trained in simulation are "fragile to small changes in dynamics" without aggressive domain randomization or real-data fine-tuning. A policy trained on cardboard boxes of 10–30 cm fails on a 5 cm pill bottle. The policy doesn't know it has crossed the boundary; it just produces a confidently wrong action.

The emergent production pattern is hybrid. A learned policy handles the perception-rich, contact-rich phases — grasp selection, compliant insertion, surface following — where classical planning struggles with the underlying contact dynamics. A classical trajectory planner handles free-space motion between those phases, where geometric reasoning beats learned generalization. Real-to-sim LiDAR scanning feeds both the policy's environment model and the classical planner's collision scene from the same workspace capture, eliminating the duplicate-modeling work that historically killed hybrid timelines.

The decision heuristic by audience segment:

• Robotics startups and integrators on tight timelines: Start with pre-trained skills for the 80% of tasks they cover; budget for hybrid as the customer base diversifies.
• Enterprise fleet operators (warehouse, assembly, logistics): Hybrid from day one — pre-trained for high-volume SKUs, classical trajectory planning manipulator stacks for the long tail.
• Academic and R&D teams: Custom planning; the generalization is the research contribution.
• Hardware-agnostic teams working with Unitree, Franka, or Universal Robots: Pre-trained skills shorten cross-platform deployment because the policy abstracts the kinematics.

---

Benchmarking Your Trajectory Planner

Teams deploy trajectory planners and measure only one number: did it work in the demo? Production reliability requires four metric categories — planning quality, execution fidelity, throughput, and failure mode distribution. ISO 9283 and NIST IR 8267 define the canonical set.

Planning quality metrics (measured in simulation, before hardware).

• Success rate: percentage of planning queries that return a valid trajectory within the timeout. The MoveIt benchmark on PR2 reports 96–100% for typical scenarios. Below 90% means your collision geometry is over-conservative, your timeout is too tight, or your goal sampling is broken.
• Median planning time: the Chitta benchmark cites 0.5–3 s. If yours exceeds 5 s on 6–7 DOF, you're likely using raw visual meshes for collision checks instead of V-HACD convex decompositions.
• Trajectory smoothness: integrated jerk magnitude over the trajectory. Lower is better; quintic and S-curve parameterizations typically cut this 3–5× over trapezoidal in our experience tuning industrial cells.
• Path length efficiency: trajectory length divided by straight-line joint distance. Above 1.5 suggests the planner is taking unnecessary detours — usually fixed by post-processing with a shortcut smoother.

Execution fidelity metrics (measured on hardware).

• Tracking error (RMS per joint): rigid industrial arms achieve ±0.05 mm path repeatability per ISO 9283 specs and the ABB IRB 2600 datasheet. Your real tracking error reveals controller tuning quality, not planner quality.
• Planned vs. actual execution time: NIST IR 8267 explicitly recommends logging both. A 10–20% slowdown is normal due to controller latency; 50%+ means the planner is commanding accelerations the actuators cannot deliver.
• Protective-stop frequency: the production analog of "did the planner respect dynamic limits?" Above 1 per 1,000 cycles indicates planning constraints disagree with the real robot.
• Collision incidents: binary, but track near-misses via tracking error spikes.

Throughput and failure-mode metrics (production).

• Cycle time decomposition: what fraction of cycle time is planning, what fraction is execution, what fraction is sensing and decision? Della Santina et al. note polynomial interpolation can hit sub-100 ms cycles on 6-axis arms — if yours is 500 ms, planning is the bottleneck and analytic methods may be the trajectory optimization fix.
• Failure mode histogram: classify every protective stop or task failure as planning, execution, perception, or upstream. Most teams discover perception, not planning, is the dominant failure source — and continue tuning the wrong layer for months.

Pre-deployment benchmarking checklist:

1. Run 100 planning queries in simulation with representative goal poses; record success rate and median planning time. Target: ≥95% success, ≤3 s median.
2. Execute 50 trajectories on real hardware logging planned vs. actual joint trajectories at 100 Hz. Compute per-joint RMS tracking error.
3. Decompose cycle time into planning, execution, and idle phases for 20 cycles. Identify the dominant cost.
4. Run an 8-hour stress test with continuous operation; verify protective-stop frequency stays below 1 per 1,000 cycles.
5. Validate against ISO 9283 test trajectories (100 mm linear, 360° circular) if your application requires certified path accuracy.
6. Document the failure mode histogram for one full shift; do not assume planning is the bottleneck until the data says so.

---

FAQ

Q1: Should I use MoveIt2 or write a custom trajectory planner?

Use MoveIt2 unless you have a constraint it does not support — non-holonomic mobile bases with full dynamics, contact-rich manipulation requiring force trajectories, or sub-10 ms replanning loops. Writing a custom planner is typically 6–12 months of work versus 2–8 weeks of MoveIt2 integration, and you inherit OMPL's 14+ planner implementations for free. The 95% case: configure MoveIt2 well rather than rebuild it. ROS motion planning has converged on this stack for a reason.

Q2: My trajectory works in Gazebo but fails on real hardware. What's wrong?

Three causes account for roughly 90% of sim-to-real failures: (1) URDF joint limits are vendor catalog values, not payload-adjusted real limits — fix by re-deriving from the payload chart on the UR datasheet or equivalent; (2) collision meshes are visual meshes, not convex decompositions — fix with V-HACD; (3) controller cycle latency (tens of milliseconds per NIST IR 8267) makes commanded accelerations unreachable — fix with jerk-limited S-curve parameterization or lower acceleration scaling.

Q3: How does trajectory planning differ for mobile manipulators (arm on a wheeled base)?

Treat the base plus arm as a single high-DOF system in configuration space — 9–10 DOF for a holonomic base plus 6-DOF arm. Use sampling-based planners (RRT*) because the search space is too high-dimensional for raw optimization. Real-time replanning is essential — base motion creates new obstacles relative to the arm. For non-holonomic bases (differential drive, Ackermann), use kinodynamic RRT variants that respect the base's motion constraints; see LaValle Ch. 14. Mobile robot trajectory planning is fundamentally a coupled problem, not two planners running in series.

Q4: Can I skip trajectory planning entirely with a pre-trained policy?

Yes, if the task is inside the policy's training distribution. Andrychowicz et al. document that policies are "fragile to small changes in dynamics" outside training. For repetitive tasks with known SKUs, pre-trained skills deploy in under an hour versus 4–12 weeks for custom planning. For variable geometry, hybrid — policy for nominal phases, planner for novel ones — is the durable answer.

Q5: What compute does real-time trajectory planning need?

For 6–7 DOF sampling-based planning at MoveIt2 benchmark speeds (median 0.5–3 s), an NVIDIA Jetson Orin Nano delivering 40 TOPS in a 7–15 W envelope is sufficient. Optimization-based planners (CHOMP/STOMP/TrajOpt) on the same DOF often need Jetson AGX Orin or T4000-class compute. Analytic interpolation runs on microcontroller-class hardware in microseconds. Measure on your target hardware — desktop benchmarks overstate edge-device performance by roughly 3–10×.

---

Pre-Deployment Validation Checklist

The work below is what separates a trajectory planner that demos well from one that runs unattended for an 8-hour shift. Complete this list before declaring any trajectory planning robotics stack production-ready.

1. Reconcile URDF with real hardware. Measure joint limits, end-stop positions, and payload-adjusted velocity and acceleration ceilings against the vendor datasheet. The common gap: catalog max velocity assumes zero payload, and your gripper plus part is never zero.
2. Decompose collision meshes. Replace visual meshes with V-HACD convex decompositions. Verify collision-checking runs at least roughly 10× faster than with raw meshes by timing 1,000 state validations before and after.
3. Select time-parameterization deliberately. Use TimeOptimalTrajectoryGeneration or RuckigSmoothing instead of the default IterativeParabolic for any deployment subject to ISO/TS 15066 force limits. The default is fine for demos and dangerous for cobots.
4. Benchmark in simulation. Run 100 planning queries; record success rate (target ≥95%) and median planning time (target ≤3 s).
5. Run 50 hardware trajectories. Log planned vs. actual joint positions at 100 Hz. Compute per-joint RMS tracking error. Compare against ISO 9283 path repeatability spec for your robot class.
6. Decompose cycle time. Identify whether planning, execution, or perception dominates. If planning exceeds 20% of cycle, evaluate analytic interpolation or optimization replacement for that segment.
7. Decide custom vs. pre-trained vs. hybrid. Apply the heuristic from the deployment-decision section: pre-trained skills for repetitive in-distribution tasks (under 60 minutes to deploy), custom planning for novel geometry, hybrid for production with a long task tail.
8. Document the constraints that changed your planner choice. Catalog every constraint that lived in real hardware but not in the URDF or simulation. This document is the foundation of your next robot deployment — and the asset that compounds across a fleet.