← Back to About

Work Experience

Hip exoskeleton work at CMU's Metamobility Lab — I led its design from Sep 2025 to May 2026 and now work on its control and sim-to-real — told in phases — failures and iterations included, not just the outcome. Earlier work and undergraduate projects are folded below if you want the fuller history.

Hip Exoskeleton

Active — Sep 2025–Present

Lead Designer, Sep 2025 – May 2026; then control & sim-to-real · Metamobility Lab, Carnegie Mellon University

The question underneath all three generations below: could a lighter, lower-torque exoskeleton design deliver more metabolic benefit than a heavier, higher-torque one?

Most of what follows has the same shape: a first guess that turned out wrong, and the real cause underneath it.

Before touching hardware: two months cleaning up an existing PhD student's control codebase — unglamorous, undocumented work, but it's how I got embedded in the project in the first place.

3.2kg
Current weight
4.2kg baseline → 3kg → 4.1kg → 3.2kg across three generations
17 N·m
Torque capacity, zero rocking
Up from 12 N·m — pilot metabolic test run at ~10 N·m
+
Metabolic pilot result
Positive reduction across all three pilot subjects
Mark I
The Reverse-Engineered Conversion
Oscar wearing the Generation One hip exoskeleton, converted from a commercial unit, in the Metamobility Lab

Is Lightweight Actually Better?

What I did
  • Reverse-engineered and converted a 2.5kg commercial exoskeleton to run our own motor and electronics
  • Diagnosed motor rocking under load by testing three concurrent hypotheses — pelvis fit, thigh contact, and hinge play
  • Recorded this lab's first-ever measurable metabolic benefit
Carried Forward
Engineering drawing of the Mark I motor and actuator assembly
  • Motor rocking under load, still unresolved on two fronts — pelvis fit never landed, and three hinge designs failed in sequence→ Mark II
Read the full build
I

Feasibility — Commercial Teardown, Conversion & First Validation

The Mark I conversion, worn and walking — Hypershell's chassis carrying our own motor, driver board, and wiring in place of its commercial internals.

Papers using the Samsung GEM exoskeleton suggested a lighter, lower-torque design could deliver more metabolic benefit than a heavier, higher-torque one. Hypershell's commercial device weighs just 2.5kg without batteries — light enough that testing this hypothesis, before committing the lab to a full from-scratch build, seemed worth doing first.

I designed an adaptor to mount our own motor and a custom PCB (mounted on top of the Jetson) onto the Hypershell structure, while reverse-engineering the device itself from the physical object — no manufacturer CAD or drawings existed, and Hypershell's thigh interface has an unusually complex curvature that made the reconstruction hard.

Chasing a flickering reading

During testing, the motor encoder reading was intermittent — good sometimes, bad other times.

Oscilloscope-style trace of position and command signals from the exoskeleton's control software, showing the encoder reading breaking up rather than tracking cleanly
Live position (pos_L / pos_R) and command (cmd_L / cmd_R) traces during testing — the reading breaking up rather than settling, which raised the question of why the driver board wasn't getting a stable signal.
The reprinted adaptor pieces in black PAHT-CF, showing the bolt-circle hole pattern
Reprinted in PAHT-CF after the PLA hypothesis — didn't fix the reading, but the material swap stuck anyway.

My first hypothesis was the mounting material: the lab was using PLA at the time, which deforms under motor heat, so I respecified it to PAHT-CF. The reading was still bad. The real cause turned out to be that the driver board couldn't be bolted down without matching the commercial unit's own hole pattern, which no drawings existed for either — solved with a custom shadow-casting rig, projecting the part at a larger scale to measure the hole coordinates on a lathe. About two weeks of work in total.

An optical comparator projecting a shadow of the driver board mounting plate at larger scale, with a digital readout measuring hole coordinates
The shadow-casting setup: an optical comparator projecting the mounting plate at a larger scale, read off against the Quadra-Chek digital readout to reconstruct the hole pattern by hand.

With a reliable reading, I ran a metabolic test on the converted device: a 5% reduction versus no exoskeleton, single subject — not conclusive, but the first measurable metabolic benefit this lab had produced. The past student's device hadn't shown one. That result was enough for our PI to commit to a full reverse-engineering of the device.

II

Full Reverse-Engineering — Three Suspects, One Culprit

