# Mini Pupper 4 is a map of the robot dog's software, not the robot dog > The Mini Pupper 4 repository is a landing page for an open source quadruped kit, pointing at separate repositories for the ROS 2 Jazzy stack, the microcontroller firmware, the Raspberry Pi applications, the MuJoCo reinforcement learning pipeline, the actuator friction model and the board support packages. The hardware is built around a proprietary 3-DoF coreless smart servo, which is where the open source story ends. **mangdangroboticsclub/mini-pupper** — Open-Source,ROS Robot Dog Kit - Repository: https://github.com/mangdangroboticsclub/mini-pupper - Stars: 1,175 · Forks: 196 - Language: Unknown - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/mangdangroboticsclub-mini-pupper ## The repository you are reading is an index The first thing to understand about this repository is what it is not. The top level contains CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE, README.md and a docs/ directory. There is no source code, no firmware, no simulation, no CAD and no bill of materials in the tree you are cloning. It is a map. The Open Source Repo Guide table in the README is the actual content, and it lists the components and where each one's source lives. The ROS 2 Core Stack is in mangdangroboticsclub/mini_pupper_ros, described as the main software platform, which strictly follows the official Open Robotics roadmap with stable support up to ROS 2 Jazzy. The BAM Friction Engine is in mangdangroboticsclub/bam. The MCU Brain firmware is in mangdangroboticsclub/minipupper-4-mcu, described as the complete firmware layer source code for the onboard microcontroller, including embedded local AI routing. There is a Mini Pupper 4 Pi Brain entry for the high level application space tailored for the Raspberry Pi computing chassis, and board support packages for Mini Pupper 1 and Mini Pupper 2 in separate repositories, plus a web controller that provides a web GUI for Mini Pupper 1 and 2 running StanfordQuadruped. So the adoption question is not whether to use Mini Pupper, it is which of these repositories your project needs and how much of the hardware you intend to build. The documentation hub is at minipupperdocs.readthedocs.io, described as a comprehensive documentation hub including modular mechanical blueprints, PCB schematics and open research challenges, and that is where the mechanical side lives rather than in this repository. The licence is Apache 2.0, the repository is not archived, and the last push was on 2026-10-16. There are no GitHub releases, which is consistent with a hub whose versioned artefacts are the sibling repositories. ## The servo is proprietary, and everything else follows from it The README is explicit that all capabilities stem from the proprietary high performance 3-DoF coreless smart servo joints, described as the ultimate, versatile building block for modern open source robotics, and the architecture diagram in the README is labelled with the MD-300C-150 smart servo. That statement deserves careful handling, because it is the boundary of the whole project. The software is open source, the mechanical blueprints are published, the PCB schematics are in the documentation hub, and the actuator model is calibrated against the real hardware. What is not open is the joint module itself, the part where the motor, the gearing, the encoder and the low level control electronics live. For a buyer, that means the kit is a mixture. You are assembling around a component you cannot modify or reproduce, which is a normal situation for a robot kit and an unusual one for something described as open source robotics. It also means the open source material is genuinely about the parts you can change: the firmware, the ROS stack, the simulation, the policies. The design decision that follows from a coreless smart servo is worth noting too. A servo that provides position, velocity and current feedback over a serial or CAN link, with the control loop closed inside the joint, is what makes a twelve degree of freedom quadruped tractable for a small team. Without it, every joint would need its own low level driver, and the repository would look very different. The hardware itself is sold through mangdang.store, and the project is presented as a kit with a store, a documentation hub, a Discord community and a Facebook group, which is the shape of a product with a company behind it rather than a hobby project. ## Reinforcement learning: MuJoCo, PPO, domain randomisation and ONNX The reinforcement learning entry in the repo guide is described as the physics engine backend, with MuJoCo environments, PPO pipelines, domain randomization, and the baked-in ONNX export runtime. The capability it supports is closing the Sim2Real gap, training complex neural network policies in high fidelity simulation and deploying them straight to the real physical robot. Read that as a pipeline rather than a list of features. MuJoCo is the simulator, and for a legged robot the physics of contact, friction and mass is where a policy either transfers or does not. Domain randomization is the technique that makes transfer possible, by varying the physical parameters during training so the resulting policy is robust to the real robot rather than tuned to one simulation. PPO is the training algorithm, a deliberately conservative choice, and the domain randomization is where the effort sits, because that is where the knowledge about the real hardware gets encoded. The ONNX export is the hand-off. A trained policy is exported to ONNX and run by the baked-in runtime on the robot, which is what makes deploy straight to the real physical robot a configuration choice rather than a research project. The interesting part for a newcomer is that the same physical parameters the domain randomizer varies over are the ones the friction model has to get right, which is what the next section is about. ## BAM exists because the joints have friction worth modelling The BAM integration is described as native and fully compatible with Better Actuator Models, to capture precise joint friction physics, letting you focus on your advanced applications. The repository guide points at a dedicated hardware actuator physics repository, and states that the MangDang MD-300C-150 servo is fully benchmarked and adapted to BAM. The detail that matters is that last clause. Any simulator can model friction, and most simulators model friction badly, because the default model is a simplification. For a policy that has to be executed on a real servo, a friction model that does not match the real joint means the policy is trained against a world that does not exist, and the gap shows up as a robot that behaves differently when the lights come on. Benchmarking the specific servo and adapting it to the model is therefore what makes the simulation and the hardware agree, and it is why the friction engine is a separate repository rather than a parameter file. It is a hardware calibration artefact, and its value is specific to the servo it was measured on. The two pieces fit together into one workflow. The friction engine tells the simulation what the joint actually does, the domain randomizer in the training pipeline varies around that, and the exported policy is run against the real servo through the same interface. For a user of a different actuator, none of that calibration transfers, and the simulation would need its own measurement. ## Two brains: micro-ROS on the MCU, ROS 2 Jazzy on the Pi The Mini Pupper 4 architecture splits the compute across two processors, and the repo guide describes the split as the micro-ROS stack for the real-time lower-level agent bridging, with actuator DDS communications introduced natively from Mini Pupper 4, and the Pi Brain for the high level application space. The microcontroller side is the low level brain. The MCU Brain repository holds the complete firmware layer source code for the onboard microcontroller, including embedded local AI routing, and the micro-ROS capability is described as native support for micro-ROS pipelines directly on the microcontroller for reliable, real-time actuator control. So the real-time loop, the part that has to keep the robot standing, runs on the microcontroller with the actuators talking over DDS. The Raspberry Pi side is the high level brain. It runs the ROS 2 Jazzy stack, described as ready-to-run out-of-the-box templates for advanced SLAM mapping, path planning and autonomous Nav2 stacks, following the official Open Robotics roadmap with stable support up to ROS 2 Jazzy. The division of labour is the interesting design decision. ROS 2 on a single board computer is not deterministic enough to be trusted with a real-time control loop, and a microcontroller is not where you want to run Nav2. Splitting them lets each processor do what it is good at, and it is why the project can offer both micro-ROS pipelines and a full Nav2 stack on the same robot. The consequence for a developer is that there are two code bases to build and two IPC layers to debug, and the docs hub points at open research challenges as well as blueprints, which suggests the edges of that split are still being worked on. ## The rest of the ecosystem: BSPs, a web controller, community notebooks Beyond the four main repositories there is a layer of supporting and community work that tells you what the project's centre of gravity is. The board support packages for Mini Pupper 1 and Mini Pupper 2 are in separate repositories, and the web controller provides a web GUI for Mini Pupper 1 and 2 running StanfordQuadruped. That the BSPs for the earlier generations are still published says the project supports the machines it has already shipped rather than only the current one, and the web controller spanning both generations with a named base stack underneath suggests the software is expected to be reusable across chassis. The community contribution table lists two external repositories with an experimental status. minipupper_kinematics contains Jupyter notebooks used to gain a better understanding of the kinematics of a quadruped robot in general and Mini Pupper 1 in particular, and mini-pupper-jupyter-notebooks holds ROSCon2022 Jupyter notebooks for Mini Pupper 1. Both are marked experimental, and both are in other people's namespaces, hdumcke and Tiryoh, which tells you the project accepts outside work without taking ownership of it. The contributing guide, in this repository, covers compiling, local simulation testing, layout conventions and code submission rules, and it is the document to read before you contribute code to any of the sibling repositories. The documentation hub rounds it out, with modular mechanical blueprints, PCB schematics and open research challenges. Publishing schematics and challenges is a stronger commitment than publishing a user manual, and for a kit aimed at students and researchers it is probably the most valuable thing in the whole set. ## Building your first Mini Pupper, in the order the repos imply There is no install command here, because there is no software in this repository to install, and building a Mini Pupper 4 is a hardware project with a software tail. The sequence the repository structure implies is the practical one. Start with the documentation hub, since it holds the mechanical blueprints, the PCB schematics and the FAQ, and it is where the assembly of the kit and its variants are described. Then choose your compute: the Pi Brain for the high level application space and the ROS 2 Jazzy stack, and the MCU Brain for the firmware and the embedded local AI routing. The simulation side is where you can start without hardware. The reinforcement learning work sits on MuJoCo with PPO and domain randomization, and the friction engine is calibrated against the MD-300C-150 servo, so a simulation-first workflow is viable: validate the model, train and export a policy to ONNX, and only then bring hardware into the loop. The contributing guide's reference to local simulation testing suggests that is the intended order. On the software side, the ROS 2 Core Stack is the main platform and follows the official Open Robotics roadmap up to Jazzy, so a team already running ROS 2 has little to learn, and the micro-ROS side is the part that is specific to this hardware. Finally, the licence is Apache 2.0 across the project, which is the permissive end of the scale and means a derivative robot or a modified firmware carries no obligation beyond keeping the notice. The hardware kit is sold separately, and the servo inside it is proprietary, so a plan that assumes you can rebuild the joints from the published files will not work. ## Conclusion Mini Pupper 4 suits a robotics student or team that wants a small quadruped to learn ROS 2, micro-ROS and reinforcement learning on, and that is willing to buy the servo hardware and assemble the kit. It does not suit a team that needs a fully open bill of materials, because the joint actuation depends on a proprietary smart servo, and it is the wrong choice if you need working hardware delivered rather than a set of repositories to build from. Verify first which of the sibling repositories you actually need for your goal, that the ROS 2 Jazzy support is the one you want since the stack follows the official Open Robotics roadmap, and that the actuator model in your simulation matches the servo you have been given. ## FAQ ### What is the Mini Pupper 4 repository? It is an index for the Mini Pupper 4 open source robot dog kit, listing the separate repositories that hold the ROS 2 core stack, the microcontroller firmware, the Raspberry Pi applications, the MuJoCo reinforcement learning pipeline, the actuator friction model and the board support packages. The repository itself contains documentation, not code. ### Which parts of the Mini Pupper 4 are open source? The software, the mechanical blueprints, the PCB schematics and the actuator model are published, but the joints themselves are proprietary 3-DoF coreless smart servos, and the README states that all capabilities stem from them. ### How does Mini Pupper 4 support reinforcement learning? Through MuJoCo environments, PPO pipelines, domain randomization and a baked-in ONNX export runtime, so a policy can be trained in simulation and deployed to the real robot, with the BAM friction engine providing the joint friction physics the simulation depends on. ### What is the role of the two compute units in Mini Pupper 4? The microcontroller runs the firmware and the real-time agent, with native micro-ROS pipelines and actuator DDS communications, while the Raspberry Pi runs the high level applications and the ROS 2 Jazzy stack with SLAM, path planning and Nav2 templates. ### Where is the Mini Pupper documentation? In the online manual and FAQ at minipupperdocs.readthedocs.io, which the README describes as a comprehensive documentation hub including modular mechanical blueprints, PCB schematics and open research challenges. The contributing guide covers compiling, local simulation testing, layout conventions and code submission rules. ## Sources - [Issues](https://github.com/mangdangroboticsclub/mini-pupper/issues) - [License: Apache-2.0](https://github.com/mangdangroboticsclub/mini-pupper/blob/main/LICENSE) - [mangdangroboticsclub/mini-pupper on GitHub](https://github.com/mangdangroboticsclub/mini-pupper) - [README](https://github.com/mangdangroboticsclub/mini-pupper/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mangdangroboticsclub-mini-pupper