OpenArm Hardware: CAD data for a reproducible robot arm

A hardware repository whose centre of gravity is a Drive folder

The openarm_hardware repository describes itself as CAD data and information for manufacturing, and the readme is short enough that its structure is immediately visible.

The first thing a reader notices is that the actual design files are not in the repository. They are on Google Drive, in two separate folders, one for v2 and one for v1, each linked from the readme with a Drive folder URL.

The readme then states the relationship between the two sources of truth in unusually plain terms. GitHub Releases provide a .tar.gz snapshot of the files for each version. They are only mirrors of Google Drive. Google Drive is the source of truth. If something is missing or broken in a release, please refer to Google Drive.

That is a deliberate arrangement rather than an oversight, and the reason is practical. CAD files are binary, they are large, and they change as the design changes. Keeping them in a Drive folder means the design can be edited by several people without a merge conflict, and the release archive exists so that a version can be pinned and downloaded reproducibly.

The release history matches that model: 2.0.0 from 2026-09-09, 1.1.0 from 2025-11-19 and 1.0.1 from 2025-10-31. So the 2.0 design landed in September 2026 and the 1.x line ran through late 2025, and anyone who wants a frozen snapshot can take the tarball matching the tag.

The documentation lives in a third place. Specifications, BOM, and step-by-step assembly guides are published at docs.openarm.dev/hardware, and the readme points there rather than duplicating it. So there are three artefacts per version, the CAD files on Drive, a frozen archive in the releases, and the written documentation on the docs site, and each serves a different need.

What is in each version

The readme describes the contents of both drives, and the difference between the versions is more than a revision number.

The v2 drive contains three things. OpenArm 2.0 is the full assembly, with the STEP file, the BOM, and options such as the head camera. OpenArm Cell is an evaluation cell, with its own STEP file, BOM, jig, wiring, and integration with OpenArm 2.0. And OpenArm KER is another full assembly, with a STEP file, BOM, jig base, and electronics in the form of PCBs and cables.

So the current design is not one object but a small family: the arm itself, a cell around it for evaluation, and a variant with its own electronics and jig. The jig showing up in two of the three is the detail that tells you something about how the hardware is meant to be used, since a jig is the fixture that holds a part in place for assembly or for a repeatable test position, and having one for the cell and one for the KER means both are built and measured in a fixed setup.

The v1 drive is described more briefly, and the difference in format is informative. It holds STEP for the full assembly of the leader and follower arm, STL ready-to-print 3D models, attachments such as camera mounts and a PCB hub casing, and wiring diagrams for cable manufacturing.

Two things stand out when comparing them. The v1 drive separates printable meshes from the CAD, with a whole STL directory, while the v2 description mentions STEP and options but not a mesh set. And the v1 arm is described as a leader and follower arm, a two-part configuration, whereas the v2 items are named as single assemblies and a cell.

The attachments in v1, camera mounts and the PCB hub casing, are the kind of small part that a hardware project accumulates and that nobody documents centrally unless somebody does. Their presence as a named category, with the PCB hub casing in particular, suggests the project has been through a stage where the electronics needed somewhere to live and that somewhere was designed rather than improvised.

The licence, and what strongly reciprocal means for hardware

The licence is CERN Open Hardware Licence Version 2 - Strongly Reciprocal, with the text in LICENSE.txt and copyright 2025 Enactic, Inc.

That choice is worth understanding rather than treating as a formality, because the CERN-OHL family was written for hardware specifically and its conditions differ from a software licence in ways that are easy to get wrong.

The Strongly Reciprocal variant is the stricter of the two. Where the permissive variant asks you to make the licence available and to acknowledge the source, the reciprocal variant asks you to license your own modifications of the design under the same terms. In practice, if you take the OpenArm arm design, change the geometry and publish the result, you owe the public a licence on your modified design, which is the mechanism that keeps hardware improvements circulating rather than being absorbed into a closed product.

For an academic or research platform, which an open hardware arm with a published evaluation cell and a KER variant obviously is, that is the correct default. It means somebody building on the design cannot accidentally close it, and the cost to the builder is a licence obligation rather than a restriction on what they may build.