Full reverse-engineering began at speed — I wanted a testable result fast, so I started with whatever was quick and cheap, evaluated it, and moved on when it failed. My CAD ended up visually near-identical to the commercial original, built entirely from measurement since no manufacturer drawings existed. Our 3D printer was too small for the full-scale parts, so I redesigned around that constraint while keeping the structure intact.

Mark I, rendered in SOLIDWORKS Visualize — drag to rotate a full 360°. The full-size render opens at 4K, with scroll-to-zoom.

When motor rocking showed up under load — the commercial device itself already rocked at 9 N·m — I had three suspects and worked all three at once: the pelvis interface, insufficient thigh contact, and the hinge.

The pelvis interface

Hypershell's own pelvis part sits on top of the glutes rather than the lower back, which I suspected made it inherently less secure. I tried several back-plate drafts — deliberately cheap, fit-check only, never load-tested for torque — but none fit perfectly. This thread stayed open through the end of Mark I.

Seven CAD iterations of the pelvis back-plate, from an early simple curved bar through progressively more integrated versions with cutouts and lightening holes, to a final wedge-shaped design
Seven back-plate drafts, in order. Each one got fit-checked and cut loose rather than carried forward whole — a plain curved bar first, then more contact area and lightening cutouts added as each version's failure suggested the next.
Oscar wearing an early 3D-printed pelvis back-plate draft against his hip to check fit
Fit-checking a draft against my own hip — geometry only, no load testing.
A different angle of the same fit check, showing the printed bracket strapped against the hip
Same check, rotated — none of these drafts fit perfectly.
A back-plate draft held up against a sheet of paper to check its silhouette
One of the discarded drafts, held against paper to check silhouette and bolt spacing before being thrown out.
A later, more integrated back-plate draft with a perforated lightening panel
A later draft, with a perforated panel cut in for weight.

The thigh interface

I considered adding high-thigh straps for more contact area, reasoning more contact would reduce rocking. Weighed against the comfort and gait trade-offs, I set the idea aside for the time being — a thread I'd pick back up in Mark II.

Hinge failures

The hinge looked like the fastest fix, so it got most of my attention. The door hinge already in place had gaps both between the pin and leaf and leaf-to-leaf. A quick plastic hinge sourced off Amazon didn't endure even 12 N·m.

Meanwhile, a McMaster metal hinge held to 12 N·m but rocked worse than the plastic one, from the same leaf/pin gap problem.

The McMaster metal hinge — the third one tried, after the door hinge and the plastic Amazon hinge — showing the same leaf/pin play that caused the rocking.

I modified it myself — dowel pins, redrilled holes, shims — which fixed the wobble and pushed it to 15 N·m, where it broke. Three off-the-shelf hinges, three separate workarounds, still failing: that's what convinced me to design a custom hinge from scratch instead.

Ends this generation at 3kg, down from the prior student's 4.2kg (both with battery).

Three off-the-shelf hinges, three failures. Next: eliminate the hinge problem at its source.
Mark II
The Custom-Fit Redesign
Oscar wearing the Generation Two hip exoskeleton, showing the ergonomic pelvis interface and custom hinge

Stop Chasing Fit-Everyone. Build One That Works.

What I did
  • Abandoned "fits everyone" to focus entirely on one working system — surfaced my own body in SolidWorks to build a Georgia-Tech-inspired, ergonomic pelvis interface
  • Eliminated hinge wobble at its source by building the pelvis interface with no separate ABAD hinge at all
  • Revisited a thigh-cuff idea shelved in Mark I — reasoning through why rocking amplifies farther from the motor — and built a tightly-fitted cuff
  • Turned a requested quick-release motor connector into a custom shoulder-bolt hinge — eliminating rocking entirely, up to 17 N·m
Carried Forward
Engineering drawing of the Mark II pelvis interface and custom hinge
  • Fits one body only — mine — not yet generalized→ Mark III
  • Motor doesn't sit flush on the non-flat pelvis surface→ Mark III
Read the full build
III

The Pivot — Building for One Body, Not Everyone

By the end of Mark I it was already April — seven months into the project — and I still didn't have a system working at high torque. I concluded the block-like pelvis design simply didn't fit well across different people, while Georgia Tech's more ergonomic approach looked promising: more pelvis contact points, better support. Test prints confirmed it fit well, and I committed to a Georgia-Tech-inspired pelvis interface from that point on.

I also made a deliberate scope cut: stop trying to fit everyone, and focus entirely on getting one working system — on myself. That meant abandoning some Mark I generalization work, like an extendable pelvis meant to fit a range of hip widths.

Building the ergonomic pelvis

