ArmControl –
I brought a robot arm to life

The arm, operated in the browser

The same inverse kinematics as in the real software: a target is set, the computer works out the joint angles. Dragging with finger or mouse rotates the view; the arm is controlled with sliders and buttons. No server, no installation – everything runs live.

From kit to real control system

The kit's original software was a simple remote control. I rebuilt everything – firmware and PC software – so that the arm really does what it is supposed to do.

The stack

Deliberately kept lean: runs locally, without a cloud, without heavy dependencies.

All connections at a glance

The heart is an Arduino Mega 2560 with a RAMPS 1.4 shield – the classic platform for motor control. Three stepper motors drive the joints, a fourth the linear rail. Special feature: on the rotary axis an optical light barrier sits instead of a mechanical limit switch, so that the axis can safely spin through if in doubt.

Inverse kinematics – how the arm “knows” where to go

I want to specify a point in space – and the arm should set its joints to match by itself. That is inverse kinematics. The arm is a classic two-joint chain on a turntable, which means it can be solved exactly in closed form.

Conversely, forward kinematics calculates the actual position back from measured joint angles – so the 3D view always knows where the arm really is. I checked both directions against each other: the back-calculation agrees to within less than a thousandth of a millimetre.

Technical manual

From installation to the first program – in a compact summary.

Command reference (G-code)

The complete guide, including calibration, comes with the download as the FIRMWARE_ANLEITUNG.md and LIESMICH.md files.

The arm in different poses

From the 3D simulation – this is how every joint position is shown live.

Inverse kinematics, the core

The three joint angles are calculated from a target point in space – classic two-joint trigonometry plus base rotation.

def ik(x, y, z, geo):
    # Cartesian -> joint angles (returns: angles or None)
    a, b = geo["lower_arm"], geo["upper_arm"]
    base = math.degrees(math.atan2(x, y))            # base rotation
    r  = math.hypot(x, y) - geo["tool_offset_h"]     # reach
    zz = z - geo["base_height"]                     # height above shoulder
    d  = math.hypot(r, zz)
    if d > a + b or d < abs(a - b):
        return None                                 # unreachable
    q2       = math.acos((a*a + d*d - b*b) / (2*a*d))
    shoulder = math.atan2(zz, r) + q2                # lower arm
    elbow    = math.acos((a*a + b*b - d*d) / (2*a*b))
    upper    = shoulder + elbow - math.pi            # upper arm, absolute
    return {"z": base, "y": deg(shoulder), "x": deg(upper)}

Which axis is which?

X, Y and Z mean different things in two places here – as a coordinate in space and as a joint name in G-code. This is the most common stumbling block when working with the arm. Clicking a row highlights the axis.

Why a straight line takes computation

Two points with a straight line between them – obvious for a human, not for an articulated arm. If the joints are simply moved evenly from start to target angles, the tip describes an arc. For a true straight line, the path has to be broken down into small steps and the inverse kinematics calculated for each and every one of them – which is exactly what move_cart(linear=True) does in the software, with cart_step as the step size.

Contact

Questions about the construction, the decisions behind it or how it could carry over to another case.

Website

Name Email

Message

Arithmetic check

Different task Result

I agree that my details may be stored and processed in order to handle this enquiry. I can withdraw this consent at any time. More in the privacy notice.

Send message

No Google captcha, no cookies, nothing passed to third parties. Prefer e-mail? info@timobritz.de.