I built a physical shoe vending machine where a Next.js web app writes a command, a Raspberry Pi worker polls roughly every 1 s, and 4 MG996R servos dispense the selected shoe.

Motivation: Vend-A-Shoe exists because the client needed a real unit, not a bench demo. The architecture is browser command -> Supabase queue -> Pi worker -> GPIO/PWM -> physical dispense. I integrated the enclosure, harness, power distribution, and control software so that path stayed reliable with 4 servos, 8 LEDs, and a fan in the same box. Early failures looked like software bugs; many were actually electrical and mechanical issues, including faulty servos and power mistakes. The useful debugging loop was isolating one layer at a time with a known-good actuator, a bench supply, and a meter before touching code.

Challenge: Fitting 4 servos, 8 LEDs, a fan, harness, Pi, and power conversion into a serviceable enclosure.

OCaml compiler from a supported C subset to runnable x86-64, with TACKY IR and instruction fixups in between.

Motivation: I got tired of treating compilers like magic, so I started building one. Nora Sandler's book gave me the roadmap; I wrote the passes myself. Lexer and parser into an AST, then TACKY to flatten nested expressions, then stack-backed x86 with a fixup pass when memory-to-memory ops are illegal. Right now it honestly covers return constants and nested unaries like return ~(-2);. Broader C is next, but only after each stage stays correct.

Challenge: Direct AST-to-assembly stopped scaling once expressions nested.

Built a 12 V sensor-monitoring circuit with comparator thresholds, logic gating, and timing analysis; then compared buck regulators for 12-17 V to 5 V conversion.

Motivation: Independent engineering work for Penn Electric Racing's recruitment process; this is not PER vehicle hardware. I built and analyzed a threshold/logic/timing circuit where brake and current conditions must both be true before an indicator trips. The hard part was requirement interpretation and power-stage reasoning: 0.5 s behavior had to match spec language, and regulator choice had to include ripple, EMI, transient headroom, and thermal limits, not only nominal 5 V output.

Challenge: Response-time wording is easy to misread as a minimum delay.

Designed and fabricated a client tennis-ball launcher prototype at BrainChild Engineering integrating ESP32 wireless control, dual RS-775 flywheel drive, NEMA 17 stepper feed, MOSFET motor switching, and 12V-to-5V power regulation into a modular electromechanical system.

Motivation: I built this at BrainChild Engineering for a client demo that had to leave USB babysitting. The work meant migrating from an Arduino Mega / Bluetooth path to an ESP32 that owned motor sequencing; driving dual RS-775 flywheels through MOSFET modules under MCU PWM instead of pot speed controllers; indexing balls with a NEMA 17 on an A4988; and splitting a fused 12 V pack so actuators stayed on the high rail while a buck fed 5 V logic. The MOSFETs are hard switches: PWM duty cycle sets average motor voltage, and the motor’s inductance / inertia smooth the pulses. Failures taught as much as the architecture: no buck at first left the ESP32 dead on battery, the stepper print was too flimsy until a denser reprint, and a PWM test oversped a motor so hard that the fuse did not open, buck / battery solder joints came off, and a wire melted. It stayed a prototype on purpose: enough for a Replit-controlled multi-motor demo, not a finished consumer launcher.

Challenge: 12 V pack without a buck converter left the ESP32 unable to run correctly off battery.

Designed and fabricated a handheld electromechanical system integrating custom mechanical packaging, discrete analog electronics, embedded lighting control, and structural design into a durable wearable prototype.

Motivation: I built this in Detkin Lab as a handheld system that had to leave the breadboard. The work meant designing a custom Fusion 360 hilt, emitter, and battery carrier across multiple print revisions; integrating a discrete analog audio circuit (NE555 timer, RC network, PN2222A transistor) alongside LED blade illumination on a switched 9V power architecture; and manufacturing the boards with 40+ through-hole joints. The electronics were straightforward; the challenge was packaging them into a handheld device that could survive repeated impact and handling. Blade bending loads broke the hilt twice; cable length forced an LED pad salvage.

Challenge: Polycarbonate blade as a lever arm concentrated bending moment at the printed hilt.

IoT flower for long-distance check-ins: proximity opens the bloom, and remote messages blink out in Morse on an LED heart.

Motivation: The idea was simple: people far apart should still have something physical to share. BloomBot lives on an Arduino UNO R4 WiFi with Blynk. Get close and an ultrasonic sensor drives the servos to open the flower. Send a message from the app and an LED heart inside blinks that message in Morse. LCD output helps when I cannot sit on serial during a demo. The cute part is the flower. The hard part was keeping WiFi, sensing, multi-servo peaks, and Morse timing honest on one board without brownouts.

Challenge: Power rails brown out under concurrent servo peaks without margin and sequencing.

Reverse-mode autodiff in OCaml: forward builds a graph, backward fills grads, gradcheck keeps me honest.

Motivation: Framework backprop always felt like a black box, so I wrote my own. Nodes store values, grads, parents, and ops. Forward grows the graph; backward walks it. Most bugs do not show up in the forward pass; they show up when a shared node silently gets the wrong accumulated gradient. Finite-difference gradcheck is what I trust. The tiny MLP with SGD/Adam is just a smoke test that the pieces still talk to each other.

Challenge: Gradient bugs rarely show in forward outputs.