PAROL6: a 3D-printed six-axis desktop arm you build from a BOM
BOM, STL files and instructions for PAROL6 3D printed robot arm
At a glance
- What is it?
- Source Robotics publishes the STL files, bill of materials, assembly instructions and control firmware for the PAROL6 desktop arm under GPLv3. This review covers what the repository actually contains, how to get from parts to a moving robot, and where the project stops short.
- Who is it for?
- Adopt PAROL6 if you want a six-axis arm whose mechanical design, firmware and Python API you can read and modify, and you are willing to source parts against the BOM and assemble the machine yourself. Do not adopt it if you need a validated industrial cell, a warranty, or a robot that arrives assembled and safety-rated; the README states the project is still under development and that you build and operate it at your own risk.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What PAROL6 is, and who the repository is written for
PAROL6 is a six-axis desktop robot arm whose structural parts are 3D printed. The README describes the design goal plainly: to be similar to industrial robots in mechanical design, control software and usability. That sentence sets the audience. This is not a toy kit with a sealed controller. It is a machine you fabricate, wire and commission, and the repository is organised around that process.
The top level of the repository tells you what kind of project it is before you read a word of documentation. There is a BOM directory, a Building instructions directory, an STL directory, a Print table, a URDF directory, and two firmware directories for the control board. There is also a SAFETY_WARNING_AND_DISCLAIMER.md file sitting at the root, next to the licence. The repository is a manufacturing package, not a library.
That matters for who should read it. If you are an engineer who wants to inspect the kinematics, print the links, populate a board and drive the arm from Python, the repository gives you the raw material. If you want a robot that arrives calibrated in a crate, the README points you at the shop instead, and the rest of this page is mostly irrelevant to you.
How the build path is structured: BOM, instructions, STL, firmware
The README gives a three-step path for anyone sourcing parts themselves. First, source all the parts from the BOM. Second, follow the building instructions to assemble the robot. Third, follow the documentation site to get the robot up and running. Each step is a separate directory or site, and the README links to each one rather than duplicating content.
The separation is deliberate and it has a consequence. The repository holds mechanical artefacts (STL files, a print table, a URDF model) and electronics artefacts (the control board main software and the control board test code). The BOM is the bridge between them, because it is the only place where printed parts, purchased parts and electronics meet in one list. If a part is discontinued, the BOM is where you find out, not the STL directory.
The URDF directory is worth noting for a different reason. A URDF model means the arm can be represented in a robotics toolchain without the physical machine present. The README's badge credits the Robotics Toolbox, and there is a separate ROS2 and MoveIt simulation repository listed under resources. Simulation is therefore a first-class part of the project, not an afterthought bolted on after assembly.
What the README does not do is estimate build time, list tooling, or tell you how many printed parts the arm contains. Those details live in the BOM and the building instructions, which is where you should look before committing to the build.
Installing the software side and getting a first motion
The repository you are reading is the hardware and documentation package. The control software lives in a separate repository, PAROL-commander-software, and the README links to a file there called confirmed_working_systems.md, flagged in the README itself as the minimum hardware specification. Check that file before assuming your laptop will run the commander.
For programmatic control there is a dedicated Python API repository. The README lists it alongside a legacy API repository, which tells you the interface has been reworked at least once and that older examples you find online may target the previous version. The README does not document the API's function names, so the following is only the shape of the workflow, not a runnable script:
# Clone the Python API repository listed in the README resources section
# then follow its own README for setup, because this repo does not document the APIWhat the README does give you is the order of operations for a first run: assemble the robot from the BOM and building instructions, then follow the documentation site to get it running. The documentation site is the only place the README points to for commissioning. There is no quickstart in this repository, and the README does not describe a simulation-only path for people who have not built the hardware yet, even though a URDF and a separate ROS2 and MoveIt repository exist.
If you want a web interface instead of the desktop commander, the README lists PAROL-Web-Commander as an alternative built by a community member, not by Source Robotics. Treat its documentation as separate from the official path.
The safety position is unusually blunt, and you should read it as a design constraint
Most open hardware repositories bury risk in a paragraph. This one puts a full disclaimer in the README and a separate file at the root. The README states that the project includes experimental software, hardware designs and assembly documentation that are still under development and may contain bugs, errors or incomplete features. It states that you use the project entirely at your own risk and that hardware performance and safety depend on user assembly, component quality, calibration and handling, which cannot be guaranteed.
The disclaimer also says the project involves lethal voltages. That single sentence changes the category of the project. A 3D-printed arm that runs on low-voltage hobby servos is a weekend project. A machine with lethal voltages inside a printed enclosure, assembled by the end user, is a different risk class, and the repository says so before it says anything about features.
Read this as an honest statement of where the project sits rather than as marketing hedging. The README instructs you to read the full safety warning and disclaimer document before using any project files, and it says proceeding means you accept all risks. That is about as clear as open hardware documentation gets. It also means the project is a poor fit for any setting where a formal risk assessment has to be signed off by someone other than the builder.
Where PAROL6 is the wrong tool
The most obvious limitation is that nothing here is certified. The README makes no claim about correctness, safety or reliability, and explicitly disclaims warranties including safety, reliability and suitability for any particular purpose. A production cell, a classroom with students who did not build the machine, or any application where a failure injures someone outside the build team is out of scope. The disclaimer is not boilerplate you can skim past; it is the project telling you which uses it will not stand behind.
The second limitation is support surface. There is a Discord, a forum, a blog and a YouTube channel, but no commercial support contract mentioned in the README. If your arm misbehaves, the path is community channels plus your own debugging. For a hobbyist that is fine. For a lab that needs a machine running next week, it is a real cost.
The third is documentation spread. The README, the documentation site, the commander repository, the Python API repository, the ROS2 repository and the community projects file are six separate places. The README does not consolidate them, and it does not state which of them is authoritative when they disagree. Expect to keep several browser tabs open, and expect the answer to a question to depend on which repository you landed in first.
Finally, the README does not document a rollback or recovery procedure for a failed firmware flash, and it does not describe what happens if the control board software and the commander software are at different versions. Those are the questions to ask in the forum before you start flashing.
Alternatives, and the real difference in approach
The closest comparison inside this project's own ecosystem is the ROS2 and MoveIt simulation repository. That is not a competitor; it is a different entry point into the same arm. If your goal is motion planning research rather than a physical machine, starting there means you work with the URDF model and never touch the BOM, the STL files or the control board. The trade-off is that simulation tells you nothing about backlash, wiring, calibration or the assembly problems the building instructions exist to solve.
Outside the project, the meaningful alternative is a commercial desktop arm. The difference is not capability on paper, it is where the engineering work sits. A commercial arm arrives assembled, calibrated and supported, and you pay for that in money and in a closed design you cannot reprint or modify. PAROL6 inverts it: the mechanical design, the STL files, the control software and the GUI are open source under GPLv3, and you pay for that in assembly time, part sourcing and the absence of a warranty. The README's own framing supports this reading, since it offers both a shop link and a self-source path in the same section.
A second alternative is the community web commander, PAROL-Web-Commander. It is a different interface to the same hardware rather than a different robot, so it is only an alternative if your objection is specifically to the desktop commander application.
Licence, maintenance and what an upgrade costs you
The project is under GPLv3, and the README states this in a licensing section near the end. The practical implication for anyone embedding PAROL6 in a product is that GPLv3 is a copyleft licence: derivative works distributed to others generally have to be released under the same terms. That applies to the control software, the GUI and the STL files as distributed here. It does not automatically cover your own application code that merely talks to the arm over an API, but the boundary is a legal question, not an engineering one, and this article cannot give you legal advice. If you plan to sell a machine built from these files, talk to a lawyer before you ship.
On maintenance, the repository is not archived and the last push was on 2026-09-07, which is recent. The only listed release is V1, dated 2025-03-08. So there is active work in the repository, but the release history is thin: one tagged version across the project's life. Plan for the code to move between commits rather than between releases, and pin the commit you built against if reproducibility matters to you.
Upgrade cost is dominated by hardware, not software. Because the arm is printed and assembled by hand, a revised STL file or a changed BOM line can mean reprinting a link or re-sourcing a part, not running a package manager. The repository gives you a Print table and a URDF, which help, but the README does not document a migration path between hardware revisions. Treat each revision as a new build decision.
Editorial conclusion
Adopt PAROL6 if you want a six-axis arm whose mechanical design, firmware and Python API you can read and modify, and you are willing to source parts against the BOM and assemble the machine yourself. Do not adopt it if you need a validated industrial cell, a warranty, or a robot that arrives assembled and safety-rated; the README states the project is still under development and that you build and operate it at your own risk. Before buying anything, open the BOM directory and count how many line items you cannot source locally, then read SAFETY_WARNING_AND_DISCLAIMER.md in full, because the README says lethal voltages are involved and that the disclaimer must be read before any project file is used.
Frequently asked questions
Do I have to print and assemble the PAROL6 arm myself, or can I buy it assembled?
Both paths exist. The README links to the Source Robotics shop for buying the arm, and separately describes sourcing all parts from the BOM and following the building instructions to assemble your own.
Where does the PAROL6 control software live, and is it in the same repository as the STL files?
No. This repository holds the BOM, building instructions, STL files, print table, URDF and control board firmware. The commander software and the Python API are separate repositories that the README links to under its resources section.
Can I simulate the PAROL6 before building the hardware?
The repository includes a PAROL6_URDF directory, and the README lists a separate ROS2 and MoveIt simulation repository under resources. The README does not describe a simulation-only quickstart, so the setup steps come from those repositories rather than from this one.
Community notes