Go back
February 1, 2026

Two Degree-of-Freedom Robotic Arm

In my first year, I designed and built a two degree-of-freedom robotic arm controlled by C++ code running on an Arduino Uno. On the surface, it was a fairly typical introductory design project: design a mechanism, manufacture it, assemble it, and make it move between specified coordinates.

In reality, it became my first lesson in how intelligent control systems can compensate for imperfect hardware.


The Reality of First-Year Design

Like many first attempts at mechanical design, ours was not flawless: Assembly revealed small geometric inaccuracies that hadn’t been obvious in CAD, link lengths were slightly off, and servo horns didn’t sit perfectly aligned. At one point, we even used Blu Tack to damp a peculiar oscillatory vibration in one of the micro-servos — a very real reminder that physical systems rarely behave as cleanly as equations suggest.

Late-stage design changes meant that hard-coded motion sequences would quickly become obsolete. Every adjustment to geometry would require recalculating and rewriting angles by hand. So instead of relying on pre-defined joint angles, I decided to compute everything procedurally.


Designing in Cartesian Space

Rather than programming “move servo to 63°”, I defined positions in Cartesian coordinates — (x, y) target points in millimetres.

The control system then:

  1. Used circle–circle intersection geometry to determine feasible link configurations.
  2. Computed the corresponding joint angles through inverse kinematics.
  3. Generated “safe” approach positions above each target to avoid collisions.
  4. Converted angles to calibrated servo commands, compensating for offsets and linkage bias.

This meant that when link dimensions changed or tolerances accumulated, I only needed to adjust geometric parameters instead of rewriting motion logic. The arm could move sequentially between an unlimited number of target coordinates, and the underlying kinematics handled the rest. Despite mechanical imperfections, the system consistently achieved millimetre-scale positional repeatability relative to the target grid.


Controlling Around Imperfect Hardware

The interesting part of this project wasn’t that the arm worked, but why it worked. The servos were inexpensive and exhibited small nonlinearities. The structure had compliance. Assembly wasn’t perfectly square. Yet by:

  • Computing angles from first principles,
  • Introducing calibrated offsets,
  • Sequencing safe trajectories,
  • And carefully constraining angle bounds,

the software absorbed much of the mechanical uncertainty. Rather than fighting hardware limitations directly, the control system re-framed the problem mathematically.

The idea that intelligent modelling can compensate for physical imperfection has stayed with me ever since.


A Pleasing Realisation Later On

Later, I learned that companies like Renishaw use rigorous 3D coordinate geometry as the backbone of their precision metrology systems.

It was reassuring to discover that even in this small first-year project, I had instinctively chosen to describe motion in Cartesian space rather than in raw motor angles. While my implementation was simple, the underlying philosophy — geometry first, actuation second — mirrors approaches used in high-precision sensing and robotics.


What I Would Do Differently Now

Looking back from third year, I would redesign the software architecture significantly. Instead of storing joint positions across multiple arrays and manually handling angle logic, I would:

  • Represent each link using homogeneous transformation matrices.
  • Define the robot using Denavit–Hartenberg (DH) parameters.
  • Derive forward kinematics symbolically.
  • Implement inverse kinematics using matrix-based transformations.
  • Separate hardware abstraction cleanly from geometric modelling.

This would make the system more scalable, mathematically elegant, and computationally efficient — particularly if extended beyond two degrees of freedom.

At the time, however, the circle-intersection method was intuitive and grounded in geometry I understood deeply. And that mattered.


Why This Project Was Important

This wasn’t an industry-grade robot. It didn’t use high-end actuators. It even had Blu Tack in the structure. But it demonstrated that well-defined constraints and strong mathematical modelling can transform a mechanically imperfect system into a controllable and repeatable one.

That lesson — that control systems are as much about modelling assumptions as they are about hardware — has shaped how I now approach robotics, optimisation, and dynamic systems more broadly.

The full implementation is available on my GitHub.