MuJoCo Simulation Issues with Latest Updates

[moavia90]

Description of the bug
After pulling the latest MuJoCo updates from GitHub, I am experiencing multiple issues that prevent the simulation from running properly.

---

Problems Observed

• Robot constantly falls and crashes repeatedly.
• Program crashes after a short time and requires restart.
• Forward/backward movement commands don't work — robot just keeps falling.
• MuJoCo simulation fails consistently, while the robot state publisher GUI runs fine.

---

What Works

• The robot state publisher GUI runs without issues.
• RViz displays all required topics and their visualizations.

---

System Specifications

• Processor: intel core i5‑11400H
• RAM: 16 GB
• GPU : Nvidia RTX 3050
• OS: Ubuntu 22.04

---

Resource Usage

Please see the attached system monitor screenshot showing CPU and RAM utilization during the MuJoCo simulation.

---

Questions

1. Is this a known compatibility issue with MuJoCo?
2. What could be causing the constant falling and crashes?
3. How can this be resolved?

---

[manumerous]

Thanks for reporting this! It seems to be a sim instability issue. I can not reproduce it on my setup which might hint that your PC is struggling to keep up with the computational load. Thanks for raising the awareness to this issue.

In the video with the sim there should be a bunch of metric like the realtime factor that should give us insights if your computer is able to keep up with the load of the simulator. Could you share a video without the Robot Base Controller Blocking the view there?

I would suggest to first test just the sim by itself without the MPC by running ros2 run mujoco_sim_interface mujoco_sim_no_torques

Then you can play around with adapting the default values of the mujoco sim to something that is a bit easier on your computer. In MujocoSimInterface.h you can adjust the default config. I suggest adapting

  double dt{0.0005};
  double renderFrequencyHz{60.0};

to

  double dt{0.001};
  double renderFrequencyHz{30.0};

If you run the sim at a lower rate you might also need to adjust the damping ratio and gains in CentroidalMpcMrtJointController.h from 10.0 to maybe something like 5.0.

Let me know how that goes.

[moavia90]

I recorded three scenarios

• make launch-g1-sim without the Robot Base Controller (realtime factor visible)

• ros2 run mujoco_sim_interface mujoco_sim_no_torques

• Lowered sim defaults in MujocoSimInterface.h

from

double dt{0.0005};
double renderFrequencyHz{60.0};

to

double dt{0.001};
double renderFrequencyHz{30.0};

I did not adjust the damping ratio and gains in CentroidalMpcMrtJointController.h as I couldn’t find a damping ratio in CentroidalMpcMrtJointController.h. The controller defines inverse_dynamics_kp_ and inverse_dynamics_kd_ (currently zero) and applies per-joint PD gains here in computeJointControlAction() :

action.kp = 1200.0;
action.kd = 10.0;

[moavia90]

@manumerous is Kp responsible for stiffnes and Kd responsible for damping ??

[manumerous]

Yes exactly that is correct. They are feedback terms that are evaluated at the mujoco frequency to emulate having those feedback terms on a motor controller level.

[manumerous]

Thanks for sharing those experiments. That helps a lot. In the first 2 cases i realize that your Real Time Factor (RTF) seems to be very inconsistent. Sometimes it increases the speed by a factor of even 3.5 faster or slower than realtime. For me that that value is consistently 1.0.

When looking at the example with no torque it seems that the physics sim by itself is stable, so you should not necessarily need to adjust kp and kd or dt. It seems that the really inconsistent timing make the closed loop MPC unstable. Could it be that your system is running low on cores and that the Mujoco sim doe snot get a full core by itself?

[manumerous]

For reference this is how the sim looks for me

vokoscreenNG-2025-08-13_18-37-37.mp4

[moavia90]

@manumerous How can I check if the MuJoCo simulator is using a full CPU core? I'm running it in a Docker container. Have you tested MPC on the host machine or inside a dev container?

[moavia90]

I tried a bunch of flags for launching docker especially If --cpuset-cpus="${CPUSET} it would restrict the container to only run on CPU core 3. i.e. CPUSET="3"

The whole script for launching docker is as follows:

#!/usr/bin/env bash
set -euo pipefail

# Allow GUI applications
xhost +local:

# Set environment variables (fallbacks if not set)
USER_ID="${USER_ID:-$(id -u)}"
GROUP_ID="${GROUP_ID:-$(id -g)}"
XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/tmp}"


# Host workspace root 
HOST_WS="$(realpath "${PWD}/../../..")" 

CPUSET="3"  

