RRT* vs. Convex Optimization: Choosing the Right ROS 2 Motion Planner
RRT* vs. Convex Optimization: Architectural Guide for ROS 2 Motion Planning
When moving a software-defined hardware system from a static mapping state to active navigation, you run headfirst into the core challenge of robotics: Motion Planning.
In our previous deep dives, we explored how to build a native
Should you deploy a Sampling-Based Planner (like RRT) or an Optimization-Based Planner (like Polyhedral/JuMP)?*
Choosing incorrectly leads to computational bottlenecks, erratic trajectories, or worst of all, kinematic instability on the physical robot. This guide provides an explicit breakdown of when to sample and when to optimize.
1. Core Architectural Differences
The fundamental divergence between these two paradigms lies in how they navigate your robot's Configuration Space (C-Space).
Sampling-Based Planners (RRT*, PRM*)
Sampling-based algorithms don't try to solve the entire mathematical geometry of the environment. Instead, they randomly poke the C-Space with coordinate samples, connect the dots where paths are collision-free, and continuously "rewire" the connections to asymptotically approach the shortest path.
Optimization-Based Planners (Polyhedral Space / JuMP / TrajOpt)
Optimization algorithms treat a trajectory as a continuous mathematical function. They wrap the robot's physical constraints (maximum velocity, torque limits, actuator acceleration profiles) and obstacle boundaries (polyhedral half-spaces) into a cost function, minimizing parameters like arrival time, control effort, or jerk.
2. Direct Technical Comparison
To determine which planner fits your specific ROS 2 node, we must evaluate them across four engineering metrics:
| Engineering Metric | Sampling-Based (RRT*) | Optimization-Based (JuMP / Convex) |
| Completeness | Probabilistically Complete: If a path exists, it will eventually find it given infinite time. | Locally Optimal: Can fail or get stuck in local minima if initialization is outside the convex field. |
| Kinematic Constraints | Difficult to natively enforce smooth velocity or joint acceleration curves without complex steering functions. | Exceptional. Enforces strict differential boundaries directly in the solver. |
| Computation Scalability | Scales well into high dimensions (e.g., 7-DOF manipulation arms). | Computation scales quadratically with the number of obstacle constraints ($O(N^2)$). |
| Trajectory Geometry | Often jagged and requiring a secondary "smoother" node. | Perfectly smooth, continuous, and immediately executable by hardware motor drivers. |
3. When to Choose a Sampling-Based Planner (RRT*)
Scenario A: High-Dimensional Manipulation (Manipulator Arms)
If you are planning motions for a 6-DOF or 7-DOF robotic arm (like the Franka Emika Panda), optimization-based planners struggle with the complex, non-linear trigonometric configurations of the joints. RRT* sweeps through high-dimensional joint spaces efficiently because it checks for collisions via forward kinematics rather than trying to invert a massive matrix of symbolic derivatives.
Scenario B: Maze-like or Unstructured Environments
If your AMR is navigating a chaotic, non-convex environment—like an organic farm field or a warehouse cluttered with jagged, randomly piled pallets—modeling these shapes as clean linear equations is impossible. RRT* does not care about the mathematical shape of the obstacle; it only needs a binary true/false return from a collision checking engine (like FCL or OctomAP).
4. When to Choose an Optimization Planner (Polyhedral / JuMP)
Scenario A: High-Speed AMRs and Drones
When an aerial drone or a high-speed warehouse robot changes direction abruptly due to a jagged RRT* waypoint, the physical momentum can cause the system to tilt, lose traction, or draw excessive current from the batteries. Optimization planners allow you to minimize Jerk (the derivative of acceleration), guaranteeing a trajectory that respects physical limits.
Scenario B: Provably Safe Autonomous Driving
In autonomous driving scenarios, lanes, guardrails, and forward vehicles can be mathematically represented as a moving corridor of convex bounding boxes. By enforcing these boundaries using polyhedral constraints, your optimizer provides a mathematical proof of safety—the car physically cannot select a trajectory that violates the half-space constraints.
5. The Hybrid Era: The Best of Both Worlds
In 2026, the industry standard for advanced ROS 2 setups is no longer purely one or the other. Instead, systems use a Hybrid Architecture:
The Global Planner (Sampling): Uses a fast sampling-based method (or a coarse grid search) to find a rough path through a complex environment, effectively identifying which hallway or corridor to take.
The Local Planner (Optimization): Takes that jagged sequence of waypoints, inflates a convex polyhedral "safe tube" around it, and uses a quadratic optimization solver (like Model Predictive Control) to generate the final, buttery-smooth control commands.
Conclusion: Matching Algorithm to Silicon
Choosing your motion planner dictates your edge computing hardware requirements. If your ROS 2 stack relies on RRT*, you need high single-core CPU speeds to iterate through distance checking loops quickly. If you are deploying JuMP-based convex optimizers, you need hardware with dedicated vector math extensions or highly integrated coprocessors.
Summary Selection Matrix for AppliedKaos Engineers
Is your environment highly structured (lanes/boxes)?
/ \
(Yes) (No)
/ \
Are kinematic limits critical? Use Sampling (RRT*)
/ \
(Yes) (No)
/ \
Use Optimization (JuMP) Either works fine
Comments
Post a Comment