Wenxiong Hao

Graduate research at the Xi Chen Lab, Columbia University, on fast-swimming soft robotic fish driven by a pre-stressed bi-stable "hair-clip" mechanism. Published as a co-authored preprint (arXiv:2206.14867).

My work centered on the actuation. I built and compared two designs — a pneumatic-only fish and a pneumatic/SMA (shape-memory-alloy) hybrid — to find which made the fish swim fastest, prototyping each (CAD, 3D printing, silicone molding) and running them on a custom pneumatic test bench (solenoid-valve manifold, regulators, DC supply). The silicone actuators ballooned and leaked at higher pressures and faster actuation, so I used FEA to locate the high-stress regions behind that failure and fed the results back into the mold geometry to reinforce them. The pneumatic-only drive came out ahead.

I also ran a characterization study on the bi-stable mechanism itself, laser-cutting and testing it across a range of materials and dimensions. Those results helped establish that its swing amplitude is scale-independent — one of the paper's key findings.

My other main contribution was the body design. I reworked it with internal cavities to set the fish's buoyancy and center of gravity so it tracked in a straight line, removing the external foam float earlier prototypes had relied on. That was the change that unlocked the speed: the pneumatic fish reached 1.40 body-lengths per second, a 2× improvement.

Led a 5-person team to design and build an untethered, servo-driven robotic fish from scratch — driven by an Arduino Nano, a single servo, and a battery, all housed inside a 3D-printed body. I designed the body in SolidWorks and optimized the skeleton for structural integrity and FDM printability.

Much of the work was hands-on prototyping and iteration, especially on the tail. The first design used a pure-silicone tail swung by an internal servo-driven lever, but it came out too soft to push effectively. Under a tight budget I cut off the rear half of the silicone tail and coupled a stiff waterproof card directly to the internal linkage, so the linkage flaps the card as the working surface — then iterated the card into a C-shaped profile for the contact area a flat card lacked. The front section of silicone I kept, repurposed as a waterproof seal where the linkage exits the body. Inside the body, the servo linkage didn't fit the way the CAD assumed, because the actual rod stock I could source didn't match the designed dimensions; I reworked the internal cavity by hand (heat-forming and hollowing it out) to make the available hardware fit. Final waterproofing combined molded silicone with a waterproof coating over the printed body.

This was the first robot I built from scratch, and it became the base platform everything else grew out of — both the ground vehicle and the robotic fish started from what I learned here.

The cart is fully self-contained and runs untethered. Compressed air is stored onboard in a large tire mounted on top, which serves as the air reservoir, while a 12V battery powers the electronics. An Arduino times the cycle and switches an AirTAC solenoid valve to release air on each stroke, driving a pneumatic cylinder back and forth. Steering is handled separately by a servo: after the cart covers a set distance, it reads its heading from an onboard compass and the servo corrects its course, so it holds a straight line with no driver.

Turning that back-and-forth stroke into forward travel went through two iterations. The first drive used a one-way ratchet wrench: on the push stroke the cylinder advanced the cart, and on the return stroke the ratchet freewheeled, so the wheels didn't roll backward. It worked, but too much energy was lost in the mechanism — so I redesigned it to push directly against the ground on each stroke, which proved more efficient. I designed and built the wooden chassis, mounted and routed all of the pneumatics and electronics, and tuned the drive geometry so each stroke reliably produced motion.

My KTM 690 SMC R doesn't come with a tachometer from the factory. I found a small aftermarket trip computer that can serve as one, but it ships with no bracket — it's meant to be mounted however you like — so I designed and 3D-printed my own mount for it.

To get the geometry right, I 3D-scanned the handlebar area using my phone's scanner, brought that scan into SolidWorks, and modeled the bracket directly against the real bar profile rather than guessing at dimensions. The mount went through two iterations:

V1 (black): a curved section that wrapped around the handlebar and was bonded on with adhesive, with a square pocket on top to hold the trip computer's display. It worked, but relying on glue alone made it less stable than I wanted.

V2 (white): I addressed that directly. I added two small tabs so the mount could be secured a second way — zip-tied physically to the bar in addition to the double-sided tape — which made it far more solid. I also rotated the display-mounting face 90° relative to v1 — instead of lying flat along the curved bar clamp, it now meets that curve at a right angle — which gave a more sensible load path and held steady even in wind. And I angled the display face upward a little, so the reading angle is more comfortable while riding.

V2 was printed in white only because I'd run out of black filament — the color didn't matter functionally. Since I prefer black, I wrapped the finished part in black electrical tape, which also waterproofs it and keeps it visually consistent with the bike.

This is a straightforward demand-driven design: scan, model in SolidWorks, 3D-print, iterate twice, and it's been on the bike in daily use ever since. In the photos, the lit-up blue display is the trip computer mounted in the finished bracket.

I run a Jeep Wrangler 392 — among the first handful in the US — fitted with an aftermarket Atlas transfer case, and the two don't agree. The factory Drivetrain Control Module (DTCM) is built around the 392's 4Auto mode, but the Atlas has no 4Auto and brings 2High back instead, so once the truck is actually in 2High the module and the real drivetrain disagree and the ECU throws a conflict. The standard workaround is to disable the DTCM to clear the fault — but that same module is what softens the throttle in 4Low to keep the truck controllable on technical terrain. Disable it and 4Low turns hair-trigger, which makes the truck genuinely hard to drive for anyone who isn't wheeling for a living.

It landed on me for two reasons. The factory transfer case kept failing — two warranty replacements in two years, since the stock 4Auto's motor-actuated clutch can burn out under a sudden load — so rather than keep cycling through them I switched to what serious off-roaders run. And no one had solved the throttle side because the Atlas is racing-grade gear, bought mostly by people who don't miss the 4Low modulation; on a street-driven 392 the conflict is essentially inevitable, but the demand to fix it had never existed.

The fix came from thinking about equivalence. With the Atlas in place, my truck now had a base-Wrangler mode set — 2High / 4High / 4Low — rather than the 392's, so instead of disabling the DTCM I proposed swapping in the module from a regular Wrangler, which is built to expect exactly that configuration: it should clear the conflict and bring the 4Low throttle modulation back. Pinning down the exact donor was the hard part, because the right module depends on the trim and model year, and the wrong one leaves the control logic out of sync. I reasoned it should be a Rubicon, and another Wrangler owner from the forums — one with access to the factory module data — helped me check it. The guess was close but wrong: the donor had to be the base Sport trim.

With that module in, the truck recognizes the transfer case, runs my 4WD mapping through the ECU again, and the throttle is controllable. We fed the result back through my build and fab shops to Atlas, who validated it across several more trucks. It reduces to a repeatable procedure: fit a same-year base-Wrangler Sport DTCM, then use AlphaOBD over the OBD port to set the parameters. What I like about this one is that there was almost no documentation to lean on — the fix came from reasoning about functional equivalence between two drivetrain configurations and validating it on real vehicles, the same root-cause-and-validate work I do on hardware.

A recipe app that imports, generates, plans, and shops. Paste a link from Xiaohongshu or Xiachufang and it pulls the recipe in, simplifies it, and saves a clean copy — so it survives even if the original comes down. You can also type a dish or a few ingredients and let it generate one, snap a photo of a dish, OCR a screenshot, or photograph the fridge to pull several dishes at once. Opening a saved recipe shows an AI summary with ingredients, time, and difficulty.

From there it auto-builds a week of breakfasts, lunches, and dinners, and turns either the weekly menu or a single recipe into a category-grouped shopping list you check off as you buy. A health mode biases both the generated recipes and the weekly menu toward lighter, lower-fat options.