With no body-scanning equipment available, I measured myself the old-fashioned way — circumference and midpoint-to-endpoint distances across the upper thigh, hip, and lower back — and used SolidWorks surfacing tools to reconstruct a model of my own pelvis, glutes, and thigh region from those measurements, then built the pelvis interface directly off that surface, crediting Georgia Tech's device design for the underlying approach. It fit me perfectly. It also surfaced a new problem: the resulting body-facing surface isn't flat, but the motor needs to sit flush on the sagittal plane or it delivers torque at an angle. Not severe enough to block progress yet — I didn't solve it until Mark III.

Eliminating the hinge

Motor rocking still hadn't gone away, even with a good pelvis fit. Having already lost faith in off-the-shelf hinges, I built the ABAD joint directly into the pelvis interface with no separate hinge at all, which eliminated hinge wobble as a variable outright. (Every ABAD hinge through Mark I had sat below the motor — this was the first time the joint moved close to it.)

IV

Still Rocking — The Thigh Interface and a Custom Hinge

Why distance from the motor matters

Rocking still persisted, which sent me back to the thigh interface as the last suspect. I think of it as a link–motor–link problem: secure both far ends of a link and the motor in between has room to rock; secure the link close to the motor instead, and it should rock less. Two things likely explain why. Any small angular play at a loose joint — a sloppy pin, an under-constrained contact — produces a linear displacement proportional to how far that joint is from the point you're watching, the same reason a wrench wobbles more at the far end of the handle than right at a loose bolt head. And if the structure itself flexes rather than just having play, cantilever-beam deflection under load scales with the cube of the distance from its support, so a compliant joint far from the motor bends disproportionately more than one close to it. Either way, constraining the far ends of the assembly — a good pelvis fit alone — wasn't enough; what mattered was constraining something close to the motor.

I came back to the high-contact thigh idea from Mark I, working through the earlier comfort and gait trade-offs by testing it directly. Using the same measure-and-surface method as the pelvis, I built a tightly-fitted thigh cuff leaving almost no gap against my leg.

Separately, my PI wanted the motor to be easy to attach and detach so it could be swapped across interfaces. I designed a removable hip-joint–pelvis connector for this — a shoulder bolt through the top of the motor that unscrews to remove the motor and hip-joint interface as a unit. That led directly to the idea that finally solved the hinge problem: since it already needed to be a shoulder bolt, swapping in one with a bushing turns the same fastener into a purpose-built hinge, solving the modularity request and the hinge problem with one part.

Tested in one attempt: no motor rocking at all, up to 17 N·m.

Mark I · 12 N·m · marching in place

Mark II · 17 N·m · level-ground walking

Not a controlled trial — Mark I is marching in place at 12 N·m, the same setup that broke the plastic hinge; Mark II is walking at 17 N·m, higher torque under real dynamic gait. If anything, that makes Mark II's zero rocking the harder result, not an easier one.

V

The Weight Trade-off

Solving the rocking issue brought the weight back up from 3kg to 4.1kg (with battery) — a byproduct of building tightly-fitted, integrated parts (the hingeless pelvis, the custom shoulder-bolt hinge, the close-contact thigh cuff) rather than a purely weight-optimized structure. I'm treating that honestly as a trade-off, not a regression. This is also a device custom-fit to one body — my own — which is its own limitation, and the subject of Mark III.

Mark II, rendered in SOLIDWORKS Visualize — drag to rotate a full 360°. The full-size render opens at 4K, with scroll-to-zoom.
Proven on one body, 17 N·m, zero rocking. Next: make it fit anyone.
Mark III
The Generalized Interface
Oscar wearing the Generation Three hip exoskeleton, showing the generalized straight-bar interface

Mature Enough to Ask a Harder Question

What I did
  • Generalized the pelvis interface to a movable design fitting a range of body sizes across the lab, after handing hardware leadership to a PhD student
  • Solved a resurfaced Mark II problem — the motor digging into the pelvis bone — by offsetting the motor for clearance
  • Replaced the ABAD hinge entirely with a flexing carbon-fiber sheet, closing out two generations of hinge failures for good
  • Ran a 3-subject pilot metabolic test at ~10 N·m that validated the project's founding hypothesis
Moving Forward
Engineering drawing of the Mark III generalized pelvis interface and dual-actuator harness
  • The calf cuff transmits torque best, the straight bar weighs least — testing whether a partial cuff, just the third closest to the motor, can hit the sweet spot between them→ Next study