The repository also carries a CODE_OF_CONDUCT.md, and the readme states that all participation is governed by it. For a project where the contributions are physical things, that matters more than usual, because the conduct expectations apply to the people doing the manufacturing and the mechanical design work alongside the software people.

The primary language of the repository is recorded as Ruby, which is worth noting because there is no Ruby code visible in the readme. The top level holds .github/, CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE.txt, README.md and a dev/ directory, and the Ruby entry most likely reflects tooling rather than the design itself, which is a common pattern for repositories where the build or conversion scripts are written in a scripting language.

What contributors are asked to bring

The contributing section says contributions are welcome, and then lists three kinds of submission, and the list tells you what the project considers missing.

The first is custom modifications and improvements. The second is assembly files for other CAD platforms, with SolidWorks, OnShape and FreeCAD named explicitly. The third is documentation enhancements.

The second of those is the most revealing. The drive contains STEP files, which is the neutral interchange format, and STEP files are good for moving geometry between tools but they do not carry the parametric history. If you import a STEP file into SolidWorks or OnShape or FreeCAD, you get shapes, not a feature tree, and you cannot change a dimension and have everything downstream update. So a contributor who has rebuilt the arm natively in one of those tools and is willing to share the parametric assembly has something the STEP file genuinely cannot provide, and the project is asking for exactly that.

It also tells you something about the intended audience. Mentioning SolidWorks, OnShape and FreeCAD as the alternatives means the project expects people arriving from commercial CAD as well as from the open-source end, and it is trying to make the design usable in whatever tool the contributor actually has.

The documentation call is the other one, and given that the documentation is hosted separately at docs.openarm.dev/hardware, with specifications, BOM and step-by-step assembly guides, and the readme points contributors there rather than inlining the guides here.

For communication there is a Discord for questions and project sharing, and an email address at [email protected]. Two channels rather than one is a reasonable pattern for an open hardware project, where some questions are mechanical and some are about the electrical side or the assembly sequence.

How to actually get the files

Putting the pieces together, the path for someone who wants to build the hardware is short and worth stating plainly.

First decide which version you want. The v2 drive is the current design, with the 2.0 arm, the Cell and the KER. The v1 drive is the earlier leader and follower arm with its printable meshes and attachments. The readme does not give a compatibility or supersession note beyond the version numbers, so if you are following a specific build guide or working from a published paper, match the version in that document rather than assuming the newest drive is the right one.

Then choose your source. The Drive folder is the source of truth and always has the latest files. A GitHub release tarball gives you a frozen snapshot matching a tag, which is what you want for reproducibility or when you need to hand somebody a specific revision that will not change under you.

Then read the documentation on the docs site, because the CAD tells you the shape and the documentation tells you the assembly sequence, the BOM and the wiring. The STEP file alone is not a build instruction, and the BOM is a separate artefact from the assembly geometry.

For the parts themselves, note the difference in what each item includes. The Cell and the KER both ship a jig, which is the fixture you would need to hold parts in position, and the KER additionally includes PCBs and cables. The 2.0 arm includes options such as the head camera rather than a fixed camera, which implies a variant choice at build time.

The dev/ directory at the top level of the repository is the one place where something resembling tooling lives, and it is worth a look when you start, since it is likely to hold whatever converts or checks the design data. Beyond that, this is a repository whose job is to point you at the right files and get out of the way, and it does that job well.

Editorial conclusion

Adopt this repository if you want to build, print or modify the OpenArm hardware, since it holds the CAD and assembly data rather than a description of it. Do not expect a conventional software project here, because there is no library to install and the authoritative files live on Google Drive rather than in git. Before you commit, read the CERN-OHL-S-2.0 terms, because a strongly reciprocal hardware licence obliges you to publish derivatives of the design, and check which of the two drives, v1 or v2, matches the revision you actually want.

Frequently asked questions

Official sources

1. enactic/openarm_hardware on GitHub
2. Issues
3. License: CERN-OHL-S-2.0
4. README
5. Releases