Microban: a 30cm humanoid you can print at a desk and drive with a gamepad

Why a 30cm robot with 19 axes is a deliberate choice

Microban is roughly 30 centimeters tall, which the README calls a compact desktop companion. That size is not an accident of shrink-fitting a larger design. It is what makes the robot printable on a standard desktop FDM printer, printable with PLA, and light enough to move around a desk while still having enough axes to do interesting things with its whole body.

The degree of freedom count is 19, and the README names them as such in the CAD section. That matches the bill of materials, which lists 19 Dynamixel XL330-M288-T servomotors. A compact serial bus servo rather than a hobby-grade PWM servo is what makes 19 axes practical: the servos carry their own controller, report position and load back over the bus, and each one gets an addressable ID. On a 30cm frame with 19 joints, wiring each servo separately would be the dominant cost in both cable volume and assembly time.

The rest of the bill of materials is short by robotics standards. There are roughly 30 printed parts, one Raspberry Pi Zero 2W, a Pollen RPI Robot Hat, two 18650 cells with a holder and a battery management system, a USB-C charger, about 200 plastic screws, and 12 steel and POM shims used as an alternative to needle bearings on motors that lack idler horns. The README states a total cost in the range of 550 to 600 dollars, and it points out that the Dynamixels may have to come from specific distributors depending on where you live, which is the main reason a real build can land outside that range.

The design also handles the practical things that a parts list does not show. The README says stops are integrated into the design to control which self-collisions are likely to occur, and that cable routing for the servos was taken into account so wires stay out of the range of motion. Those two sentences are the difference between a robot that assembles and one that jams on its third joint.

Two licenses for two very different kinds of asset

Microban is licensed in layers, and GitHub cannot parse that into a single field, so the repository reports no license while the README carries two badges.

The software badge declares GPLv3. The hardware badge declares Creative Commons Attribution-NonCommercial-ShareAlike 4.0. That split is the interesting part: the GPL governs the code you run on the Pi, and the CC license governs the CAD files and printed geometry. The non-commercial clause in the second one matters if you were planning to sell a Microban you built, because ShareAlike plus NonCommercial on the mechanical design is a real constraint on what you can do with a product derived from it.

A LICENSE file does exist at the repository root, so the licensing intent is recorded somewhere concrete even though the hosting side does not detect a single SPDX identifier for a project that is deliberately dual-licensed.

There is a second licensing detail worth knowing about. The README declares a DOI badge for citation, and the badge image reads 10.5281/zenodo.18470949 while the link behind it points at zenodo.20784789. Both are Zenodo identifiers and the intent is clearly to cite the project archive, but they are not the same record. If you need the archive for a paper or a thesis, resolve the DOI that the link actually targets rather than transcribing the number printed on the badge, and confirm with the authors which deposit is the canonical one.

The repository is documentation first and Python second

The tree is small: a cad directory, a docs directory, a src directory, a systemd directory, a Makefile, a pyproject.toml, a CITATION.cff, a LICENSE, and the README. Reading it as a software project would lead you to expect a large package. Reading it as a hardware project gives you the right expectation, which is that the value is in the documentation and the CAD files and the software is a thin driver on top.

The documentation directory carries the four guides the build actually depends on. docs/bom.md is the detailed bill of materials with purchase links and prices. docs/printing.md covers how to orient and print each part. docs/assembly.md is the step by step mechanical build. docs/deployment.md covers getting software onto the Pi Zero 2W, and docs/usage.md covers running the robot, driving it with a keyboard or a gamepad, and adding your own moves.

The printing guidance is specific enough to be useful rather than generic. The README recommends PLA at a 0.12mm layer height and 15 percent infill, and it warns that some parts need particular orientations to get strength and fit right. That warning is the difference between a working robot and a bucket of failed prints, and it is the reason printing.md is linked rather than summarized.

Printable geometry comes in two formats under the cad directory, STL for slicing and STEP for opening in a CAD tool, plus an interactive Onshape assembly linked from the README so you can walk through how the parts fit before committing an evening of filament. The 19 degrees of freedom are laid out in that assembly, which makes it the fastest way to understand the kinematic design.

The CITATION.cff file at the root is a small signal about intent. It is how you cite the project if a paper or a thesis needs to reference the design rather than the vendor's servos.

The Makefile is the entire developer interface

All software interaction with Microban goes through make. The Makefile sets a default host name of microban and an empty ID, then defines targets that shell out over SSH to that host. Nothing in it runs locally except the two simulation targets.

The sync target is an rsync of the working directory to the robot, excluding the directories you do not want on a Pi Zero. Note which ones those are: cad and docs are excluded because they are large and useless on the device, and src/sim, src/debug, and src/model/mjcf are excluded because the simulation half of the tree is not what the robot runs.

sim:
	PYTHONPATH=src uv run --group sim src/sim/sim_main.py --hz 50

viewer:
	PYTHONPATH=src uv run src/sim/viewer_main.py --hz 25

