Arctos Robot Arm
Open-source hardware, my control stack
IN MOTION
A full pick-and-place cycle
The arm running a complete cycle under its own solver — approach, close, lift, traverse, release. Nothing here is teach-and-repeat: each pose is a Cartesian target that the damped-least-squares solver turns into six joint angles, checked against measured limits before a single step is sent.
- Sped up for the clip — the arm runs this slower in reality.
- A target outside the measured joint envelope is refused, not approximated.
- The wrist stays gated in software until its axis naming is verified against the hardware.
A six-axis arm built from the open-source Arctos design. The mechanics are theirs and published; everything that computes is mine. What I took from upstream was geometry — link lengths and joint-axis directions, transcribed from the community URDF and cross-checked against the official DH table, which agreed to within a third of a millimeter. That is data, not code.
Forward kinematics is about forty lines of numpy evaluating that chain. Inverse kinematics is a damped-least-squares solver I wrote myself. The plan had been to bolt on a library; the reason I didn't is that the solvers worth using drag in ROS or heavy dependencies that fight Windows and Python 3.14 — and a solver I own can be taught this machine's actual truths instead of the document's. J3's sign is flipped from what the docs say, and I found that with a tape measure. The tool point sits 9.5 cm out, fit from my own measurements. My measured joint limits rule the solver, not the published ones.
The safety behavior is the part I would defend hardest. On 14 August the second joint reached its commanded angle, then drove 111° the other way into its own end stop. The clamp that should have caught it can only bound an axis it has a counts-per-degree scale for, and its plausibility gate accepted 50 to 5,000 — which silently rejected J2 at −6,983 and J3 at −7,030. The two axes that kept running away were exactly the two the clamp was blind to.
That is why the investigation folder opens with a rule: never assert a number I have not measured. It also cost three days to a unit error — one position count is 0.01 motor-degree, not 1/16384 of a revolution — which became obvious the moment I checked the suspicious ratio against every axis instead of only the one that looked strange. A constant factor on all four axes is a unit mistake, not a mechanical one.
HOW IT WENT
- 01
Measure
Encoder scales taken off the drivers, not read off a datasheet
- 02
Solve
Forward kinematics in numpy, inverse by damped least squares
- 03
Constrain
Measured joint limits and a refuse-don't-guess gate on every move
- 04
Investigate
One written file per incident, with the raw frames decoded
Need a part scanned, modeled, or built?
SEE SERVICES →