moteus: an open brushless servo, from the PCB layout up

This is an actuator, and the warning comes first

The moteus repository contains full designs for the moteus brushless servo actuator, including firmware and PCBs. The project description reads: brushless DC motor controller.

The README then puts a warning in the first paragraph, and it is unusual enough to quote in substance. It says this is not just a software project. It includes designs for moderately high power electronics. It has not yet burned down my, or anyone's that I know of, house, but there are no guarantees.

That warning is the honest summary of the project. Most open source robotics repositories are a ROS package or a driver. This one contains the mechanical and electrical design of a device that moves a lot of current, which means the design decisions, the current ratings and the thermal limits are all part of the open material, and so is the risk of getting them wrong.

The alternative to building your own actuator is buying a commercial one, and the two paths differ in more than cost. A commercial servo gives you a tested unit with a datasheet and a warranty. The moteus path gives you the source, the firmware and the ability to change the behaviour, and it asks you to be the person who validates the electronics.

For a team building robots where the actuator has to do something nobody sells off the shelf, that trade is worth taking. For a team that just needs a joint to turn, it usually is not.

Four variants, and the numbers that separate them

The specification table covers four boards, and the differences between them are large enough that choosing the wrong one is expensive.

The r4.11 takes 10 to 44 volts and peaks at 900 W at 30 V. The c1 takes 10 to 51 V and peaks at 250 W at 28 V. The n1 takes 10 to 54 V and reaches 1.3 kW at 36 V, and the x1 takes the same voltage range and peaks at 1 kW at 36 V.

Mass follows a similar spread, with the c1 the lightest at 8.9 g, the r4.11 at 14.2 g, the n1 at 14.6 g and the x1 at 23.8 g. Dimensions range from the flat 38 by 38 by 9 mm of the c1 through the 46 by 46 by 8 mm of the n1 to the 56 by 56 by 10 mm of the x1, with the r4.11 at 46 by 53 mm.

The current ratings are the ones to plan a power supply around. Uncooled phase current runs from 5 A on the c1 to 25 A on the x1, cooled phase current from 14 A to 62 A, and peak phase current from 20 A on the c1 to 100 A on the r4.11 and 120 A on the x1. Those are phase currents in a three phase machine, and the peak figure is what your supply has to survive for the fraction of a second a hard move takes.

Only the r4.11 row carries the timing and communications figures in the table: a control rate of 15 to 30 kHz, a PWM switching rate of 15 to 60 kHz, an STM32G4 CPU, and 5 Mbps CAN-FD communications.

hw, fw, lib and utils are the layers you will actually touch

The directory structure is the clearest statement of the project's scope, and it is worth reading before anything else.

hw/ - hardware (mechanical and electrical designs)
fw/ - firmware for brushless controller
lib/ - client side software
utils/ - diagnostic tools
tools/ - bazel build configure
docs/ - documentation

hw/ holds the hardware, and it has one subdirectory per board: controller/ for the moteus-r4.11 PCB design, c1/, n1/ and x1/ for the others. So the electrical and mechanical design of each variant is in the repository, which is what makes the open source claim mean something beyond the firmware.

fw/ is the firmware for the brushless controller, which is the part that has to be right about current control, timing and fault handling.

lib/ is the client side software, and this is where the release tags tell you what languages are in play. The recent tags are rust/v0.5.5 and rust/v0.5.4, both from 2026-09-04, and python/v1.1.1 from 2026-08-04. The version numbers are per language, tagged with a rust/ or python/ prefix, which tells you the client libraries are versioned independently of the hardware designs.

utils/ holds diagnostic tools, which is the part an integrator will appreciate most, because a servo that is not behaving needs to be interrogated. tools/ is the Bazel build configuration, and docs/ is the documentation, with a mkdocs.yml at the root and a requirements-docs.txt for building the site.

The 5 Mbps CAN-FD link is what carries all of this to the host, and it is why a project with open firmware also ships a client library in two languages: the host that commands the actuators is likely to be a Linux box running Rust or a Python robotics stack.

The build is Bazel with a CMake escape hatch

The repository is not a conventional application project, and the build arrangement shows it. At the root there is a BUILD file, a WORKSPACE file, a .bazelrc and a .bazelignore, which is the Bazel workspace layout, and the tools/ directory is described in the README as the bazel build configure. There is also a CMakeLists.txt, a configs/ directory and a travis-ci.sh, so a CMake path exists alongside Bazel.

There is a .eslintrc.js at the root, which is a small detail that says something about the client side: the JavaScript tooling is part of the same repository rather than a separate project.

The documentation has its own build. There is a mkdocs.yml and a requirements-docs.txt, and the published site is at mjbots.github.io/moteus, with a quick start page at mjbots.github.io/moteus/quick-start, plus a Discord for support. There is also a CHANGELOG.md, a RELEASING.md, and a CLAUDE.md in the tree, which is the file an automated coding assistant is pointed at, alongside the GitHub Actions workflow that the CI status badge refers to.

For a newcomer, the practical route is the quick start page and the Discord rather than the build system. The Bazel configuration exists so that the firmware, the client libraries and the hardware design files can be built and tested together, which is the same reason the hardware sits in the same tree as the code.

Support runs through the shop that sells the boards

The README has a section on how to support moteus development, and it is unusually blunt about the model.

The easiest way to support development of the moteus hardware and firmware is, first, to buy things from mjbots.com, and second, to build awesome machines. That is it. If for some reason you want to go above and beyond, you can sponsor mjbots through GitHub.

This is a small company selling assembled and tested boards, and the open repository is the research and development surface for the product. The relationship is the reverse of the usual open source arrangement. Rather than the community funding the development of a product, the customers fund it by buying the product, and the designs are published anyway.

For an adopter this has a practical consequence worth stating plainly. You can buy a working unit and use the client library against it, and the hardware design is available if you want to make your own. What is not available is a guarantee that a hobby-built board will behave like a factory-assembled one, because the factory units are assembled and tested by the people who designed them, and the README does not claim otherwise.

The documentation site, the quick start guide and the Discord are the places where that distinction gets resolved in practice.

Apache-2.0 for the files, a trademark for the names

All files contained in this repository, unless otherwise noted, are available under an Apache 2.0 License. The LICENSE file is at the root, and the licence is the permissive one with the patent grant, which is a sensible choice for hardware designs that a third party might want to manufacture.

The trademark position is separate and just as important. mjbots Robotic Systems LLC owns and protects the mjbots and moteus trademarks in many jurisdictions, and if you want to use these names in your project or product, the README says to read the Trademark Policy on the mjbots site.

So there are two separate permissions here. You may take the electrical designs, the mechanical designs, the firmware and the client libraries and build your own servo, subject to the Apache 2.0 terms and the notice requirements. You may not, without permission, call your product a moteus or put the mjbots name on it.

That split is common in hardware that is open but commercially manufactured, and it is the reason the trademark paragraph is in the README at all rather than buried in a legal folder. For most integrators it never comes up, because nobody names their robot after the servo. It comes up for a reseller or a second source manufacturer, and the answer there is to read the policy before printing anything.

Editorial conclusion

moteus fits a robotics engineer who wants a commercially available, well specified brushless actuator with open firmware and client libraries, and who is prepared to work at the hardware level. It does not fit someone who wants a library to call, because the client software is the small part of the repository, and the electrical designs carry the risk the README explicitly warns about. Before you design a board around it, read the specification table for the exact variant, and check the Trademark Policy if you intend to put the moteus name on your own product.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mjbots/moteus on GitHub
3. Project website
4. README
5. Releases