A narrow-passage motion planning task — dock a mobile base at a target panel, then thread the arm's end effector through a hole in that panel to a pose on the far side — used as a head-to-head test of PRM, RRT, and RRT*.
Screenshot — mobile manipulator docked at the panelPaste an image here
01Tech Stack
A ROS2-native stand-in for the KUKA youBot, with the same architecture: an independent mobile base and arm, planned through MoveIt2.
OS
Ubuntu 24.04
Host platform
ROS Distribution
ROS2 Jazzy Jalisco
Latest, not yet LTS-mature
Simulator
Gazebo
Base, arm, and panel in one scene
Robot Platform
TurtleBot3 Waffle + OpenMANIPULATOR-X
Mobile base + independently-actuated arm
Motion Planning
MoveIt2 (OMPL plugin)
PRM, RRT, RRT* via one-line config swap
Navigation
Nav2
Docks the base in front of the panel
02Five-Session Implementation Plan
Each session is capped at two to three hours, ending with a head-to-head comparison rather than a single working demo.
Session 1
Combined Base + Arm Setup
Assemble the TurtleBot3 Waffle base and OpenMANIPULATOR-X arm into a single robot description, spawn it in Gazebo, and verify joint control plus MoveIt2 integration.
Session 2
Panel Geometry & Docking
Model the target panel and its hole as a collision object in the planning scene; use Nav2 to dock the base at a fixed pose in front of it.
Screenshot — panel with hole in the planning scenePaste an image here
Session 3
First End-to-End Reach
Prove out one planner guiding the end effector through the hole to a pose on the far side — the point at which the panel's collision geometry gets validated for real.
Load-bearing milestone
Screenshot — end effector threading the holePaste an image here
Session 4
Head-to-Head Planner Runs
Run PRM, RRT, and RRT* multiple times each through the same hole, recording planning time, success rate, and path quality for every trial.
Core project milestone
Screenshot — RRT* path through the panelPaste an image here
Session 5
Analysis & Write-Up
Compare the three planners' actual measured behavior against what the theory predicts, and write up the results.
Everything downstream depends on the panel being modeled correctly in the planning scene. Get it wrong, and the planner either can't find a path that exists, or finds one that shouldn't.
Fails
Panel ignored
The planner treats the space where the panel sits as free — paths are found, but they'd collide with the physical panel.
Fails
Hole modeled as solid
The panel is a solid collision block with no opening — every planner reports no valid path exists, even though one does.
Succeeds
Hole modeled correctly
The panel is solid except for a free-space opening sized to the end effector — the narrow-passage problem the planners are actually meant to solve.
04Head-to-Head: PRM vs RRT vs RRT*
All three run through MoveIt2's OMPL plugin, so switching planners is a one-line configuration change — which is what makes a clean, controlled comparison possible.
PRM
RRT
RRT*
Approach
Builds a roadmap over the whole free space up front, then searches it for a path.
Grows a single tree outward from the start, biased toward the goal.
Grows a tree like RRT, but continually rewires it toward lower-cost paths.
Narrow-passage behavior
Tends to struggle — random sampling rarely places roadmap nodes inside a small opening.
Generally better — a directed, single-query search is more likely to find the one opening.
Same passage-finding behavior as RRT, plus ongoing refinement once a path is found.
Optimality
None — first valid roadmap path returned.
None — first valid path returned, not necessarily short.
Asymptotically optimal — path quality improves the longer it's given to plan.
Expected trade-off
Fast to reuse across queries, weak on this specific task.
Fast first success, no guarantee on path quality.
Best path quality, at the cost of planning time.
Recorded per trial: planning time · success rate · path quality
05Standing In for the KUKA youBot
The project is conceptually modeled on the youBot's mobile-base-plus-arm architecture, but built on hardware with active ROS2 support.
No actively maintained ROS2 package for youBot
The original KUKA youBot driver stack targets ROS1 and isn't kept current for ROS2, ruling it out as the simulated platform.
TurtleBot3 Waffle + OpenMANIPULATOR-X as the substitute
Same architecture — an independently-actuated arm mounted on a mobile differential-drive base — with first-class ROS2 and MoveIt2 support.
Architecture matters more than the exact hardware
The planning problem (base navigation, then constrained arm reach) is what's being tested, not the specific robot — any ROS2-native mobile manipulator would surface the same narrow-passage behavior.
06Future Work — Extending the Project
Natural directions once the base comparison and write-up are done.
Constrained planning (CBIRRT / TrajOpt)
Add a fourth planner family that handles the narrow passage via explicit constraints rather than pure sampling, and compare it against the sampling-based trio.
Base + arm joint planning
Plan base and arm motion together instead of docking first, letting small base adjustments open up easier reach geometry.
Variable hole sizes and offsets
Sweep the hole's size and position to find where each planner's success rate actually breaks down, rather than testing a single fixed geometry.
Sim-to-real transfer
Rebuild the panel physically and repeat the comparison on real TurtleBot3 + OpenMANIPULATOR-X hardware.
Vision-based hole localization
Replace the fixed, known panel pose with a camera-based detector so the base docks relative to a hole it has to find first.
Learned planner warm-starts
Train a model on the recorded trials to propose an initial path for RRT* to refine, and measure whether it shortens planning time.
Takeaway: a narrow passage is a stress test, not a corner case — it's the cleanest way to see the actual difference between roadmap-based, tree-based, and optimization-based planning instead of just reading about it.