CHOMP and STOMP

CHOMP (Covariant Hamiltonian Optimization for Motion Planning) and STOMP (Stochastic Trajectory Optimization for Motion Planning) are two algorithms in the same family: take a (possibly bad) initial trajectory, deform it iteratively to minimize a cost. CHOMP uses analytical gradients; STOMP uses sample-based ones. Both ship in MoveIt; both are practical alternatives to OMPL's sampling planners for arm motion.

The framework

Represent a trajectory as a sequence of N waypoints in C-space: \xi = (q_1, q_2, ..., q_N). Define a cost:

U(ξ) = U_obstacle(ξ) + λ · U_smooth(ξ)

where U_{\text{obstacle}} sums obstacle costs along the trajectory and U_{\text{smooth}} sums squared accelerations. Minimize U starting from an initial trajectory.

The two algorithms differ in how they take the gradient.

CHOMP: analytical gradient descent

Compute the gradient of U with respect to each waypoint analytically. Update each waypoint via covariant gradient descent (a Riemannian optimization that respects the smoothness metric).

ξ_{k+1} = ξ_k - η · M⁻¹ ∇U(ξ_k)

M is a positive-definite matrix (typically K^T K where K is a finite-difference matrix). Multiplying by M^{-1} ensures updates stay smooth.

The obstacle gradient comes from a signed distance field of the workspace. At each waypoint, look up the workspace distance to obstacles; gradient pushes the trajectory away.

Strengths: deterministic; smooth output; differentiable cost makes it amenable to plugging into larger optimization pipelines.

Weaknesses: needs differentiable cost (signed distance field requires care); local minima; gets stuck behind obstacles.

STOMP: stochastic gradient descent

Same cost function, different gradient estimator. At each iteration:

1. Generate K random perturbations \delta \xi_1, ..., \delta \xi_K.
2. Evaluate the cost of each perturbed trajectory \xi + \delta \xi_i.
3. Compute weighted average using the perturbation costs as weights.
4. Update the trajectory toward the lower-cost perturbations.

The "stochastic" part: gradient is estimated from samples, not computed analytically.

Strengths: handles non-differentiable costs (collision is a binary check, no gradient needed); fewer assumptions; simpler implementation.

Weaknesses: stochastic; runs slower than CHOMP for the same number of iterations; quality of gradient depends on perturbation noise level.

The two-step pattern

Most production setups combine:

1. Initial planner (RRT-Connect, BiTRRT, or even straight-line) generates a possibly-bad path.
2. Trajectory optimizer (CHOMP or STOMP) refines it into a smooth, low-cost trajectory.

This is the OMPL → CHOMP/STOMP pipeline that MoveIt ships out of the box.

The signed distance field (SDF)

Both CHOMP and STOMP need a way to compute "how far is this configuration from collision?" The standard answer: a precomputed signed distance field over the workspace.

• 3D voxel grid; each voxel stores distance to nearest obstacle (positive outside, negative inside).
• For each robot link, sample a few collision spheres; query SDF at each.
• Total cost = sum over spheres of penalty for negative distances.

SDF construction takes ~100 ms for a 1m³ workspace at 1 cm resolution. Recompute when the scene changes.

When to pick which

Scenario	Choice
Smooth differentiable cost	CHOMP — faster convergence
Discrete/black-box cost	STOMP — handles anything
Local optimum problems	STOMP — stochasticity escapes
Real-time control loops	CHOMP — predictable runtime

The 2026 alternatives

CHOMP and STOMP are still in MoveIt; both still useful. But newer methods cover similar ground:

• TrajOpt (Sequential Convex Optimization): Schulman et al.'s approach. Linearize obstacle penalties; solve convex sub-problems; iterate. Often faster than CHOMP/STOMP.
• iLQR / DDP: differential dynamic programming. Fast for low-dimensional systems; widely used in legged-robot trajectory optimization.
• cuRobo: NVIDIA's GPU-accelerated trajectory optimizer. Drop-in replacement for MoveIt's planning pipeline; 10–100× faster on hard scenes.
• Diffusion-based planners: Janner et al.'s diffusion policy generates trajectories as denoising. Recent research; not yet production.

For new projects in 2026, consider cuRobo first if you have NVIDIA hardware; CHOMP/STOMP if you're CPU-bound and need MoveIt-compatible.

Common gotchas

• Bad initial trajectory: both algorithms get stuck in local minima. Initialize from a sampling-based planner.
• Wrong SDF resolution: too coarse misses thin obstacles; too fine eats memory. 1–2 cm is the practical sweet spot for arms.
• Smoothness/obstacle weighting: tune \lambda. Too high → snake through obstacles; too low → smooth but invasive.
• STOMP perturbation magnitude: too small → no exploration; too big → noisy gradient. Tune to scene scale.

Exercise

In MoveIt 2 with the Panda arm, plan a path between two configurations using OMPL (the default). Then re-plan using CHOMP. Compare path smoothness and execution time. CHOMP is dramatically smoother — and that smoothness shows up in the real arm's vibration and tracking accuracy.

Next

MPC as a motion planner — when the line between control and planning blurs.