# Run the container with devcontainer-compatible arguments
docker run \
  --rm \
  -it \
  --name wb-mpc-dev \
  --net=host \
  --privileged \
  --cpuset-cpus="${CPUSET}" \
  -u "${USER_ID}:${GROUP_ID}" \
  -e DISPLAY \
  -e QT_X11_NO_MITSHM=1 \
  -e XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR}" \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -v "${XDG_RUNTIME_DIR}:${XDG_RUNTIME_DIR}" \
  -v "${HOST_WS}:/wb_humanoid_mpc_ws:cached" \
  -v "${HOME}/.gitconfig:/home/vscode/.gitconfig:ro" \
  --workdir /wb_humanoid_mpc_ws/src/wb_humanoid_mpc \
  wb-humanoid-mpc:dev \
  bash

echo "Done."

I'm using a script to launch Docker because devcontainer.json isn't working. I tried debugging it on my end, and if I can't resolve it, I'll share the issue. Initially, the script used flags similar to those in the runArgs section of devcontainer.json, but I later added some, like cpuset.
So in gif the robot does move for few steps before it falls .

@manumerous Do you think the above flags are causing issues ? can you recommend which flag should I avoid or which one should be added ?

[kosei1515]

I met the same issue and tried reducing the cpu load.
Sim version seems to have different loop rate, which may increase the cpu usage.

Try replacing

wb_humanoid_mpc/humanoid_nmpc/humanoid_wb_mpc_ros2/src/WBMpcRobotSim.cpp

Line 123 in a4ac4ab

size_t mrtDeltaTMicroSeconds_ = 1000000 / (500);

to:

  size_t mrtDeltaTMicroSeconds_ = 1000000 / (80);

, which is the same frequency with dummy sim's (

wb_humanoid_mpc/humanoid_nmpc/humanoid_wb_mpc_ros2/src/WBMpcDummySimNode.cpp

Line 75 in a4ac4ab

MRT_ROS_Dummy_Loop dummySimulator(mrt, 80, interface.mpcSettings().mpcDesiredFrequency_);

).

I also set

  - double renderFrequencyHz{30.0};
  - double renderFrequencyHz{10.0};

Although my cpu usage still exceeds 300%, the g1 movement in Mujoco is getting better. I do not think this is the best answer as well since decreasing control frequency can cause serious issues.

top

 %CPU  %MEM     TIME+ COMMAND                           
 328.6   4.4   5:25.89  humanoid_centro...
 27.9     0.8   0:29.87  rviz2                             
 14.6     0.3  18:00.78 Xorg    

[manumerous]

Thanks for the updates. I think trying to reduce the docker container to only use one core with e.g. CPUSET="3" will not help since launching the mpc and sim together launches multiple threads. The threads used are the following:

• Simulation thread running mujoco
• Render Thread visualizing mujoco
• MRT Thread that reads latest MPC policy and applies the low level controller to compute the torqes send to the robot.
• The actual MPC threads as specified in nThreads in the task.info file (typically 4)

All these threads are independent from each other. The computations in the MRT thread should be really fast. On my CPU I bench-marked the inverse dynamics as 30 micro seconds, so even on a slower CPU there should be plenty of time to solve the loop in 2ms.

Given that your simulation RTF is inconsistent even when the MPC is not running I would suggest trying to fix that first. If we fix this and issues persist we can exclude the sim timing and focus on whats left.

The render thread should be independent form the sim thread apart from the mutex they share to access mujoco data. Decreasing the frequency might help a bit.

Inc case you do not have enough cores I suggest trying to get rid of all the rviz and ros2 nodes that are not strictly needed. You can disable all the non necessary ros2 nodes in cfg.ld.add_action(cfg.mpc_sim) to

    # Add nodes
    cfg.ld.add_action(cfg.mpc_sim)
    # cfg.ld.add_action(cfg.robot_state_publisher_node)
    # cfg.ld.add_action(cfg.terminal_robot_state_publisher_node)
    # cfg.ld.add_action(cfg.target_robot_state_publisher_node)
    # cfg.ld.add_action(cfg.rviz_node)
    # cfg.ld.add_action(cfg.base_velocity_controller_gui_node)

You could also try to set the thread priority for the mujoco and mpc threads to be higher than the rest of the system threads so your OS does not interupt them for other tasks.

[uzakotim]

Please, tell me how do you run mujoco simulation of g1 with the controller
FOUND IT in Makefile:
launch-g1-sim
launch-wb-g1-sim
Maybe, it will help someone