GO2 deployment instability at 20 Hz on RTX 3090

[LeonardoSani]

Hi,
we are trying to reproduce your GO2 deployment results, but we are seeing unstable behavior on trot (and similarly on other deploy tasks).

In our setup, the robot often falls within the first step. Also, the real_kp / real_kd values from the repo config definitely do not work for us.

A likely factor is hardware performance: we are running on an NVIDIA RTX 3090 (less powerful than the GPU reported by you), and we cannot sustain 50Hz.
Our current 20Hz settings are:

dt: 0.05
timestep: 0.05
low_cmd_pub_dt: 0.005

Do you have some ideas for a working GO2 config for this lower-rate regime, including recommended real_kp / real_kd values and any other parameters that should be tuned together with these variables?

Other important details that could be useful to help us:

MuJoCo window
When launching trot, a MuJoCo window opens. Is there a way to disable visualization (headless) without stopping simulation/control? We suspect this may contribute to slowdown.

Initial posture before enabling control
The README says the robot will slowly stand up and, if squatting, it should be manually lifted.
In our case we have the robot squatting, while MuJoCo shows a rest-like initial posture, so the expected starting pose is not fully clear.
Could you clarify the exact initial GO2 posture in the real world and the corresponding posture we should see in the MuJoCo window?

Thanks in advance for your help.

[marinarasauced]

In trying to reproduce their Go2 deployment results, I have also observed this unstable behavior with the trot task where the robot tends to fall within the first step(s), running on a NVIDIA RTX 4060.

In my own tests, I have started with the robot in a standing pose and have matched the joint angles to the initial_position_ctrl parameter in the example deploy.yaml file. I have not paid much attention to the visualization, and I have disabled it by commenting out

        self.viewer = mujoco.viewer.launch_passive(
            self.mj_model, self.mj_data, show_left_ui=False, show_right_ui=True
        )

and

        self.vis_thread = Thread(target=self.visualize)
        self.vis_thread.Start()

    def visualize(self):
        while True:
            mujoco.mj_step(self.mj_model, self.mj_data)
            self.viewer.sync()
            time.sleep(0.05)

in dial_real.py. Have you have obtained any better results at 20 Hz with different settings or still not so far ?

[S4b3]

Hey all! Do you have any updates on this? I am also interested in the matter. It looks like the trot behavior performs "plausible" actions when lifted, but those are not stable enough to walk without falling. Moreover, having to fix the standing position by hand is a bit unsafe. Wouldn't it be better to have actual joints position for the initial pose?

[marinarasauced]

@S4b3 what do you mean by fixing the standing position by hand exactly ? for me, we are using something akin to the unitree sdk2 go2_stand_example (integrated into our own pipeline) to get the robot in an initial joint configuration which matches that in the unitree_go2_trot_deploy.yaml file, then switching over to dial. Sadly I do not have any updates on trying to get better performance with lower frequency or other modified settings :(

I did personally find that increasing the traj_diffuse_factor from 0.5 to 0.9 as suggested in #15 with the higher frequency yields walking results around 0.2 m/s in my own external asynchronous simulator, but it leaves much to be desired.

[S4b3]

@S4b3 what do you mean by fixing the standing position by hand exactly ?

Authors mention in the README that when running an example (such as trot), The robot will slowly stand up. If the robot is squatting, manually lift the robot into a standing position. In my experience, when the robot lifts by running the trot code, it lays on the four legs with a 90° angle and I manually have to put it in a standing position.

Thank you for the hint on the traj_diffuse_factor !

[marinarasauced]

Ah okay. To be honest, I have not tried running the trot code with the robot initially in its resting position lying down, but that is good to note, thanks !