ARMA
A voice-controlled robotic arm for a workbench. It holds a conversation without the user picking up a phone, extracts fumes when positioned near the work, and plays audio through an open speaker so the person using it keeps their hearing on the room. Designed, modelled, printed, wired and programmed end-to-end as a single build.
What it does
ARMA answers questions, runs calculations and picks music on voice command, so the phone stays in the pocket. That was the starting point: a worker at a bench doesn't need fewer tools for information, they need one that isn't also the thing pulling their attention off the job.
The arm carries an extraction fan to the work rather than waiting for fumes to reach a fixed hood, and audio comes out of an open speaker instead of earbuds, so nothing gets between the user and the sound of the workshop around them.
Movement guard rails and the safe response protocol are written as code, not documentation — a spoken command cannot talk the arm past them.
How it's built
Control is split across two processors deliberately. The Arduino handles motion, because driving actuators in real time needs timing that never slips. The Raspberry Pi handles wake word detection, filtered speech to text, the conversation layer and camera detection, because those need an operating system and a network.
Every conductor is soldered and heatshrunk rather than twisted or taped, with screw terminals at the drivers, buck converters and power supplies so those parts can be swapped without cutting into the loom. A 250 V 10 A fuse sits at the head of the circuit. Nothing in the electrical system has failed, melted or shorted.
The base is 40 mm recycled hardwood, routered along the top edge, drilled for casters and finished by hand — it's the lift point, the electrical isolation from the bench, and the mass that keeps the centre of gravity low. A recycled plexiglass panel keeps the internals visible.
What went wrong
Most of the sixty-plus rejected prints came off the bed complete and then didn't fit — warp across large flat sections and variation in extrusion width meant the printed part was always slightly different to the model. The fix was re-iteration, not slicer settings: measure the real part, find where it moved, remodel with the difference built in.
The shoulder servos stripped their gears under load. No replacement was obtainable within driving distance, so the joints were fixed at 45° and the load rebalanced through the elbow — base rotation, elbow, claw, extraction and conversation all survived. Voice recognition also failed on Australian accents, which moved the system from an offline recogniser to a filtered speech-to-text API.
What that taught me
The stepper motor was the only actuator specified directly from a torque calculation, and it is the only actuator that never failed. The shoulder servos were specified despite an analysis that already showed the load sitting near the limit of that gearing. That's a selection failure, not a workmanship one, and it's the most useful thing the build taught me.
The recovery pattern that worked was substitution rather than extension: when a constraint wouldn't move, the plan was rewritten around it instead of waiting. Running the mechanical, electronics and software phases in parallel — writing motion control and the voice stack during print failures and supply runs — is the only reason it finished at all.
Engineering drawings above are from the Onshape model. Photography of the finished build is being added — the arm exists, it's just not photographed well yet.