# RoboJuDo: a deployment framework that decouples policy, controller and environment > RoboJuDo is a Python-first framework for running trained control policies on humanoid robots and in simulation, built around three separable pieces, a controller that gathers inputs, an environment that executes actions, and a policy that produces them. It ships a wide policy catalogue, from Unitree's own reinforcement learning work through Human2Humanoid, Smooth, AMO and HugWBC, and the licence terms are less permissive than the badge suggests. **HansZ8/RoboJuDo** — A plug-and-play deploy framework for robots. Just deploy, just do. - Repository: https://github.com/HansZ8/RoboJuDo - Stars: 590 · Forks: 86 - Language: Python - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/hansz8-robojudo ## The problem it starts from: models without deployment code The framing sentence in the README is the one that explains the project. Tired of projects that release only models but no deployment code? RoboJuDo provides a unified framework that makes policy deployment straightforward and practical. The tagline is A plug-and-play deploy framework for robots, just deploy, just do. That gap is real in academic robotics. A policy paper ships weights, a config and a description of the observation space, and the reader is left to write the loop that connects the policy to a simulator or a robot: how inputs are sampled, how actions are applied, how timing is handled, how the two are kept in sync at 50 or 100 Hz. Every project reinvents that loop, and the result is that comparing two policies on the same robot is harder than it should be. RoboJuDo is part of the FRoM-W1 project, hosted under OpenMOSS, and the four highlights it claims are specific. Out-of-the-box deployment means that after setting RoboJuDo up, multiple policies can be deployed on both simulation and real robots in minutes. Decoupled and modular design means the Environment, Controller and Policy are modular and freely composable, with minimal code changes to adapt across robots and setups. Multi-policy switching means you can switch between different policies during a task. And lightweight means the framework is small enough that after five minutes of setup it runs smoothly onboard, which the README credits to a separate project called UnitreeCpp, so that RoboJuDo runs on the Unitree G1 without needing an Ethernet cable. That last point is the one that tells you about the deployment target. Running a policy on a humanoid robot without a network cable means the whole stack has to fit on the robot's own computer, which constrains the dependency list and rules out anything that expects a workstation. The primary language is Python, the default branch is release, the last push was on 2026-08-27 with the project not archived, and the recent releases are 1.5.0 with new policies from 2025-11-10, 1.4.2 from 2025-10-21 and 1.4.1-v1 from 2025-10-14. The project has no GitHub releases in the usual sense beyond these tags, and the repository records a custom licence that GitHub cannot classify. ## Three modules, and the data that flows between them The Introduction section gives the architecture, and it is short enough to state exactly. The Controller is a collection of control signals. It receives external inputs, for example a joystick, a keyboard or motion sequences, and forwards them as ctrl_data to the pipeline. The Environment is the execution environment, for example Mujoco or a real robot. It processes actions provided by the policy and sends real-time sensor data as env_data to the pipeline. The Policy is a trained control policy, from various whole body control and locomotion works. It generates actions based on information from both the environment and the controller. So the loop is: the environment produces env_data, the controller produces ctrl_data, the policy consumes both and emits actions, and the environment applies them. The data flows are named explicitly, which is what makes the decoupling work. A policy does not know whether its observations come from a simulator or from a robot, and a controller does not know what will be done with the joystick values it collects. Experiment configurations can be organized through config files, which is how the framework keeps the composition of a particular run reproducible. The repository has a submodule_cfg.yaml and a submodule_install.py at the root, and a .gitmodules file, which is a hint at how the policy catalogues are brought in. The top-level layout follows the same logic: a robojudo/ package, a packages/ directory, a third_party/ directory, scripts/, tests/, docs/ and assets/. The pyproject.toml confirms the packaging is simple, a single package named robojudo with dynamic dependencies read from requirements.txt, requiring Python 3.11 or newer. ## The policy catalogue is the substance of the project The policy table is where the project's real value sits, because a deployment framework is only as good as the policies it can run. The table lists policies against the three robot targets the badges name, the Unitree G1, the Unitree H1 and the FFTAI gr1t1, with a reference repository, a documentation link and a feature note for each. The supported set is Unitree Official, Unitree Wo Gait, Human2Humanoid, Smooth, AMO, GMT, HugWBC, BeyondMimic and ASAP, and the table in the README is clearly still being filled in, since the policy environment matrix above it is commented out and ends with an ellipsis. The notes carry real information. Unitree Wo Gait has the note no gait, meaning it does not produce locomotion. Human2Humanoid has the note Need PHC submodule, which is a hard requirement for that policy. BeyondMimic is marked With and Without SE supported, referring to whether the support estimator is used. Smooth is marked with a warning symbol on the gr1t1 column, which the table does not explain. The roadmap table above records how the catalogue grew and it reads as a work log. The project was initialised in 2025.04, added Unitree G1 in 2025.05, then H1 and FFTAI Gr1T1 in the same month, integrated the Unitree C++ SDK in 2025.06, added BeyondMimic in 2025.08, opened source in 2025.09, and added ASAP in 2025.10 along with a policy-switch pipeline with interpolation and support for KungfuBot. November 2025 brought KungfuBot2 and TWIST, and a March 2026 update added the ProtoMotions G1 tracker, with credits to NVLabs and to two named contributors. Three items remain unchecked: the code for HugWBC, the code for GMT, and an unspecified list of upcoming policies. The cadence is roughly monthly, which for a project that has to track a dozen upstream policy repositories is a reasonable pace. ## Dependencies tell you what the runtime looks like on a robot The requirements file is the best evidence for what this framework actually runs on, and it is worth reading as a specification of the deployment environment: ```text torch scipy onnxruntime joblib pyyaml easydict python-box tqdm pygame zmq pynput pydantic mujoco msgpack msgpack-numpy colorlog ``` Several entries are the obvious ones for this domain. torch and onnxruntime sit side by side, which tells you the framework expects to load policies in both formats. mujoco is the simulator. scipy, joblib and pyyaml are ordinary supporting libraries. easydict and python-box are configuration and dictionary helpers, and pydantic sits alongside them for validation. The entries that reveal the on-robot constraints are the interesting ones. pygame is a game library, and its presence alongside zmq, the ZeroMQ messaging library, suggests a display or rendering path in simulation that is not needed on hardware but is part of a common interface. msgpack and msgpack-numpy are for compact serialisation of numpy arrays, which is what you want when the data crossing a process boundary is sensor buffers rather than text. colorlog is a logging formatter, and tqdm is progress bars. pynput is the one that catches the eye, because it is a library for capturing keyboard and mouse input globally, which matches the README description of the Controller receiving joystick and keyboard input. The pyproject gives the build details: setuptools with a wheel requirement, a build backend of setuptools.build_meta, the package name RoboJuDo at version 1.5.0, and a requires-python of 3.11 or newer. The optional dev group is pre-commit 4.3.0 and ruff 0.12.7, and the ruff configuration sets a line length of 120 with a target version of py310, selecting the E, F, I, B and UP rule sets and ignoring B008. The exclude list is a good sign of maturity, since it names specific directories that are vendored or generated, including robojudo/controller/motion_lib, robojudo/policy/hilo, robojudo/policy/gmt, packages and third_party, which tells you that some policies and controller code are pulled in as submodules rather than maintained here. ## The licence needs reading before anything else This is the point to slow down on, because the repository's metadata and its badge do not obviously agree. The repository's licence field is recorded as a custom licence that GitHub cannot classify, which is what happens when a licence file exists but does not match a known identifier. The README badge is labelled with a Creative Commons Attribution 4.0 licence, and the badge's link points at a Creative Commons Attribution-NonCommercial 4.0 licence. The two are not the same licence, and the non-commercial variant is the more restrictive of the two. The practical reading is that a deployment framework for humanoids, in a research setting, is likely to be released under terms that restrict commercial use. Anyone planning to put a policy into a product, or to run it in a commercial deployment, needs to read the LICENSE file in the repository root and establish what the terms actually permit. There is a second detail worth knowing for anyone who wants to reuse the code. The repository also carries a pre-commit configuration, a scripts/ directory, a tests/ directory and a docs/ directory with per-policy documentation pages, and the README links each policy to its own anchor page in docs/policy.md. That documentation structure is a good sign for the project, but it also means the operational knowledge for each policy is spread across many pages, and the ones for a policy you have not used yet are the ones you will need most. So the evaluation order matters. Read the licence first, because a non-commercial term ends the discussion for some use cases regardless of how good the framework is. Then read the note column of the policy table, because some policies have hard prerequisites like the PHC submodule, and the framework's value is mostly the catalogue rather than the abstraction. ## Conclusion Adopt RoboJuDo if you are running trained whole body control or locomotion policies on humanoids and want one deployment loop instead of a per-paper one, particularly if your targets are the Unitree G1, H1 or gr1t1 that the framework already knows. Do not adopt it for a commercial deployment until you have read the LICENSE file at the repository root, because the repository metadata and the README badge point at different Creative Commons terms and one of them is non-commercial. Before you commit, check the note column of the policy table for hard prerequisites such as the PHC submodule Human2Humanoid needs, and confirm the policy you want is actually released, since the roadmap still lists the code for HugWBC and GMT as unreleased. ## FAQ ### What is RoboJuDo? It is a plug-and-play deploy framework for robots, a Python-first system for deploying trained control policies on real humanoids and in simulation. It is part of the FRoM-W1 project under OpenMOSS, the last push was on 2026-08-27, and the recent tags include 1.5.0 with new policies, 1.4.2 and 1.4.1-v1. ### How does RoboJuDo decouple a policy from a robot? Into three modules. The Controller receives external inputs such as a joystick, keyboard or motion sequences and forwards them as ctrl_data, the Environment executes actions and sends real-time sensor data as env_data, and the Policy generates actions from both. Because the interfaces are named and separate, a policy can run against Mujoco or against real hardware with minimal change. ### Which policies does RoboJuDo support? The table lists Unitree Official, Unitree Wo Gait, Human2Humanoid, Smooth, AMO, GMT, HugWBC, BeyondMimic and ASAP, against the Unitree G1, Unitree H1 and FFTAI gr1t1 targets. The roadmap shows support for KungfuBot, KungfuBot2, TWIST and the ProtoMotions G1 tracker added between late 2025 and March 2026, with the code for HugWBC and GMT still listed as unreleased. ### What does RoboJuDo need to run on a robot? The requirements list torch, scipy, onnxruntime, joblib, pyyaml, easydict, python-box, tqdm, pygame, zmq, pynput, pydantic, mujoco, msgpack, msgpack-numpy and colorlog, and the project requires Python 3.11 or newer. A separate UnitreeCpp project lets RoboJuDo run on a Unitree G1 without an Ethernet cable. ### What licence does RoboJuDo use? The repository records a custom licence that GitHub cannot classify, while the README badge is labelled as a Creative Commons Attribution 4.0 licence and links to the Attribution-NonCommercial 4.0 terms. Anyone considering commercial use should read the LICENSE file at the repository root to establish what the terms actually permit. ## Sources - [HansZ8/RoboJuDo on GitHub](https://github.com/HansZ8/RoboJuDo) - [Issues](https://github.com/HansZ8/RoboJuDo/issues) - [README](https://github.com/HansZ8/RoboJuDo/blob/release/README.md) - [Releases](https://github.com/HansZ8/RoboJuDo/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hansz8-robojudo