Rock-Paper-Scissors Robotic Hands

Provided vs. designed: the hand itself (a palm on a ball-joint holder, with three-segment fingers, a two-segment thumb and click-together ball joints) came from the course. The actuation, spools, mounts, covers and base described below are our team’s design.

We based the actuation on the human hand: motors act as the muscles and fishing line as the tendons. Watching our own hands throw each gesture showed that the index and middle fingers always move together, and so do the thumb, ring and pinky. So instead of one actuator per finger, each hand uses two motors:

• Tendons and returns. Fishing line is tied through holes drilled in each fingertip and wound onto a spool on the motor. Elastic bands run from the fingertips to the back of the palm, so the fingers spring back open when the line goes slack. Early tests showed that line has to do the pulling and elastics only the returning.
• Grooved spool. One motor has to reel in several lines without tangling them. Two spools wouldn’t fit on the motor shaft, so we made one Ø30 mm spool with a raised centre divider that keeps each line in its own channel.
• Covers for the “minus one”. Physically pulling a whole hand away would have needed far more mechanism and space. Instead, each hand has a flap on a servo-driven arm, hinged at the top of the board, that only has to swing about 90°, well inside a servo’s 180° range.
• Mounts and base. A ¾″ plywood base holds a 300 mm backboard. Each hand’s holder cup screws to the backboard so the hand sticks straight out, with its two motor holders mounted below it. The cover servos sit on the top edge of the board, and each flap swings down from upright to lie flat over its hand.
• Manufacturing. All custom parts are PLA, which is cheap, quick to reprint and strong enough for these low loads. Stiff joints and mating faces were sanded after printing to cut friction.

The SolidWorks drawings for the spool, motor holder, servo mount, servo holder and base are in the gallery.

Each hand has its own ESP32-WROOM-32 (on an MSE Duino board), its own MX1508 motor driver and its own cover servo. Both boards use the same pin layout, which made wiring, debugging and copying the hardware much simpler. The work is split across two boards partly because one board couldn’t power four DC motors and two servos at once.

• DC motors run through the MX1508’s dual H-bridge. Each motor uses two GPIO inputs: driving one high spins it one way and driving the other high reverses it, which we need to both curl and reset the fingers. A motor that spun the wrong way could be fixed by swapping its leads at the driver output.
• Servos connect straight to a GPIO pin and are positioned with a PWM signal. They need 5 V while the ESP32 runs at 3.3 V, so they are fed from the board’s 5 V rail (USB or an external pack) rather than the logic supply.

Choosing which hand to keep

// Case 3: opponent showed a different, non-identical pair
char shared = getSharedHand(myA, myB, oppA, oppB);
char other  = getOtherHand(myA, myB, shared);

int roll = random(0, 3);          // 0, 1, 2
return (roll < 2) ? shared : other;  // keep shared 2/3, other 1/3

We built and tested one hand first, so problems got fixed before we printed the second. Below are the mechanical tests, the elastic strength data and the firmware and integration problems we found and fixed.

Elastic band tensile test

To check whether rubber bands could provide the return force, we pulled bands to failure with a digital luggage scale, with the other end anchored under a couch so a snapping band would fly away from whoever was pulling. The results were inconsistent: bands that had already been stretched past their elastic limit broke far earlier. Doubling the bands raised the breaking load, but by less than double, and both bands failed in quick succession.

Firmware & integration

The final system played full rounds of RPS-1 consistently and repeatably. It formed all three gestures with just two motors per hand, chose which hand to keep for every possible opponent pair, and covered the correct hand at the end of every round. The master and slave stayed in sync over repeated test cycles with no significant packet loss.

Limitations and what I’d do next

• Close the loop. Add motor encoders for position feedback instead of timing. The schematic already shows motor/encoder units and the firmware reserves encoder pins.
• See the opponent. Replace typed Serial Monitor input with computer-vision gesture detection, so the robot doesn’t need a laptop or someone typing.
• Clean up the wiring. Two boards, four motors, drivers and servos got cluttered. A custom PCB or proper cable management would make it more reliable and easier to debug.
• Longer-life tendons. Line and elastic tension change over time, and the grooved spool reduces tangling but doesn’t eliminate it over long use.