logo Mr.Robota 具身智能学习手册 中文
Chapter 7: Booster K1 Webpage MuJoCo: Local Deployment and AMP Training Experience

Booster K1 Webpage MuJoCo: Local Deployment and AMP Training Experience

Update date: 2026-09-29

This tutorial first allows you to experience the upstream online demo, and then deploys the upstream static web pages and model assets provided by the repository into a local Windows browser. It also explains how to publish them on your own GitHub Pages after obtaining authorization. Web-based inference does not require installing the MuJoCo environment of Python projects or training models; local static hosting requires running an HTTP service with Python, while re-training requires Linux + NVIDIA GPU.

1. How the web demo runs

The upstream booster_mjlab project provides the Booster K1 MuJoCo model, speed control and motion tracking tasks, as well as a training process based on Adversarial Motion Priors (AMP). Its web page is a static site: the browser loads the pages, JavaScript, and the policy and model from static/demo/ from the website directory, and then loads MuJoCo WebAssembly, Three.js, and the Draco decoder from jsDelivr. Simulation and policy inference are executed in the browser, and the official page indicates that the policy frequency is 50 Hz; this is not a remote desktop or video stream.

Therefore, three things need to be distinguished:

Content Execution Location Required
Official online demo Upstream hosted webpage; policy calculated in local browser Browser, network, and WebGL
Local static hosting Local HTTP service provides upstream website/ files Upstream repository copy, Python 3, browser, and network
Optional training Linux upstream project Linux, NVIDIA GPU, W&B; minimum memory not announced

This deployment uses the upstream web source code and pre-exported policy assets, rather than this tutorial reimplementing the MuJoCo frontend or training models on this real robot. The official project page shows the results of the policy executed on a real robot, but the upstream repository currently does not provide the deployment code for real robot deployment; this tutorial does not claim to reproduce real robot experiments.

2. Experience the upstream online demo first

2.1 Open the interactive page

Open the Booster K1 official project page using a newer Microsoft Edge or Google Chrome, scroll to In your browser, and click Load interactive demo ≈14 MB. This is a upstream-hosted web page; the first load requires connecting to the network to download resources such as WebAssembly, rendering libraries, and policies.

2.2 Control Robot

  1. Wait for the simulation canvas and the speed reading in the upper left corner to appear.
  2. Click on the simulation scene to focus it with the keyboard.
  3. Use W to move forward, S to move backward, A / D to move sideways, and Q / E to turn. You can also drag the joystick in the lower left corner or use a game controller.
  4. Click the Reset button on the screen to restore the initial state. You can drag the mouse to rotate the viewing angle.

2.3 Check if the operation was successful

  • The page displays the K1 simulation model, the ground, and the control joystick.
  • When the direction key is pressed, the speed reading changes, causing the robot to move; when the key is released, the corresponding speed command returns to zero.
  • Clicking Reset restores the simulation to its initial state.

When this tutorial was written, the upstream online page was actually opened in Microsoft Edge on Windows: the canvas renders normally. After pressing W, vx changes from 0.00 to non-zero; when released, it returns to 0.00 m/s. This merely verifies that the upstream online demo is interactive in this browser, not a local hosting verification.

2.4 Common Issues

  • No screen appears after clicking the button: Ensure the network can access the official page, and wait for the first resource to load; try again after refreshing the page. Update the browser and graphics card drivers if necessary, and enable graphics acceleration in browser settings.
  • Keys do not respond: First, click on the simulation canvas, then press the direction keys; confirm that the focus is not on the address bar or other page controls.
  • Screen lags or long loading time: The first download requires approximately 14 MB of resources; close programs that consume a lot of resources, then reload, and ensure the browser does not disable WebAssembly / WebGL.
  • Want to run web files on your own computer: Continue to the next section. Hosting a static webpage locally is a different matter from installing the upstream Python simulation / training environment.
  • Want to run Python-based training on Windows: The upstream requires a NVIDIA GPU, but no native Windows training steps are provided; use a Linux + NVIDIA environment for training.

3. Hosting Web Pages on Windows Local Machine

The web page itself is a static file, so there is no need to install the MuJoCo Python package on Windows or perform GPU training. The browser still downloads MuJoCo WebAssembly, Three.js, and Draco from jsDelivr, which means a connection is required for the first load. Do not double-click index.html to open it with file://: the browser module and fetch() require an HTTP source.

3.1 Obtain upstream web pages and model files

Open PowerShell in the root directory of the tutorial repository and clone the upstream repository:

powershell$BoosterRoot = Join-Path $env:USERPROFILE 'src\booster_mjlab'
git clone --depth 1 https://github.com/IntelligentRoboticsLab/booster_mjlab.git $BoosterRoot

If the GitHub clone connection fails, select Code → Download ZIP from the upstream repository . After decompression, change $BoosterRoot to the decompression directory. Ensure the web page and policy file are on the disk:

powershellTest-Path "$BoosterRoot\website\index.html"
Test-Path "$BoosterRoot\website\static\demo\scene.json"
Test-Path "$BoosterRoot\website\static\demo\policy.bin"

