Humanoid programming in practice

Unitree G1 in MuJoCo: Motion Control and MALONI Software Development

MALONI Robotics shares further humanoid software development results: a video of Unitree G1 motion in a virtual MuJoCo laboratory and keyboard-control documentation. We explain the components used, local observations and the limits of the supplied evidence.

MALONI assesses supply, programming and integration for each project. Before an order, we confirm the supply scope, applicable authorizations and available services in writing for the selected model and country. Editorial policy and sources →

Unitree G1 model in the virtual MALONI Robotics Lab during a MuJoCo motion demonstration
Unitree G1 in MALONI Robotics Lab. This image shows a virtual model in MuJoCo.

What our evidence shows

MALONI Robotics continues developing software for humanoid robots. Building on our virtual Unitree G1 laboratory, we share another video of model motion in MuJoCo alongside a screenshot of the keyboard-control documentation. This example describes a local simulation rather than physical robot operation.

Motion demonstration of the simulated Unitree G1 in MALONI Robotics Lab. Published by MALONI on 11 October 2026. Watch on YouTube ↗

The YouTube video is titled “dancing unitree robot”. In this development example, it serves as a visual record of model motion. We do not infer a newly developed dance choreography, music synchronisation or precisely measured velocities from the recording.

Environment and scope

AreaDocumented information
PlatformVirtual Unitree G1 model in MuJoCo
SceneMALONI Robotics Lab, scene_lab.xml
ControlKeyboard control in g1_keyboard.py; documentation describes a mode without ROS
Motion policyExisting g1_29dof ONNX model; policy_config.json follows deploy.yaml
RuntimeONNX Runtime; documentation references building a helper with build_policy_runner.sh
Versions and measurementsExact dependency versions, model revision and systematic performance measurements are not supplied

Connecting control, the model and the ONNX policy

The development screenshot documents keyboard control implemented in the Python file g1_keyboard.py. Its default mode uses scene_lab.xml, the original robot model and an existing ONNX policy for the g1_29dof model. The policy_config.json configuration follows the corresponding deploy.yaml parameters; the documentation states that parameters must be updated when the model changes.

According to the documentation, this particular example runs without ROS. It builds on our broader C++ and ROS 2 work, but we do not attribute these technologies automatically to every simulation recording. Integrating an existing motion policy also differs from training a new policy from scratch.

Visual Studio Code documentation of G1 keyboard control in MuJoCo, showing ONNX policy configuration and lateral-motion and turning parameters
MALONI development evidence: implementation documentation and local observations. The displayed commands are documentation rather than a standalone measurement report.

Commanded velocity and the model response

The documentation records a useful limitation: a lateral command of 0.2 m/s produced almost no stepping for this model. The A/D keyboard mapping therefore uses 0.3 m/s. Turning commands are documented as 0.6 rad/s for Q and −0.8 rad/s for E; the model response in the rightward direction is described as weaker.

These are controller command values rather than measured robot velocities. The simulated model response can differ. We restrict these observations to the documented local simulation and configuration.

Local simulation testing approach

  • Load the laboratory scene and G1 model with the corresponding motion-policy configuration.
  • Start keyboard control and observe model responses in the MuJoCo graphical environment.
  • Separate headless scenarios: documentation lists 10-second posture and forward-command checks and 15-second lateral-motion and turning scenarios.
  • Record a visual example and document observed limitations for further development.

What the result establishes and what comes next

The supplied evidence documents the virtual laboratory, control approach, integration of an existing ONNX policy and local observations of the model response. It does not supply walking success statistics, long-term stability testing, autonomous-navigation validation or validation on physical hardware.

Further development should track the difference between commanded and actual motion, scenario repeatability and the relationship between results, the model and software versions. Moving to a physical humanoid requires separate integration, testing and safety assessment.

MALONI continues developing software for humanoid robots

This example is another step in MALONI Robotics development: from building a virtual laboratory to understanding humanoid-model control and responses in more detail. We continue developing software for humanoid robots, working with simulation and integrating robotics components for specific tasks. For customer projects, scope and compatibility are confirmed for the platform and available interfaces.

Sources and further reading

Primary evidence consists of MALONI’s own video and screenshots. Parameters and observations come from the displayed documentation rather than an independent benchmark. The recording shows simulation.

Concepts for this project

MALONI Robotics

Have a task to assess?

Describe the task, location, and operating conditions. MALONI will review the available product and support options for the specific inquiry.

Robot programming in C++ and ROS 2 ↗Request robot programming ↗