02Work

I design electromechanical systems that work when they are built.

I remember being excited during my first C++ class in grade school when the code that I would write compiled on the first try. If it didn't, no matter -- just read the error message and fix the bug. When it comes to hardware systems, errors can't be fixed by just changing two lines of code. A robot is a few hundred parts that have to function together both mechanically and electrically while meeting a performance target. The expensive part is never the first build — it is the second, and the third, after the first one did not work. Revision loops are where hardware schedules go. I have a tendency to design hardware systems that "compile on the first try."

I have spent sixteen years getting better at spending those loops on paper and digital tools instead: in notebooks, in simulation, in benchmarks that tell me early and cheaply when I am wrong. The work is just electromechanical design, controls and the mathematics underneath, but the throughline is that one habit.

Section 2.2 claims that the way to make hardware work on the first build is to spend the revision loops on paper. This is what that looks like.

The question is whether to cut parts from stock we already hold or buy stock to size. It is a purchasing question, so it arrives sounding like admin — but the cost is set by how much metal ends up as chips, and that is a geometry problem with an answer and it also is a very large ops question. Storage, cutting machinery, increased chip recycling and transport all matter here.

Constraints first: about 5 kg, 20 cm in width and depth, 20 cm tall. Then the densities, because a 12 cm cube of aluminium and an 8.5 cm cube of steel are the same 5 kg and that sets the size of the problem. Then the actual question: if we hold s different stock sizes, how much metal do we waste on average?

Waste in one dimension averages d/4s, so summing the three faces of a w × l × h piece gives ⁷⁄₁₆ · wlh/s. Spread the sizes evenly up to d_max and the total becomes a sum over i — one expression for how much a stocking policy costs, before anything is ordered.

The page ends on “how much does this cost?”, which needs parameterization based on the specifics of the situation. One may notice that this analysis does not include the recursive (to depth d) case for material reuse. True.

Below are a few side project that I found interesting. Each attempt to find out whether an abstraction, discovered while learning math, improves some concrete mechanism — a robot arm, a proof assistant, a benchmark — which sometimes it does not.

Real sensors arrive at different rates, with latency, jitter, drift and the occasional dropout, and the state you want is usually on a manifold rather than in a vector space. codynamic-sensor-data treats fusion the way a sheaf does — local observations that agree on their overlaps, glued into a global state — so a late measurement is not dropped but rewound into place, and sensors that genuinely disagree raise an error instead of averaging into a plausible lie.

This work supports all other sensor fusion techniques as well because it is based on a higher level of abstraction. Imagine if your robot design or control system didn't have to be a fight with the hardware, firmware, and software to make sure your data streams are perfectly synchronized? This code allows for that.

Full write-up, with interactive demonstrations →

A Bishop-style constructive real analysis library for Lean 4, built against Lean core only — no Mathlib, no Batteries, no dependencies at all. Every existence claim carries a witness; every limit carries an explicit, Type-level Cauchy modulus.

Every load-bearing theorem is gated by #print axioms to propext and Quot.sound only: no Classical.choice, no excluded middle, no native_decide, no sorry. The rationals are rebuilt from scratch because Lean's own Rat smuggles in Classical.choice through its decidable equality.

A policy trained in simulation learns the simulator as much as it learns the task, and the places it fails on real hardware are usually the places the simulator was wrong. The question I care about is what structure a world model has to carry for that gap to be small — and whether that structure can be stated in advance rather than hoped for.

Structure Is All You Need is the attempt: a network that restructures its own graph as it learns, instead of fixing the architecture up front and pushing everything into the weights. Related to it, I think distributed machine learning is the right shape for robotics. The sensing and the acting are already distributed, and forcing otherwise costs latency and synchronization issues that don't need to exist.

This is the part of my work I am least able to prove. It is a preprint, there is no number here I would defend, and I am including it because it is what I actually argue for in client work rather than because it is finished. Stay tuned for some code and writeups in this space.

Shortest paths are the substrate under most motion planning, so a method that preserves exact distances while cutting the edge count would be worth having. I built one — run Δ-stepping on a sparse skeleton of each node’s nearest outgoing edges, then patch a band on the full graph to keep the distances exact — and benchmarked it in C++ against two baselines.

My method came in slower than the plain baseline it was supposed to beat, while ordinary Δ-stepping won comfortably. At this size, on this graph family, with these parameters, the skeleton does not pay for itself.

A keyboard laid out on a manifold parameterised by the hand rather than by the desk: key orientation per finger, dish and fillet geometry, tenting contours, and a thumb that gets its own plane because it does not live in the same frame as the fingers.

It is a keyboard. It is also the problem of fitting a gripper to a task — reachability, orientation fields, contact patches, and one digit whose workspace has to be described separately. Same geometry, much cheaper failure mode.

Patents

• US9032635 — Physiological measurement device, with Hugh Herr2015
• US8801569 — Flexure-based torque sensor in a bicycle, sole inventor2014
• USD596084 — Motorcycle, design patent2009

Full list on Google Scholar and Google Patents.

I take on a small number of advisory and engineering engagements through Darthur LLC, and currently work with several robotics companies in the Bay Area.

Concretely, that has meant mechanism and actuator design, simulation, design review, advising, and systems and ops specification. Much of the process involves quantitatively determining what the functional requirements have to be for any given context/system using long-term thinking.

There is a separate page for the film and television work — robots on screen — which is the same knowledge pointed at a different problem. Reach out if you're making a film and need a science guy.

Reachable on Linkedin or on GitHub.