All three results should be True. The demonstration relies on a set of mutually referenced files, and the entire website/ directory structure is preserved during download.

3.2 Starting the Local HTTP Service

The serve_demo.py included in this tutorial is a standard library static server. The default MIME type for Windows Python 3.11 will treat .js as text/plain, and the browser will refuse to execute ES module in web pages; this script explicitly sets the MIME types for .js, .mjs, and .wasm.

Execute in the root directory of the tutorial repository:

powershellpython ".\07-机器人操作、运动控制\Locomotion\02-BoosterK1-mjlab-AMP\serve_demo.py" `
  --directory "$BoosterRoot\website" `
  --host 127.0.0.1 `
  --port 8765

After the terminal displays Serving ... at http://127.0.0.1:8765, keep the window running, and open http://127.0.0.1:8765/ in Edge or Chrome. Click Load interactive demo, wait for the model to appear, then press W; the speed reading should become non-zero, and it will smoothly return to zero after releasing the button. Press Ctrl+C to stop the service.

127.0.0.1 is accessible only by this machine. This Python service is suitable for local inspection and is not a production public server; if it is temporarily exposed to the local network, --host can be changed to 0.0.0.0, but you need to handle the firewall and access scope yourself.

This tutorial has tested this on-hosted path on Windows 11, Python 3.11, and Microsoft Edge: the web module returns with text/javascript, and both the interactive canvas and policy are successfully loaded; when holding down W, the speed reading increases to a non-zero value, and it returns to 0.00 m/s after releasing. The upstream introduction video requests on the page are canceled by the browser during the automated check, but this does not affect the simulation demo.

4. Where Do Webpage Models and Policy Files Come From

The upstream repository has submitted the pre-exported assets used in the current demo, so there is no need to download the web inference weights from Hugging Face. They are located at [website/static/demo/:

File Purpose
policy.bin AMP speed policy weight for browser execution; not a PyTorch checkpoint
k1_web.xml MuJoCo XML model used in browser simulation
meshes/*.stl Collision mesh referenced in XML, requiring retained relative paths
robot.glb Robot appearance mesh for Three.js rendering
scene.json Index of policy, joint mapping, control parameters, and the above files

To reuse the official demo, the simplest and most reliable way is to download or clone the upstream repository and fully retain website/static/demo/. lafan_locomotion_k1 The Hugging Face dataset is the action reference data used for AMP training, not the policy.bin of the web demo.

The upstream export script export-web-demo accepts an ONNX speed policy with mjlab metadata, and generates policy.bin, XML, grids, and scene metadata; its usage example is:

bashuv run --with fast-simplification export-web-demo path/to/policy.onnx

The default output directory is the website/static/demo/ of the repository. There is currently no explanation from the upstream about how to convert the .pt checkpoint generated during training into this ONNX input. Therefore, do not directly rename the .pt file to policy.bin; instead, use the policy you trained yourself. You need to prepare the model according to the ONNX export process provided by the upstream first.

5. Publish on your own GitHub Pages after authorization

As of the update date of this tutorial, there are no project-level LICENSE files in the upstream repository; the BULMA-LICENSE.txt in the repository only describes the license for the Bulma style library and cannot replace the licenses for web pages, robot models, and policy assets. Before publicly hosting or distributing web page code, models, and policies, confirm the authorization with the upstream maintainer or wait for the repository to add licenses. The following steps apply only to cases where the rights to publicly host these files have been confirmed; policy.bin, models, and web page files on GitHub Pages are accessible to visitors.

The upstream includes .github/workflows/docs.yml Displayed publishing method: The website is a static file with no build steps. GitHub Actions directly handles it. website/ The directory is uploaded to Pages. The easiest way is to fork the upstream repository after obtaining clear authorization; if using your own repository, you need to copy the web pages and the workflow according to the license, while preserving the original directory structure.

  1. Fork [IntelligentRoboticsLab/booster_mjlab], or after obtaining authorization, add the upstream [[website/]] and [[.github/workflows/docs.yml]] into your own repository. The workflow defaults to monitoring the [[main]] branch; if your default branch name is different, modify the branch name in the workflow accordingly.
  2. Open the repository Settings → Pages → Build and deployment, set Source to GitHub Actions. Ensure Actions is enabled; if the workflow page suggests enabling [[Docs]], enable it first.
  3. Open Actions → Docs → Run workflow to publish manually; future pushes to the [[main]] branch [[website/]] or modifications to this workflow file will also trigger automatic publishing. After the workflow succeeds, check the deployment details in Actions or Settings → Pages for the site URL. Project repositories typically use paths such as [[https://<用户名>.github.io/booster_mjlab/]].
  4. Open the page from a public URL and click Load interactive demo. Verify that the robot canvas loads correctly and keyboard controls respond, and check that resources such as [[scene.json]], [[policy.bin]], XML, grids, and GLB are accessible.

The MuJoCo and rendering dependencies of the web page still load from jsDelivr, so visitors need to be able to connect to the CDN. If the deployment environment cannot access the CDN, these dependencies must be hosted manually under appropriate licensing conditions, and the import map and WASM paths in the web page need to be modified; this tutorial does not verify the offline packaging solution. GitHub Pages supports publishing static sites via GitHub Actions. For details, see , the GitHub Pages custom workflow documentation and , and the configuration of the publishing source instructions .

6. Optional: Train AMP speed policy

This section is designed for readers who wish to experience reinforcement learning training. There is no need to run this section to test the browser demo. The commands are based on the README in the upstream repository; after updates to the upstream project, task names and parameters may change. Please refer to the latest instructions before execution.

6.1 Environmental Requirements

  • A Linux environment and a functioning NVIDIA GPU. The upstream documentation indicates that a NVIDIA GPU is required for training, but no minimum memory or recommended graphics card models are specified; therefore, it cannot be assumed that any laptop GPU can handle the default configuration.
  • Git, a connected environment, and the uv package manager. The project synchronizes Python and dependencies via uv.
  • A Weights & Biases (W&B) account for recording training runs and loading checkpoints using the run path. When used for the first time, log in according to the official W&B instructions ; do not include the API key in the code or commit it to the repository.
  • A stable network and several GB of available disk space. The first uv run will synchronize dependencies such as PyTorch / MuJoCo; the actual download size varies depending on the platform and dependency resolution results, and the upstream does not specify a precise minimum disk requirement.

The upstream source does not provide any instructions on native Windows training support. If Windows users want to train, they should use a Linux workstation with a NVIDIA GPU or a cloud-based Linux environment. Do not interpret browser inference verification as equivalent to verified Windows Python training. The default 4096 parallel environments may require a large amount of memory; if there is insufficient memory, the number of parallel environments can be reduced first. The actual speed and memory usage depend on the GPU, driver, and version of dependencies.

6.2 Install and check the task

Execute in the Linux terminal:

bashgit clone https://github.com/IntelligentRoboticsLab/booster-mjlab.git
cd booster-mjlab
uv run list_envs

uv run list_envs will prepare the running environment according to the project configuration and list the registered tasks. After confirming that the command completes successfully and Mjlab-Velocity-Flat-Amp-DA-Muon-Booster-K1 is included in the list, then start training. If uv has not been installed yet, please follow its official installation instructions first, reopen the terminal, and verify that uv --version is available.

6.3 Startup Speed Control Training

The default command given in the upstream README is 4096 parallel environments:

bashuv run train Mjlab-Velocity-Flat-Amp-DA-Muon-Booster-K1 \
  --env.scene.num-envs 4096

If there is insufficient video memory, try a smaller number of parallel processes first, for example:

bashuv run train Mjlab-Velocity-Flat-Amp-DA-Muon-Booster-K1 \
  --env.scene.num-envs 512

During training, monitor the terminal and W&B run page to ensure that the simulation steps and training metrics are updated continuously, and record the path of this run. 512 is merely an initial attempt to reduce the parallel scale; it is not a guaranteed minimum configuration or performance commitment from upstream. If there is insufficient VRAM during initialization, continue reducing the number of environments or switch to a GPU with more VRAM.

The default speed task uses a small number of LAFAN1 walking action clips provided from the upstream to serve as AMP action priors. To replace the action data, the upstream supports Hugging Face dataset IDs or local files/directories, which can be passed via --agent.dataset-root; please prepare and verify the data according to the upstream format first.

6.4 Evaluating Checkpoint in Simulation

Get the training run path from the W&B run page, in the format 组织或用户名/mjlab/run-id, and then execute:

bashuv run play Mjlab-Velocity-Flat-Amp-DA-Muon-Booster-K1 \
  --wandb-run-path 组织或用户名/mjlab/run-id

Replace the example path in the command with your own W&B run path. The upstream description indicates that this command will retrieve the latest checkpoint from W&B and initiate policy simulation evaluation. Check whether the policy can respond to speed commands and whether the robot can continue walking in simulation; this is still simulation evaluation, not sending control commands to a real robot.

7. Interpretation of Results and Precautions

  • The official project page describes a demonstration of the real robot Booster K1 running the AMP speed policy after 30k training steps. This is an upstream showcase result, not a guarantee for reproduction on readers’ hardware; the number of training steps also cannot be used as a guarantee for the same effect alone.
  • The upstream README currently states that the real robot policy deployment code “will be provided soon”. This tutorial only covers browser-based inference, as well as the upstream training commands and simulation evaluation interfaces, but does not provide real robot deployment or security operation steps.
  • The browser version uses publicly available web-based export policies; the training version involves retraining in a local / Linux GPU environment. The two methods rely on different dependencies, execution locations, and outputs.
  • This tutorial only links to the upstream repository, web pages, and dataset; it does not copy upstream code, model weights, or web resources. As of the update date, no LICENSE file is found on the upstream repository page; if you wish to distribute its code, weights, or data again, please confirm with the upstream maintainers regarding authorization and data usage conditions.

8. Reference Materials