<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sampling-Based Planning | Henry Kou</title><link>https://kenryhou2.github.io/tags/sampling-based-planning/</link><atom:link href="https://kenryhou2.github.io/tags/sampling-based-planning/index.xml" rel="self" type="application/rss+xml"/><description>Sampling-Based Planning</description><generator>HugoBlox Kit (https://hugoblox.com)</generator><language>en-us</language><lastBuildDate>Wed, 06 May 2026 00:00:00 +0000</lastBuildDate><image><url>https://kenryhou2.github.io/media/icon_hu_da05098ef60dc2e7.png</url><title>Sampling-Based Planning</title><link>https://kenryhou2.github.io/tags/sampling-based-planning/</link></image><item><title>Sampling Based Planners</title><link>https://kenryhou2.github.io/projects/sampling-based-planners/</link><pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/sampling-based-planners/</guid><description>&lt;p&gt;
&lt;figure &gt;
&lt;div class="flex justify-center "&gt;
&lt;div class="w-full" &gt;&lt;img alt="RRT* planner moving a planar robot arm through an obstacle map"
src="https://kenryhou2.github.io/projects/sampling-based-planners/demo.gif"
loading="lazy" data-zoomable /&gt;&lt;/div&gt;
&lt;/div&gt;&lt;/figure&gt;
&lt;/p&gt;
&lt;p&gt;I used this project to compare how different sampling-based planners behave on the same high-DOF arm problem. The planner executable receives an occupancy-grid map, the arm DOF count, comma-separated start and goal joint angles, a planner ID, and an output path, then returns a collision-free sequence of joint configurations for a planar arm with fixed 10-cell links.&lt;/p&gt;
&lt;p&gt;The important idea is that planning happens in configuration space even though collision is checked in workspace. For each candidate joint vector, I rasterize every link with Bresenham line traversal, reject poses that hit nonzero map cells, sample joint angles in &lt;code&gt;[0, 2*pi)&lt;/code&gt;, and score path quality as cumulative wrap-around L1 joint motion.&lt;/p&gt;
&lt;p&gt;The planner modes show the tradeoff nicely. Single-tree RRT is simple and usually finds something. RRT-Connect grows start and goal trees toward shared samples and is much faster for single-query planning. RRT* adds local rewiring, which can lower cost but spends more time improving the tree. PRM pays an upfront roadmap cost, then uses Dijkstra search over collision-checked graph edges.&lt;/p&gt;
&lt;p&gt;In my report, I compare fixed start/goal pairs over 3-, 4-, and 5-DOF settings on &lt;code&gt;map2.txt&lt;/code&gt;. RRT-Connect was the fastest and most reliable single-query planner overall, RRT* reduced path cost through rewiring at higher runtime, and PRM produced strong global path quality but paid a larger roadmap construction cost.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Kavraki et al. on probabilistic roadmaps; LaValle&amp;rsquo;s original RRT work; Kuffner and LaValle&amp;rsquo;s RRT-Connect paper; and Karaman and Frazzoli&amp;rsquo;s RRT* optimality result.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Technical stack:&lt;/strong&gt; C++, CMake, Python, Matplotlib, Pillow, occupancy-grid maps, CSV evaluation outputs.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; sampling-based motion planning, high-DOF arm planning, planar robot arm, configuration space, collision checking, Bresenham rasterization, occupancy grid, RRT, RRT-Connect, RRT*, PRM, roadmap planning, Dijkstra search, goal bias, nearest-neighbor search, rewiring, path quality, wrap-around joint cost, C++, CMake, Python visualization.&lt;/p&gt;</description></item></channel></rss>