I built my first serious mechanical system in my first year of college (2024), before I had formal training in CAD or mechanical engineering.
I was on a student team working on a bionic arm project with very open-ended usability specs. That openness could have diluted the work. Instead, we aligned on a constraint that forced clarity: Cost comes first. Power and modularity are next.
That single decision immediately revealed the real engineering problem.
Early on, we ran into a tradeoff that felt fundamental: if you map “one motor to one joint,” you get one controllable degree of freedom per actuator. A human hand has many joints. The implication was a hand with ~12 motors: expensive, heavy, difficult to package, and fragile in practice. Even if we had the budget, the weight and packaging would have made the project bulky and fragile.
How do you get useful finger motion without buying (and carrying) a motor for every joint?
Because I didn’t have the background at the time to know what “the standard approach” was, my instinct was to go with brute-force exploration: read widely, follow curiosity, and build a mental library of mechanisms.
The key shift came from mechanism design.
A four-bar linkage, usually used in oil pumpjacks, can convert a simple linear input into a constrained, repeatable trajectory. Applied to a finger, this meant:
- Motion could be encoded in geometry, not controlled independently at each joint
- One actuator could drive coupled motion across multiple joints
- The system trades control complexity for mechanical intelligence
Using linkages instead of assigning one actuator per joint reduced the number of actuators while still achieving coordinated motion across multiple joints. We reduced the actuator requirement from ~12 independent motors to a single actuator driving coordinated finger motion through linkage geometry. The resulting design was simpler, lighter, and cheaper than the one-motor-a-joint approach.
Instead of “control everything with motors,” the hand could be designed so that one actuator produces a natural curling trajectory mechanical coupling.
Put together (Left), Switched from pulley to linear actuator + lever for more force, simpler motion, and fully laser-cut fabrication (Right)
Why $0 BOM?
With cost as the throughline, we pushed toward an intentionally aggressive target:
$0 mechanical bill of materials.
In practice, this meant laser-cut parts and a reused actuator from a Penn senior project scrap room. This forced decisions that simplified fabrication, reduced part count, and kept the design grounded in what could actually be built.
At first glance, this appears to be a constraint, but in practice, it served as an acceleration mechanism. A $0 BOM removes friction from the iteration process. There’s less need for an approval step, no hesitation about “wasting” parts, and batching designs to save cost. You can cut, assemble, test, and throw away within the same session.
Under a $0 BOM mindset, engineers build rather than overthink, let go of bad ideas quickly, and test as soon as something is viable.
It also compresses the design space in a useful way. If a part can’t be laser-cut or assembled from what’s already available, it’s excluded by default. That eliminates entire classes of overengineered solutions and biases toward simpler mechanisms.
Because each loop is cheap (effectively free), you can run more of them. More loops mean better intuition, faster convergence, and higher-quality outcomes. In that sense, $0 BOM isn’t just about cost minimization; it is a way to buy time for iteration.
Instead of optimizing for theoretical performance, we optimized for how quickly we could learn from the next build.
How can we make findings like this more common? There are a few factors that, in retrospect, seem to have mattered.
Wide search, low attachment to priors
Not knowing the “correct” approach meant I explored a larger space of mechanisms. This is occasionally helpful. If you don’t already know which approaches are supposed to be correct, you’re less likely to prematurely narrow the search space.
Flat team structure, Ownership
The team had a flat enough structure that a freshman could do real work on a subsystem. Most of the useful work happened in a small number of longer work sessions, but because iteration was fast and local, I could deliver concrete results in an end-to-end system. My productivity came in intense bursts: a few multi-hour sprints where I could go deep, iterate quickly, and deliver concrete proposals rather than partial work that doesn’t properly fit together with other components.
Mentorship
Huge thanks to PLs Joe and Natey Kim, who helped me avoid dead ends and focus energy on real engineering progress instead of getting lost in the space of unknown unknowns.
The main benefit of mentorship wasn’t getting answers directly, but avoiding unproductive directions.
In a system with many unknowns, it’s easy to spend time on problems that don’t matter or paths that don’t work. Having guidance on where not to spend time was more valuable than detailed instruction on what to do.
Looking back, this project reinforced a few patterns that seem to generalize:
- Start with constraints and let them shape the system. If cost is the priority, don’t treat it like a footnote. Let it drive the design space.
- Learn aggressively and curiously. When you don’t know the norms, you can explore further and sometimes find simpler solutions.
- Optimize for prototypes, not speculation. Multi-hour build sprints with some prototype beat weeks of theoretical debate.
- Mentorship is a force multiplier. It prevents dead ends, calibrates ambition, and keeps learning energy focused on what matters.
