This is an Annin Robotics AR4 MK3 — open-source hardware,
CAD and firmware and robot description all published. Every number in the
kinematics is transcribed from its
MIT-licensed
ROS 2 description package: the joint origins and axes from
ar_macro.xacro, the travel limits and l6_length from
config/mk3.yaml, the two-jaw gripper from
ar_gripper_macro.xacro.
| joint | travel | offset from the previous joint |
|---|---|---|
| 1 | ±170° | at the base, about the column |
| 2 | −42…+90° | 64 mm out, 170 mm up — the shoulder |
| 3 | −89…+52° | 305 mm — the upper arm |
| 4 | ±180° | coincident with 3 — forearm roll |
| 5 | ±105° | 223 mm — the forearm |
| 6 | ±180° | 41 mm — the wrist |
All six are limited to 1.0472 rad/s, which is 60 °/s,
exactly as the URDF has it. The selftest checks the joint table field for
field against those files, checks that the chain composes the way URDF
specifies (<origin> first, then rotation about
<axis>), and checks that the tool can never reach beyond the
sum of the link lengths — 0.800 m, which is the norms of the joint
offsets, not their z components.
What is not transcribed: the shells. The AR4's real STL meshes are megabytes and this page ships as a static asset with no build step, so the links are drawn as machined housings spanning the true joint origins. Change the transcription and the arm on screen changes shape, because the drawing reads the kinematics rather than repeating them.
Six joints, four keys — so driving joints directly is off the table. But that is not how anyone operates an industrial arm anyway: you teach it poses and play them back. A teach pendant records a handful of joint configurations and the program walks between them. You are the program.
The three poses were solved on the real chain, not hand-set — each is the joint vector that puts the tool centre point at the named place with the gripper pointing straight down, found by search inside the AR4's real joint limits. They are stored as joint angles, because that is what the arm stores.
A joint-space move does not travel in a straight line, and the joints are not time-synchronised — each runs at up to 60 °/s and arrives when it arrives. Measured on the real chain:
| route | time | sideways travel at part height |
|---|---|---|
| Q → O | 0.82 s | 200 mm |
| Q → W → O | 1.38 s | 1 mm |
The shortcut saves 40% of the time, and it saves it by coming in sideways across the belt at pick height — straight through the line of parts. The approach pose turns the final leg into a vertical descent. Flown against a full line, going straight in scatters 1.75 parts a trip against 0.63.
None of that is a rule bolted on to make a game. It is why approach waypoints exist in real robot programs, it falls out of the AR4's own joint geometry, and the selftest measures it rather than asserting it.
The jaws take 0.22 s to close and the line runs at 105 mm/s, so a part travels 23 mm during the close — further than the grasp radius. You cannot close when the part is under the tool; you have to close before it gets there. That was not designed in, it fell out of the numbers, and the selftest found it: a test controller that gripped only while the part was dead centre never picked anything up, because the jaws reopened as it drifted.
The arm, its limits and its speeds are the AR4's. The cell around it is ours: the belt speed, the part spacing, how often a reject comes past, what counts as scrap. There is no dynamics here — no torque, no payload, no compliance — the joints simply move at their rate limit, which is what a position-controlled arm looks like from outside and is not what one feels like from inside.
Same four keys as /qwop/, /graze/, /qgol/, /griddle/, /mimic/ and /pong/. Rendering is three.js r169 (MIT), vendored — no CDN, nothing fetched at runtime.