Project Quiver: an open hardware quadcopter platform under the CERN licence

A platform, not a product, and the numbers that define it

Project Quiver is an open-source, modular quadcopter platform for developers and operators, developed by Arrow Air and released under the CERN Open Hardware Licence.

The headline specifications are concrete. It is a 25 kg maximum take-off weight drone with 5 to 8 kg of payload capacity, three hot-swappable attachment interfaces, and a distributed electronics architecture. The stated design goals are reliability, field serviceability and customization, and the word distributed is doing real work there, because it comes with the four-board detail below.

The feature list spells out the rest. A modular payload system with three quick-release interfaces, on the bottom, the left and the right, for mission equipment. Dual GNSS with RTK for centimetre-level positioning with backup redundancy. A distributed PCB architecture of four custom boards that can be individually serviced. A 25 to 31 minute hover endurance on a Tattu 14S 30Ah smart battery with Hobbywing X6 Plus propulsion. ArduPilot firmware with standard QGroundControl and Mission Planner compatibility. And a weatherproof design with a sealed cockpit, rain canopies and drip-proof geometry.

The licence choice is the part with the widest consequences. The CERN Open Hardware Licence is a hardware licence, which means the design files themselves carry terms rather than being a free-for-all or governed by software copyright. In practice it is the licence that lets someone else build the aircraft, or a payload for it, without having to ask.

The design is not new in the sense of being finished. The README itself points to a photo of Project Quiver PT3, and the repository has a flight-test/ directory described as historical flight test logs, which tells you the platform has been through iteration and the artefacts reflect that.

What is actually in the repository, and what is not

The repository structure is the fastest way to understand what kind of project this is:

project-quiver/
├── docs/                    # Documentation (hosted at arrowair.com/quiver)
├── src/
│   ├── quiver/              # CAD assembly — build123d Python package
│   ├── pcb/                 # KiCad PCB designs (4 custom boards)
│   ├── printing/            # 3D print profiles and settings
│   └── manufacturing/       # DXFs and cut sheets for CNC/laser
├── flight-test/             # Historical flight test logs
└── task-grant-bounty/       # Bounty and grant task specifications

What is absent matters as much as what is present. There is no flight controller firmware here, because the platform uses ArduPilot, which is a separate and well-known project. There is no GCS either, since QGroundControl and Mission Planner are the stated ground stations. This is a hardware and documentation repository, not a software one.

The CAD source is the most interesting engineering decision. It is a build123d Python package that composes STEP files into the full drone assembly, and the stated purpose is to enable programmatic CAD generation and version-controlled mechanical design. That is a significant choice. Conventional mechanical work happens in a CAD tool's binary file, which is awkward to review and impossible to diff meaningfully. Putting the parametric model in a Python package means the assembly can be generated, the geometry can be versioned in Git, and a change to a dimension is a pull request rather than a binary blob replacement.

Alongside that sits the manufacturing output, with DXFs and cut sheets for CNC and laser, and 3D print profiles and settings, so the path from a parametric model to a physical part is in the same tree.

The task-grant-bounty/ directory is the least conventional part. It holds bounty and grant task specifications, and the README points at two specific information notes, one listing possible attachments and one giving the detailed attachment requirement for the bounty. The model is that the platform needs payloads, the maintainers want proposals rather than unsolicited code, and the funding is attached to the task.

Three ways to engage, from building to attaching a payload

The getting started section branches by what you actually want to do, and the branching is more informative than a single install command would be.

If you want to build one, you start with the assembly guides on the project site, under the manufacturing category, which are described as step-by-step build instructions. If you want to develop attachments, you are pointed at the two bounty information notes in the repository, the possible attachment list and the priority attachment requirements. And if you want a dev-kit, the README says dev-kit drones are available for loan to developers with promising projects, and to join the Arrow Discord to learn more.

That last option is the one that changes the shape of the project. A 25 kg aircraft with 5 to 8 kg of payload capacity is not something most people can source, so a lending programme is what makes the platform accessible to the developers it is aimed at. It also means the priorities are set by whoever runs the lending programme, which is why the bounty task specifications exist in a machine-readable form.

The documentation is organised by audience, with three categories listed. Assembly guides sit under manufacturing, engineering reports under reference and engineering reports, described as technical details for each prototype, and the meeting notes live in the project wiki, containing engineering call notes.

Separately, there is a flight tracking site at project-flight-tracking.vercel.app, plus a DAO forum at dao.arrowair.com and the Discord server. The DAO wording is worth noting, because a project with a forum, a flight tracker and a bounty system has a governance structure rather than a single maintainer pushing commits.

The contributions the project wants are listed by discipline: attachments, meaning new payloads for the modular interfaces, electronics, meaning PCB improvements and new sensor integrations, mechanical, meaning structural design and manufacturing optimization, software, covering ArduPilot configs, companion computer features and tooling, and documentation, including guides, tutorials and translations.

A repository that is mostly a documentation site, with the checks to keep it honest

The top level of the repository shows a project that has moved beyond a hardware dump and started treating its documentation as a product.

The docs/ directory is hosted on the Arrow website, at arrowair.com/quiver, and the README links the full documentation there as a platform overview with capabilities and a roadmap. The bom/ directory holds the bill of materials, the kind of file a hardware project publishes so that anyone rebuilding it knows exactly what is in the original.

Then there is the infrastructure. A .make/ directory holds the included make fragments, and the Makefile in the repository root is short and marked DO NOT EDIT, with a comment saying the file was provisioned by Terraform and giving the origin as a template in the Arrow-air tf-github repository. That is a slightly unusual arrangement, and it tells you the build tasks for the documentation are themselves managed as code in another repository, so a change to how the checks run is reviewed the same way as a change to the drone would be.

The tasks themselves are linting checks rather than a compile. The test target depends on cspell-test, md-test-links and editorconfig-test, and the help target lists the same set. So a pull request that changes the documentation is checked for spelling, for broken links and for editorconfig conformance, and nothing else. There is no build of the CAD in the default path, which is consistent with a repository whose main artefact is a website.

The rest of the top level is ordinary hygiene: a .commitlintrc.yml for commit message format, a .cspell.config.yaml with a .cspell.project-words.txt for the domain vocabulary, an .editorconfig with an .editorconfig-checker.json, a .link-checker.config.json, a .terraform_init file, a .vscode/ directory, CODE_OF_CONDUCT.md, CONTRIBUTING.md, a SECURITY.md, and a .github/ directory for the workflows.

The last push was on 2026-10-19 and the default branch is main, so the repository is actively maintained even though it produces no releases.

Editorial conclusion

Project Quiver suits a developer or operator who wants to build or adapt a heavy-lift multirotor and needs the mechanical design and electronics to be reusable rather than a black box, and the CERN licence is what makes that reuse explicit. It does not suit you if you want a ready-to-fly aircraft or a firmware project, because there is no flight software here beyond ArduPilot configuration. Before you start, read the assembly guides on the project site, since the repository is documentation and artefacts rather than a build you can run, and check the bounty task specifications in the task-grant-bounty directory if you are looking for a way to contribute rather than to build.

Frequently asked questions

Official sources

1. Arrow-air/project-quiver on GitHub
2. Issues
3. License: CERN-OHL-S-2.0
4. README