Exoskeleton part 1
I Turned a Drone Motor Into an Elbow
Here’s What That Actually Took
Few months ago my partner Adwaiy and I sat down to pick a final-year project, and we wanted something that actually helps someone, not another line-follower that dies in a drawer after the viva. We landed on an assistive elbow exoskeleton, for people who have almost zero ability to drive their own arm. Picking up a cup, a phone, a bottle… the stuff nobody thinks about until they can’t do it.
Sounds cool until you realise the thing is strapped to a person who cannot move out of the way if your code does something stupid. That one sentence ended up shaping every single decision in this build.
In this part ill explain the hardware: the motor, the gearbox, the board, and the maths that decided all of it. In the next part we tear down the firmware, why closed-loop FOC fought us, and how we made the thing safe enough to trust.
The stack
The whole joint runs on a 5010 360KV outrunner, basically a drone motor, with 7 pole pairs. It’s driven by a Makerbase MKS ESP32 FOC Mega running SimpleFOC, an AS5600 12-bit magnetic encoder reads the angle over I2C, and a 3S LiPo (12.6 V full) powers everything. Between the motor and the forearm sits a 3D-printed single-stage cycloidal reducer, designed in Fusion 360 and printed on a Bambu P2S, PLA for fit tests and PETG for the real thing.
The signal path is simple: battery → FOC board → three phases → motor → eccentric camshaft → cycloidal disc → output carrier → forearm.
Why not just use a massive gearbox?
This was the first real fight. Your elbow needs a few N·m, a drone motor gives you almost nothing, so the obvious answer is slap a 100:1 harmonic or a worm gear on it and call it a day.
Except a 100:1 gearbox is stiff. If the motor stops, the arm is locked in place, and for someone who can’t move their arm, a joint that locks up is the worst possible failure. So we went quasi-direct-drive (QDD): a strong low-KV motor with a low ratio. You give up some peak torque, but you get three things that matter on a body:
It backdrives, so when power dies the arm goes limp and can be moved freely. It’s transparent, motor current roughly tells you joint torque, so you can control force without a load cell. And reflected inertia scales with ratio squared, so 21:1 is way gentler on a human than 100:1.
We originally planned 40–60:1. We pulled it down to the low twenties on purpose.
The cycloidal reducer
A cycloidal drive is a lobed disc wobbling around inside a ring of pins. The ratio depends only on the counts:
ratio = N / (P − N)
N is the number of lobes on the disc, P is the number of pins. Ours is 21 lobes, 22 pins, so 21 / (22 − 21) = 21:1, in one printed stage. Lots of lobes share the load at once and it backdrives smooth, which a single printed planetary stage just can’t match.
The numbers: housing is Ø87 flange on a Ø77 body with Ø4 pins on a 69 mm PCD printed straight into it. The disc has 1.0 mm eccentricity, is 5 mm thick, runs on a 6801 bearing, and has six output holes on an 18 mm PCD (bumped from Ø8 to Ø9 so they clear the 1 mm orbit). Output carrier is 48 mm on a 6809.
Get Aditya Zagade’s stories in your inbox
Join Medium for free to get updates from this writer.
And here’s the part nobody tells you about printing gearboxes… the tightest gap in the whole thing is 0.2 mm between the disc profile and the pins. A consumer FDM printer holds maybe ±0.1–0.15 mm, plus elephant’s foot, plus shrinkage. So your clearance is literally inside your printer’s error. Too tight and it binds, too loose and it’s all backlash. Lesson learned: print a small disc-and-pin test coupon first, design a bit loose (~0.3 mm), and fit down.
One disc, so it needed a steel spine
Most cycloidals use two discs 180° apart so the forces cancel out. We went single disc to keep the stack short and the build simple. The catch is that the eccentric force no longer cancels, it spins around with the camshaft at motor speed.
For a cycloidal, output torque and that force are tied by:
T_out = N · F_ecc · e, so F_ecc = T_out / (N · e)
At 3.9 N·m output, N = 21 and e = 1 mm, that’s around 186 N whipping around a small printed shaft. PETG across layer lines hates rotating bending loads. So the one-piece camshaft has a Ø4 steel rod epoxied through its core.
A quick beam estimate says the rod sees about 190 MPa at 3.9 N·m, fine for any steel. Push it to 10 N·m and it’s ~480 MPa, hardened drill rod territory only. That single number is why the firmware torque limits in part 2 matter as much as the mechanics.
The camshaft itself is 41.1 mm: a Ø8 stub on a 688 bearing, a Ø12 lobe offset 1 mm for the 6801, a shoulder that only touches the inner ring, then a cone up to a Ø20 hub with 4× M3 for the motor. Printed vertical, 100% infill, 0.12 mm layers, bearing seats reamed to a light press fit.
The board
The 5010 can is too fat for the housing bore, so the motor sits in its own vented enclosure and couples into the camshaft through a 6 mm collar.
The MKS ESP32 FOC Mega pinout is not the same as the V1/V2 boards, and that cost us more time than I’d like to admit:
BLDCDriver3PWM driver(32, 33, 25, 12); // enable = GPIO12
float vin = analogReadMilliVolts(13) * 8.5 / 1000;
// AS5600: SDA 19, SCL 18, TwoWire(0), 400 kHzAlso, this motor’s phase resistance is tiny, ~0.1–0.3 Ω. Even 2–3 V across the windings is real current, so everything we wrote keeps the voltage low and ramps slow.
The honest maths
Rough joint torque per amp:
T_joint ≈ ratio × η × Kt = 21 × 0.7 × 0.023 ≈ 0.34 N·m per A
A forearm plus hand plus hardware needs roughly 2.3 N·m at the worst angle just to fight gravity. That’s reachable on this board. Lifting a heavy object on top of that… not with this motor and a printed reducer. So instead of pretending we built Iron Man, we framed it as gravity compensation: cancel the weight of the arm and help with light everyday objects.
And yes, η = 0.7 and the winding resistance are estimates. Measuring Kt with a known mass on a known lever is next on the list.
The point of this build was never maximum torque. It was a joint that’s strong enough to help and weak enough to never hurt.
Next part, the firmware: open loop, the FOC alignment fail, the gravity-comp control law, and every safety layer we stacked on top.
Final-year project, Government Polytechnic Mumbai, built by two of us: Aditya Zagade and Adwaiy Padwal.