Read the full build
VI

Generalizing Under New Leadership

By May, I wanted to spend more time on the control side of the project and stepped back from hardware, handing it to a PhD student in the lab. I only stepped back in when an undergrad's design attempt didn't work out.

The changes I made directly: reworked the pelvis interface to be movable, so it could generically fit a range of pelvis shapes across the lab — which immediately resurfaced the motor-mounting problem deferred from Mark II, since a varying pelvis shape made the non-flat mounting surface unavoidable. I fixed it by offsetting the motor for clearance. I also redesigned the strapping, from one stomach belt and one pelvis belt into two cross belts — noticeably lighter than before.

Straight bar, and cleaning up

An undergrad developed a straight-bar alternative configuration — a good concept that needed polishing, but he left partway through the summer before finishing it. I ended up cleaning up the CAD for the whole project.

Removing the hinge for good

The PhD student in charge took my advice to remove the ABAD hinge entirely — it does very little during level-ground walking anyway — replacing it with a carbon-fiber sheet that flexes slightly in the ABAD direction, closing out two generations of hinge failures for good. The PhD also tried a passive thigh-damping system; it didn't actually damp, but it did apply the strap-close-to-the-motor principle from Mark II.

Mark III, rendered in SOLIDWORKS Visualize — drag to rotate a full 360°. The full-size render opens at 4K, with scroll-to-zoom.

The result: about 3.2kg, tested on three subjects for metabolic benefit at roughly 10 N·m — 8 N·m for one subject, well under what Mark II proved the hardware could handle. That's the number that mattered: it's the direct test of the hypothesis that opened this whole project.

Bar chart of net metabolic rate for three subjects. Left: group mean 2.50 W/kg without the exoskeleton versus 2.18 W/kg with it powered, a 12.9 percent mean per-subject reduction. Right: every trial per subject in collection order, with per-subject reductions of 13.0, 7.4 and 18.4 percent.
Mark III metabolic pilot: three subjects, exoskeleton on (ExoOn) vs. no exoskeleton (NoExo), two trials each. Net metabolic rate = last 3 minutes of each trial minus standing (Brockway). Left: mean ± SD across subjects, with the −12.9% mean per-subject change; right: every trial in collection order. A pilot, not a powered study.

Ends this generation at 3.2kg, tested on three subjects — the number that answers Mark I's opening question.

Control & sim-to-real · Jun 2026 – present

  • Implemented and compared time-based estimation, piecewise and unified phase-variable gait-phase estimators on a hip exoskeleton across treadmill speed transitions.
  • Diagnosed double-peak torque commands in time-based estimation during speed changes: the rolling-average stride period lagged the true stride period, causing premature phase resets.
  • Selected heel-strike-triggered time-based assistance as the fit-agnostic controller for a fit study, removing feedback from fit-corrupted joint-angle and IMU signals.
  • Designing a study to identify human–exoskeleton fit error from onboard sensors (IMU, encoder) under injected torque, with motion capture as ground truth, to support controller compensation.

Also on this project

  • Supported 5 human-subject experiments — Bertec instrumented treadmill, K5 metabolic cart, marker-based motion capture, EMG placement.
  • Mentored 3 undergraduates. Built metabolic probes for a labmate's data pipeline.
  • Currently supporting two PhD students: one on data collection and processing, the other on an outdoor human experiment — where I'm writing the test plans, pilot-testing protocols on myself, and scouting locations.

Mark III's pilot metabolic test — run at roughly 10 N·m, well under what Mark II's hardware could survive — showed a meaningful reduction across all three subjects: proof the hypothesis that opened this project held. That result raised the question I'm working on now: how different interface designs affect torque transmissibility.

Class Projects — Carnegie Mellon 1 project, 2026

Coursework during the same CMU era as the project above — kept lightweight here, full report linked below.

Intro to Reinforcement Learning · Carnegie Mellon · Feb – May 2026

Musculoskeletal Digital-Twin of Human Gait via Reinforcement Learning

With Changseob Song and Rajiv Josh.

Why

Rehab is trial-and-error — every patient responds differently to a given recovery plan, so clinicians largely learn what works by testing it on the patient directly. A "digital twin" moves that trial-and-error into simulation instead: an RL-trained virtual patient that lets a recovery strategy get tested and forecast safely before it's tried on a person. This project builds the first piece — a musculoskeletal agent that learns human-like walking — as a step toward eventually predicting gait for stroke, Parkinson's, and cerebral palsy patients.

