<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>C++ | Henry Kou</title><link>https://kenryhou2.github.io/tags/c++/</link><atom:link href="https://kenryhou2.github.io/tags/c++/index.xml" rel="self" type="application/rss+xml"/><description>C++</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>C++</title><link>https://kenryhou2.github.io/tags/c++/</link></image><item><title>A* Pursuit of Dynamic Target</title><link>https://kenryhou2.github.io/projects/a-star-dynamic-target/</link><pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/a-star-dynamic-target/</guid><description>&lt;p&gt;I built this planner to answer a simple pursuit question: if the target is moving on a cost map and I know its future trajectory, where should the robot move next? Instead of planning only in &lt;code&gt;(x, y)&lt;/code&gt;, I lift the search into &lt;code&gt;(x, y, t)&lt;/code&gt; so an interception is defined as both agents occupying the same cell at the same time.&lt;/p&gt;
&lt;p&gt;The core method is weighted A* over 8-connected grid motion plus a wait action. The edge cost comes from the destination cell, cells above the collision threshold are treated as blocked, and the planner returns only the first action from the best path. That receding-horizon structure matters because the useful plan changes as the target advances.&lt;/p&gt;
&lt;p&gt;The interesting engineering detail is the heuristic. I cache a multi-source Dijkstra table from feasible near-future target cells, then combine that with a static meet-point estimate chosen by travel cost plus wait time. The implementation also exposes &lt;code&gt;eps&lt;/code&gt;, &lt;code&gt;time_budget_ms&lt;/code&gt;, and &lt;code&gt;heu_band&lt;/code&gt; so I can trade optimality against response time, and it uses deterministic priority-queue tie breaking on &lt;code&gt;f&lt;/code&gt;, &lt;code&gt;h&lt;/code&gt;, &lt;code&gt;g&lt;/code&gt;, and packed state keys. The repo includes map files, recorded robot trajectories such as &lt;code&gt;rtraj_map*.txt&lt;/code&gt;, and a Matplotlib visualizer for replaying the pursuit.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Hart, Nilsson, and Raphael&amp;rsquo;s 1968 A* paper for best-first graph search; Pearl&amp;rsquo;s heuristic-search framing; and Koenig and Likhachev&amp;rsquo;s D* Lite work as background for why replanning problems often need incremental or receding-horizon structure.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; weighted A*, time-expanded A*, dynamic target pursuit, receding-horizon replanning, 8-connected grid search, wait action, collision threshold, cost map, multi-source Dijkstra, static meet point, trajectory visualization, C++, CMake, Python, Matplotlib.&lt;/p&gt;</description></item><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><item><title>Symbolic Planner</title><link>https://kenryhou2.github.io/projects/symbolic-planner/</link><pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/symbolic-planner/</guid><description>&lt;p&gt;I built this symbolic planner to make classical AI planning concrete. Instead of commanding robot trajectories directly, the planner reasons over facts such as &lt;code&gt;Clear(A)&lt;/code&gt;, &lt;code&gt;On(A, B)&lt;/code&gt;, or domain-specific predicates for a robot-fire-extinguisher task. It parses compact domain files into symbols, grounded initial facts, goal facts, and action schemas with positive and negated preconditions and effects.&lt;/p&gt;
&lt;p&gt;The planner grounds action schemas by enumerating ordered symbol tuples of the required arity, substitutes them into each action&amp;rsquo;s preconditions and effects, filters actions whose grounded preconditions are satisfied in the current state, and applies add/delete effects to generate successor states. Search uses an OPEN priority queue and CLOSED state set, with parent pointers for plan reconstruction once all goal facts are reached.&lt;/p&gt;
&lt;p&gt;The repository includes several planning environments: standard Blocks World problems using &lt;code&gt;MoveToTable&lt;/code&gt; and &lt;code&gt;Move&lt;/code&gt;; a Blocks Triangle variant with &lt;code&gt;Block&lt;/code&gt;, &lt;code&gt;Triangle&lt;/code&gt;, &lt;code&gt;NotTable&lt;/code&gt;, &lt;code&gt;Clear&lt;/code&gt;, and &lt;code&gt;On&lt;/code&gt; predicates; and a FireExtinguisher domain where a robot and quadrotor coordinate movement, landing, charging, water refill, and repeated pour actions to reach &lt;code&gt;ExtThree(F)&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;The implementation exposes heuristic modes for Dijkstra-style search (&lt;code&gt;h = 0&lt;/code&gt;), missing-goal-count guidance, delete-effect penalties, and a combined heuristic. This makes the project a small testbed for seeing how much a heuristic can help when the branching factor comes from grounded actions rather than grid neighbors.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Fikes and Nilsson&amp;rsquo;s STRIPS paper for add/delete-list planning; Bonet and Geffner&amp;rsquo;s HSP work for heuristic planning; and Russell and Norvig&amp;rsquo;s AI planning chapters for the connection between symbolic search and robotics task planning.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; symbolic planning, STRIPS-style planning, grounded actions, action schemas, preconditions, add/delete effects, Blocks World, Blocks Triangle, FireExtinguisher domain, heuristic search, Dijkstra search, priority queue, state-space search, plan reconstruction, C++14, CMake.&lt;/p&gt;</description></item></channel></rss>