fade ninja

the problem

the back of a fade is the one part of a haircut you physically can't do yourself, and 'same as last time' at a barber is a guess from memory. we wanted a haircut to be something you can save and replay.

how it works

you hold an iphone like a clipper - it's the teach pendant. arkit tracks it in 3d and streams the pose over udp at 50 hz to a python server that does inverse kinematics, joint-limit enforcement, recording and replay, and an arduino drives four servos on a 3d-printed arm. a hold-to-lock clutch parks the arm so you can reposition your hand, like lifting a mouse off the pad. later you pick the cut from your library, press replay, and the arm runs it again with nobody holding the phone.

design choices

• heel on the scalp instead of hovering. the clipper's heel stays pressed on the scalp and the blade tilts away from it, so hair length is h = L·sin(θ) - about 0.43 mm of error per degree. holding the clipper at a set distance instead turns every millimetre of positioning error into a millimetre of length error, against a fade whose whole range is 0.5 to 8 mm. it's also what barbers do by hand: they rock the clipper out.
• record the actuator, not the controller. what gets saved is where the arm actually went, never where the phone thought it was - so a cheap, drifting sensor can't corrupt the recording.
• simulate first. we built a physics-lite simulator of the arm with forward and inverse kinematics, real joint limits and reachability, and put the control stack behind 235 automated tests before any hardware existed.
• refuse, don't repair. a recording that asks for an impossible pose is corrupt data - smoothing it back into range would quietly run it near someone's head, so replay refuses it instead.

what went wrong

• coordinate frames: the app sent position in the camera's axes instead of gravity-aligned world axes. held upright it looked fine; held like a clipper, up became forward. the same class of bug came back in orientation, where turning the phone sideways tilted the blade.
• a test that agreed with the bug: a sign error in the quaternion maths passed its unit test because the test helper used the same wrong convention. it only surfaced when we ran against a teammate's independently written simulator and the numbers disagreed.
• clipping joints instead of clamping targets: reaching past the arm's envelope froze it with the elbow folded and pushed the tip ~15 mm off the commanded line. clamping the target to the workspace before solving ik fixed both.
• the network: campus wifi's client isolation meant the phone and laptop couldn't see each other. after hours on it, we ran everything off a phone hotspot.

what i learned

your own tests can encode your own wrong assumption - integration against something someone else wrote catches what unit tests structurally can't. and every bug you find in simulation is one you don't find with a motor spinning next to a head.

team

built with tejas gautam, om upadhyay and saswath yeshwanth.