What we built

A full-body musculoskeletal model in SCONE, simulated with the Hyfydy physics engine. Instead of controlling every individual muscle, the agent outputs 25 muscle-synergy activations (11 per leg + 3 trunk) — closer to how the CNS actually simplifies motor control. Reward combines a Gaussian forward-velocity/stability tracking term, a range-of-motion penalty on the knees and lumbar, and two terms we specifically tested the impact of: a muscle-effort penalty and a fall penalty (episode ends if the agent's center of mass drops).

What the videos below compare

Two questions. First: which training method actually learns to walk — random actions vs. PPO (on-policy) vs. SAC (off-policy) vs. SAC with a learned dynamics model bolted on (model-based RL). Second: do the effort and fall reward terms actually matter — tested by re-training SAC with each one removed.

Reinforcement LearningMusculoskeletal SimulationSCONE / HyfydySAC / PPOMuscle Synergies

Random agent — baseline

No training at all. Falls within a step — the starting point every method below has to beat.

PPO (on-policy)

Never got past one gait cycle — its action variance collapsed before it found a walking strategy.

SAC (off-policy)

Walks without falling after 20M training steps — entropy-driven exploration is what got it there.

Model-based RL

SAC plus a learned ensemble dynamics model. Similar end performance to SAC, with fewer training collapses over a longer 75M-step run.

SAC — no effort penalty (ablation)

Muscle activation goes unconstrained — visibly stiffer, over-actuated gait, and more falls during training.

SAC — no fall penalty (ablation)

Training curves barely change, but the stance visibly widens — a less human-like walking pattern.

Takeaway: SAC's exploration was what made walking learnable at all — PPO and random both stayed near zero reward. Of the two reward terms tested, the effort penalty mattered most for realistic movement; the fall penalty barely moved the training curves but still shaped a more natural-looking gait.

SAC vs. PPO vs. random baseline, model-based RL, and two reward ablations · CMU · Completed
Earlier Work — Before the Lab 2 roles, 2023–2025

Paid roles between undergrad and CMU. Kept lightweight — the depth lives in the project above.

Apr 2024 – Mar 2025Suzhou, Jiangsu, China
Lab Assistant
Soochow University, Embedded Systems Lab
  • Developed synchronous serial communication (SPI) between two MCUs and a host computer as part of a graduate research project
  • Built a C# UI to translate between characters, binary, decimal, and hex, improving debugging efficiency
  • Prepared 68 PCBs by soldering electrical components for an undergraduate course
Jul 2023 – Dec 2023Orangeburg, SC, USA
Equipment Engineer
Hounen Solar America Inc.
  • Maintained and operated a solar cell stringer soldering machine, reducing unplanned downtime by 40%
  • Reduced assembly line blockage from twice a day to once per three days using FMEA
  • Wrote standardized operating procedures for 4 machines, cutting average training time by 50%
  • Instructed over 12 employees on machine operation along the assembly line
Undergraduate Projects — Virginia Tech 3 projects, 2021–2023

Coursework and team projects from before the field rejection story turned into a real direction — see How I Got Here.

DJI RoboMaster Competition · Virginia Tech · 2021–2023

"Hero" Sub-team, Mechanical Engineer

  • Redesigned the golf-ball launcher feed path, cutting weight by 67% and assembly time by 40%
  • Built a mobile welded test chassis to field-test target lock-on robustness
  • Trained 4 new members on converting 3D CAD into CNC-manufacturable parts
Full write-up pending · Archived
Senior Capstone · MELD Automation Prep Line · 2022–2023

Mechanical Engineer

  • Designed a pneumatic trap door releasing cut bar stock within 13% of the allotted cycle time
  • Iterated corner-bracket geometry through FEA to a 2% safety-factor margin
  • Fabricated motor brackets by CNC mill and MIG welder, rated to 3× desired mass
MELD Automation Prep Line senior capstone poster — problem statement, detailed design, FEA and other modes of analysis, product evaluation, self evaluation and future work

Full capstone poster — click to view large

Poster available · Archived
Intro to Human–Robot Interaction · Virginia Tech · 2023

"Best Pokémon Trainer" — Inverse RL

  • Built a Python database of Pokémon statistics, widening AI-generated variation by ~400%
  • Recovered reward weights via Metropolis–Hastings, std. dev. of 0.025
  • Trained an IRL agent to a 72% win rate vs. a simple AI, 45% vs. a human

View code on GitHub ↗

Code + intro video available · Archived