<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Robotics | Henry Kou</title><link>https://kenryhou2.github.io/tags/robotics/</link><atom:link href="https://kenryhou2.github.io/tags/robotics/index.xml" rel="self" type="application/rss+xml"/><description>Robotics</description><generator>HugoBlox Kit (https://hugoblox.com)</generator><language>en-us</language><lastBuildDate>Thu, 07 May 2026 00:00:00 +0000</lastBuildDate><image><url>https://kenryhou2.github.io/media/icon_hu_da05098ef60dc2e7.png</url><title>Robotics</title><link>https://kenryhou2.github.io/tags/robotics/</link></image><item><title>ARPA-E Pipe Inspection</title><link>https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/</guid><description>&lt;p&gt;I worked on this as a confined-space robotics problem: how do you make an inspection robot useful when the environment is narrow, dark, repetitive, and hard to instrument? Pipe inspection is not just a mobility problem. The robot also has to keep enough sensing coverage and map consistency for an operator to understand where defects or misalignments are located.&lt;/p&gt;
&lt;p&gt;My work connected crawler hardware, embedded sensing, and mapping interfaces. The mapping GUI below shows the kind of alignment problem that comes up when local sensor observations have to be stitched into a coherent pipe-scale view. In a pipe, small pose errors are easy to hide visually but can become large localization errors along the run, so the inspection interface needs to expose uncertainty and misalignment clearly rather than only showing a polished map.&lt;/p&gt;
&lt;p&gt;
&lt;figure &gt;
&lt;div class="flex justify-center "&gt;
&lt;div class="w-full" &gt;&lt;img alt="ARPA-E mapping misalignment GUI"
src="https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/mapping_misalignment_GUI.gif"
loading="lazy" data-zoomable /&gt;&lt;/div&gt;
&lt;/div&gt;&lt;/figure&gt;
&lt;/p&gt;
&lt;p&gt;
&lt;figure &gt;
&lt;div class="flex justify-center "&gt;
&lt;div class="w-full" &gt;
&lt;img alt="Henry with pipe crawler"
srcset="https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/henry_pipe_crawler_hu_50dcd30817b6b985.webp 320w, https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/henry_pipe_crawler_hu_18ba225fb490a012.webp 480w, https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/henry_pipe_crawler_hu_d3468a2a4b384aa1.webp 760w"
sizes="(max-width: 480px) 100vw, (max-width: 768px) 90vw, (max-width: 1024px) 80vw, 760px"
src="https://kenryhou2.github.io/projects/arpa-e-pipe-inspection/henry_pipe_crawler_hu_50dcd30817b6b985.webp"
width="760"
height="508"
loading="lazy" data-zoomable /&gt;&lt;/div&gt;
&lt;/div&gt;&lt;/figure&gt;
&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Thrun, Burgard, and Fox&amp;rsquo;s &lt;em&gt;Probabilistic Robotics&lt;/em&gt; for the localization and mapping mindset; Grisetti, Kummerle, Stachniss, and Burgard&amp;rsquo;s graph-based SLAM tutorial for pose-graph thinking; and pipe/cave robot literature from CMU&amp;rsquo;s confined-space robotics work for practical constraints on mobility, sensing, and operator feedback.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; ARPA-E, pipe inspection, confined-space robotics, crawler robot, mapping, sensing, embedded systems, inspection robotics.&lt;/p&gt;</description></item><item><title>Boeing Material Deposition</title><link>https://kenryhou2.github.io/projects/boeing-material-deposition/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/boeing-material-deposition/</guid><description>&lt;p&gt;I am working on a process-control idea for ultra-large-format additive manufacturing, where the robot is big enough that structural vibration becomes part of the manufacturing process. If a long-reach system is depositing material for aircraft, bridge, or infrastructure repair, the tool may be commanded to move smoothly while the actual nozzle is still oscillating.&lt;/p&gt;
&lt;p&gt;The key shift is to stop treating motion control as the only place to fix the error. A low-stiffness plant may not have enough bandwidth or model certainty to fully cancel the vibration, but the deposition process can still react to the measured tool motion. My approach changes the deposition timing and rate based on real-time trajectory deviation, so material lands more evenly even when the tool path is imperfect.&lt;/p&gt;
&lt;p&gt;I validate the idea on a custom testbench that emulates the deposition dynamics. The sensor measures high-bandwidth tool motion, the controller estimates deviation from the desired path, and the process layer schedules material output around the residual vibration. The practical lesson is that process quality can sometimes be improved by controlling when material is added, not only by trying to make the structure perfectly still.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Altintas&amp;rsquo; work on manufacturing automation and process control; input-shaping literature from Singer and Seering for vibration-aware motion; and additive-manufacturing control papers on bead geometry, melt-pool monitoring, and closed-loop deposition rate control.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Status:&lt;/strong&gt; In progress.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; ultra large format additive manufacturing, ULF-AM, process control, deposition scheduling, vibration compensation, high-bandwidth sensing, trajectory deviation estimation, material deposition, manufacturing robotics.&lt;/p&gt;</description></item><item><title>EigenBot</title><link>https://kenryhou2.github.io/projects/eigenbot/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/eigenbot/</guid><description>&lt;p&gt;I use EigenBot as a way to study modular limbs where the hardware, sensing, and controller are all tightly coupled. A modular robot is appealing because the same building blocks can become many morphologies, but that flexibility makes control harder: the controller has to reason about contact, compliance, and changing body geometry.&lt;/p&gt;
&lt;p&gt;
&lt;figure &gt;
&lt;div class="flex justify-center "&gt;
&lt;div class="w-full" &gt;
&lt;img alt="EigenBot full limb platform"
srcset="https://kenryhou2.github.io/projects/eigenbot/eigenbot_full_limb_hu_6a5e232051268d94.webp 320w, https://kenryhou2.github.io/projects/eigenbot/eigenbot_full_limb_hu_b39c3640f486c383.webp 480w, https://kenryhou2.github.io/projects/eigenbot/eigenbot_full_limb_hu_3cbe25c28ba96f9e.webp 760w"
sizes="(max-width: 480px) 100vw, (max-width: 768px) 90vw, (max-width: 1024px) 80vw, 760px"
src="https://kenryhou2.github.io/projects/eigenbot/eigenbot_full_limb_hu_6a5e232051268d94.webp"
width="760"
height="507"
loading="lazy" data-zoomable /&gt;&lt;/div&gt;
&lt;/div&gt;&lt;/figure&gt;
&lt;/p&gt;
&lt;p&gt;My part of the work focuses on force-sensing experiments, full-limb behavior, and early neural-controller results. The full-limb platform gives a concrete test case for asking whether local sensing can support useful global motion, especially when the robot is assembled from repeated modules rather than a single monolithic mechanism. See the
and watch the
.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Yim, Shen, Salemi, Rus, Moll, Lipson, Klavins, and Chirikjian&amp;rsquo;s modular self-reconfigurable robot survey; Cheney, Bongard, Lipson, and Clune&amp;rsquo;s evolved soft robot work for morphology-control coupling; and recent differentiable or neural locomotion papers as context for data-driven controllers on physical robots.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; EigenBot, modular robotics, force sensing, robot limbs, neural control, embedded sensing, physical robot experiments.&lt;/p&gt;</description></item><item><title>Medusa Space Arms</title><link>https://kenryhou2.github.io/projects/medusa-space-arms/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/medusa-space-arms/</guid><description>&lt;p&gt;I worked on Medusa as a space-robotics arm testbed, where the physical setup makes coordination visible. The carriage-mounted arm lets us study manipulation and sensing on a system that is not just a fixed industrial arm bolted to the floor; base motion and arm motion both matter.&lt;/p&gt;
&lt;p&gt;The project connects mechanical system design, embedded sensing, and control implementation. The useful technical question is how much coordination you can get from a real platform when sensing, actuation limits, and geometry are all present at once. Watch the
.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Yoshida&amp;rsquo;s space robot dynamics work for free-floating manipulation context; Dubowsky and Papadopoulos on planning and control for space manipulators; and standard resolved-rate / operational-space control references for connecting arm motion to task-space behavior.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; space robotics, robotic arms, manipulation, carriage-mounted testbed, controls, sensing, embedded systems.&lt;/p&gt;</description></item><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>MPPI Wheeled Quadruped</title><link>https://kenryhou2.github.io/projects/mppi-wheeled-quadruped/</link><pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate><guid>https://kenryhou2.github.io/projects/mppi-wheeled-quadruped/</guid><description>&lt;p&gt;
&lt;figure &gt;
&lt;div class="flex justify-center "&gt;
&lt;div class="w-full" &gt;&lt;img alt="Unitree Go2W wheeled quadruped using MPPI on rough terrain"
src="https://kenryhou2.github.io/projects/mppi-wheeled-quadruped/demo.gif"
loading="lazy" data-zoomable /&gt;&lt;/div&gt;
&lt;/div&gt;&lt;/figure&gt;
&lt;/p&gt;
&lt;p&gt;I built this project around a control question that comes up with wheeled-legged robots: can one sampling-based controller handle both stepping and rolling without switching to a separate planner? I adapted a real-time whole-body Model Predictive Path Integral controller for the Unitree Go2W in MuJoCo, starting from a legged quadruped MPPI baseline and expanding it for hybrid locomotion.&lt;/p&gt;
&lt;p&gt;The controller adds four wheel-torque channels to the action space, augments the running cost with wheel-velocity regulation, a PD-shaped joint-effort penalty, and an L1 base positional drift penalty, and modifies the Raibert-style foot-placement heuristic to account for wheel speed. I wanted MPPI to remain the single control layer across walking, rolling, jumping, and stair-climbing tasks, without offline learning or precomputed contact schedules.&lt;/p&gt;
&lt;p&gt;Simulation tasks include &lt;code&gt;walk_straight&lt;/code&gt;, &lt;code&gt;roll_straight&lt;/code&gt;, &lt;code&gt;walk_octagon&lt;/code&gt;, &lt;code&gt;big_box&lt;/code&gt;, and &lt;code&gt;stairs&lt;/code&gt;, with task definitions covering goal positions, commanded body-frame velocities, gait phases, waiting times, MuJoCo model paths, and controller YAML configs. In the rough-terrain comparison, the wheel-aware controller reduces traversal time by 55.7% and raises forward velocity by 134.5% over the leg-only baseline while maintaining smoother wheel-ground contact.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sources I leaned on:&lt;/strong&gt; Williams et al. on information-theoretic MPPI; Theodorou, Buchli, and Schaal on path-integral control; Raibert&amp;rsquo;s legged-robot foot-placement heuristics; and recent wheeled-legged locomotion work on hybrid contact and wheel torque control.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Technical stack:&lt;/strong&gt; Python, MuJoCo 3.1.6, NumPy, SciPy, Matplotlib, &lt;code&gt;mujoco-python-viewer&lt;/code&gt;, editable &lt;code&gt;setuptools&lt;/code&gt; package.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Keywords:&lt;/strong&gt; whole-body MPPI, Model Predictive Path Integral control, sampling-based MPC, Unitree Go2W, wheeled-legged robot, hybrid locomotion, wheel-torque control, Raibert heuristic, gait scheduler, MuJoCo simulation, rough terrain, stair climbing, box jump, waypoint following.&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>