Those two targets are the part of the project you can use before you own any hardware, and they are the reason the Python dependency list exists at all. The simulation group pulls in MuJoCo and better-actuator-models, which means the joint model is simulated rather than guessed, so a control loop you tune in simulation has a real chance of transferring to the physical robot.

Everything else targets the device. setup syncs and then runs uv sync with the frozen flag on the host. run and stop invoke src/main.py and src/stop.py on the Pi. voltage takes the ID variable and calls src/voltage.py for a named servo, which is how you check whether a specific joint is drawing what it should. imu calls src/imu.py for the onboard inertial unit. shutdown powers the machine down.

setup: sync
	ssh $(HOST) "bash -l -c 'cd microban && uv sync --frozen'"

There is one feature in the Makefile worth reading twice, because it changes how you interact with the robot day to day. The gamepad-headless-enable target installs a systemd service from the systemd directory so the control loop launches by itself when the gamepad START button is held for two seconds, with no SSH session involved, and the gamepad B button stops it again. gamepad-headless-disable uninstalls it. In other words the project ships a path to running without a terminal attached, which is what you need before the robot can be walked away from.

Five Python dependencies and a version number that trails the releases

pyproject.toml is tiny and worth reading in full, because it tells you more about the software's real scope than the language badge on the repository does. GitHub reports the language as Python, and the whole runtime is five dependencies: numpy, onnxruntime at 1.26.0 or newer, placo at 0.9.23 or newer, pollen_bmi088_imu_library pinned to 1.0.0rc1, and rustypot at 1.4.2 or newer. Python 3.12 or newer is required.

Those packages tell you what the software does. placo is the Rhoban inverse kinematics library, which is where whole-body motion on a 19 axis humanoid gets solved. rustypot is the servo bus layer, so the Dynamixels are reached through it rather than through custom register poking. pollen_bmi088_imu_library handles the inertial measurement unit on the Pollen hat. onnxruntime means a learned component runs on the device, most likely a small policy rather than a hand-written controller.

There is also a tool.uv section that overrides numpy to 2.3 or newer, which tells you the project manages dependencies with uv and has already resolved the numpy 2.x compatibility question for itself.

The version field is where the repository disagrees with its own release history. pyproject.toml says version 0.0.2. The releases tab carries three tags: v0.1.1 and v1.0.0 both published on 2026-07-06 along with an image.v2 tag whose name suggests container or model imagery rather than a source release. None of the three release bodies carry notes.

Both facts are true and they point in opposite directions. The package version looks like an unmaintained placeholder, which is common for a project where the real unit of release is the CAD revision and the robot image rather than a library on an index. If you are pinning Microban in an environment, do not rely on the pyproject version to tell you which hardware revision you have. Pin a git revision, read the CAD commit date, and confirm against the documentation that the geometry matches the servos you ordered.

How the project asks you to participate

Two parts of the README are about the community rather than the robot, and both point at GitHub Discussions rather than an issue tracker. There is a Q and A section for problems encountered while sourcing components, printing parts, or assembling, and a Show and Tell section for people who have built their own Microban. There is also a General Discussions category for ideas that are not yet hardware.

The contribution guidance is deliberately broad. Designing a new head, writing code, and fixing typos in the documentation are all listed as welcome, and the README asks contributors to fork and open a pull request. For a project whose stated philosophy is that users modify and share their versions, that is the mechanism that makes the fork culture work.

Marc Duclusaud created Microban as a member of the Rhoban team at LaBRI, University of Bordeaux, and the repository sits under the Rhoban organization. That matters more than it looks: Rhoban is the group behind placo, one of the dependencies, so the kinematics solver and the robot that uses it come from the same research group. The YouTube video linked from the README shows the robot taking its first steps, and the repository had 440 stars at the time of this review with the topics diy, electronics, engineering, humanoid-robot, and robotics. The last push was 2026-09-10.

If you are deciding whether to build one, the practical test is the bill of materials and the printing guide rather than the video. Read docs/bom.md against the distributors actually available to you, check whether the Dynamixel XL330-M288-T ships to your region at the price you expect, and read printing.md for the parts that need specific orientations. Those two documents will tell you in twenty minutes whether this is your weekend project or your semester project.

Editorial conclusion

Microban is the clearest example I have seen of the open-hardware robot moving from hobby curiosity to something a lab will actually hand to a student. The specific reasons are unglamorous: a target cost that stays under six hundred dollars, a bill of materials with purchase links, an Onshape assembly you can inspect before cutting filament, and simulation code that lets you tune a walk without owning the robot. What it does not give you is a finished product. There are no prebuilt units, the parts need a printer and about two hundred plastic screws, and the software half of the repository is small enough to read in an afternoon. If you buy the hardware, you are buying a research platform and a teaching artifact. If you want to print a robot, this one has the documentation to make the afternoon worthwhile.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Rhoban/microban on GitHub