Robot Arm Kinematics: From Servo PWM to Inverse Kinematics

Robot arm kinematics is the geometry that connects two things a manipulator has to reconcile: the joint angles it can actually command, and the tool position you want in the world. Going one way—angles to position—is forward kinematics, and it is easy. Going the other way—position to angles—is inverse kinematics, and it is where the interesting problems live: two solutions, edges you cannot reach, and poses where the arm briefly loses control of a direction.

This path builds that understanding from the ground up. You start with the hardware—getting a servo to move to a commanded angle through a PCA9685 driver, calibration and all. Then you learn the geometry: how a two-link arm’s angles place its tool, and how to invert that to reach a target. Finally you explore it live in the simulator, dragging a target and watching the solver pick joint angles, hit the workspace boundary, and flag the unreachable.

Follow the nodes in order—each unlocks the next once you have done it, and your progress saves on this device. When you are ready to build the real thing, this path feeds straight into the 4-DOF robot arm project.

Before you start

You need trigonometry — specifically sin, cos, and atan2 — and enough programming to write a function that returns two values. Servo experience helps but the path covers it. Nothing here requires the physical arm; the whole geometry can be learned in the simulator.

What you will be able to do

• Compute where a two-link arm’s tool sits from its joint angles, and invert that to find the angles that reach a given point.
• Choose deliberately between the two solutions — elbow-up and elbow-down — instead of taking whichever one the maths returned.
• Predict the boundary of the reachable workspace and detect a target outside it before the arm tries to move.
• Recognise a singularity as the arm approaches full extension, where a small change in tool position demands an enormous change in joint angle.
• Measure the play in your own joints, and say how much of the gripper’s error is the mechanism rather than the maths.

Where people get stuck

Using atan instead of atan2. Plain atan cannot tell which quadrant the target is in, so the arm reaches correctly in front and mirrors backwards behind. atan2 takes the two components separately and gets all four quadrants right.

A domain error on acos. When the target is further away than the links can reach, the cosine rule produces an argument outside −1 to 1 and acos returns NaN. That NaN flows into the servo command as a garbage angle. Check reachability before the trigonometry, not after.

Confusing joint angle with servo angle. A servo’s zero is wherever its horn was fitted, and it may rotate opposite to your maths. Every joint needs a calibration offset and possibly a sign flip. Skipping this produces an arm that moves smoothly and lands nowhere near the target.

Ignoring gravity at extension. The geometry assumes the arm goes where told. A hobby servo holding a fully extended link is at its worst mechanical advantage, and the real position sags below the commanded one — most visibly at the far edge of the workspace.

Tuning a mechanical error. If the arm reaches the same point differently depending on which side it came from, no gain will fix it: that is gearbox play, multiplied by the whole length of the arm. Four degrees at a shoulder driving a 150 mm link is over 10 mm at the gripper.

Driving through a singularity. Near full extension the inverse solution becomes ill-conditioned, and a smooth tool path turns into a violent joint movement. Keep paths inside a margin of the boundary rather than up against it.

What you need

Why the path runs in this order

Servo driving comes before geometry, and it is not obvious that it should. The reason is calibration. Once you can command a joint and see where it actually lands, you have a way to test every later result against reality. Learn the geometry first and you have no way to distinguish a wrong solver from a mis-fitted servo horn — two very different faults that look identical from across the room.

Arm types come next because they explain what a “link” is. Cartesian, SCARA and delta arms solve the same problem with completely different geometry, and seeing three of them makes it clear that kinematics is about the arrangement of joints rather than about any particular arm. It also tells you why a SCARA’s IK is nearly trivial and a delta’s is not.

Inverse kinematics comes third, when both prerequisites are in place. It is the heart of the path, and it is the only node where you will spend real time on maths.

The simulator comes fourth because it makes the invisible visible. Reachability, the two elbow branches, and singularities are all things you can prove on paper and will not truly understand until you have dragged a target to the workspace edge and watched the solver’s behaviour change. Dragging is also the fastest way to find the shape of a workspace, which is an annulus rather than a disc whenever the links are unequal.

Backlash closes the path deliberately. It is the point at which you stop being able to improve the arm’s accuracy with better maths. Every node before it is about computing the right angle; this one is about the millimetres between the right angle and the right position.

Checkpoints: how to know a stage landed

Where this path stops

This path covers the planar two-link solution solved in closed form — the geometry behind the shoulder and elbow of almost every hobby arm. It is the right thing to learn first because you can derive it, check it, and see exactly why each failure happens.

It stops short of several things you will meet next. General n-DOF kinematics uses Denavit–Hartenberg parameters and homogeneous transformation matrices to describe any chain of joints systematically, rather than solving each arm’s geometry by hand. Numerical IK — Jacobian-based iteration — is what you use when no closed-form solution exists, which is the normal situation past four or five joints; it also degrades gracefully near singularities where a closed-form solution simply breaks.

Redundancy resolution is the question of what to do when an arm has more joints than the task constrains and therefore infinitely many valid solutions — a genuinely interesting problem this path never has to face, because a two-link arm has exactly two.

And dynamics is the whole other half of manipulation: kinematics says nothing about forces, inertia, or how fast a joint can move without overshooting. Everything here assumes the arm goes where it is told, slowly enough that the assumption holds.