Robotic arm

Projects

A robotic arm driven wirelessly from a mobile app: the phone sets the destination, the firmware works out the motion.

Personal projectRobotics

The link: the Bluetooth LED and the destination it carriesThree servo joints and a two-jaw gripperThe phone sends only where the jaws should go. The firmware solves the joint angles for that point and moves there at its own pace, at most 140 mm a second, so a late packet delays a move rather than corrupting one. Cut the link and the arm stops where it is: an arm holding something must not let go.

RoleSole designer and engineer

StackC++ · Servo control · Inverse kinematics · Bluetooth · Flutter

The problem

Driving a multi-joint arm from a phone means a command leaves a touchscreen and has to arrive as coordinated motion across several motors, over a link that is neither fast nor reliable enough to be trusted with the details.

Constraints

Wireless link with variable latency and real dropouts
Six servos, five joints and a gripper, that must move together to be useful
Arm must fail safe when the connection goes away

Decisions

Send intent, not motor positions

The phone sends where the arm should go; the firmware decides how to get there. That keeps motion smooth when packets are late and means a dropped message delays a movement rather than corrupting one.

Hold position on link loss

The safe state for an arm holding something is not to release it. Losing the connection stops new commands rather than stopping the arm.

What I'd change

I put the inverse kinematics in the app before moving it into the firmware. On the device it belonged in from the start; the app should only ever have described the destination.