walk-these-ways-go2: sim-to-real gait conditioning on the Unitree Go2

A fork that exists because the SDK changed underneath

This repository is a fork of walk-these-ways, the Go1 sim-to-real locomotion starter kit, and the reason for the fork is specific.

The original project was built against the older Unitree SDK, unitree-legged-sdk, and the documentation notes that walk-these-ways can be used on the Unitree A1 with simple modifications, since those robots are based on that SDK. The newer architecture, unitree-sdk2, is not based on UDP anymore, so this project exists to train and deploy walk-these-ways on the Unitree Go2 by modifying the SDK interfaces.

That is the whole scope, and it is a sensible one. The reinforcement learning side, the training environments and the policy are inherited. The work is in the transport and the deployment layer, where the old SDK assumptions no longer hold.

The repository layout shows the split clearly. There is a go2_gym directory for the simulation environments, a go2_gym_learn directory for the learning code, and a go2_gym_deploy directory that holds the bridge to the robot, the bundled SDK and the scripts. The scripts directory holds the training and play entry points, and runs/ contains a pretrained Go2 model under gait-conditioned-agility/pretrain-go2.

The package metadata names the distribution go2_gym, version 1.0.0, described as a toolkit for deployment of sim-to-real RL on the Unitree Go2, with the author listed as Dengting Liao.

Training needs Isaac Gym, a GPU with 8GB and a pinned PyTorch

The requirements are listed once and they are not light: miniconda, PyTorch 1.10 with cuda-11.3, Isaac Gym, and an Nvidia GPU with at least 8GB of VRAM.

The PyTorch and CUDA versions are pinned rather than ranged, which is a tell that the training stack is tied to what Isaac Gym expects. Isaac Gym is the piece that has to be obtained separately, since it is not distributed as a pip package with the rest of the environment.

The install is the standard editable install of the forked package:

git clone https://github.com/Teddy-Liao/walk-these-ways-go2.git
cd walk-these-ways-go2
pip install -e .

Training is then started from the scripts directory:

python scripts/train.py

The documentation names go2_gym and go2_gym_learn as the main folders for the training process, which is where you would go to change the environment or the algorithm.

To see a policy, you run the play script:

cd scripts
python play.py

And there is a shortcut for the impatient. A pretrained Go2 model is provided in the runs directory, and you can point the label at it by changing the line label = "gait-conditioned-agility/pretrain-go2/train" to your own trained model, or leaving it as is to reproduce the shipped policy.

The deployment side runs on LCM and a rebuilt unitree_sdk2

Getting from a trained policy to a moving robot takes two native pieces, and the documentation is explicit about both.

The first is LCM, Lightweight Communications and Marshalling. The original walk-these-ways implements an interface based on LCM to pass sensor data, motor commands and joystick state between the Python code and the low level control SDK provided by Unitree, so LCM has to be installed on your PC or laptop first. It is built from source:

git clone https://github.com/lcm-proj/lcm.git
mkdir build
cd build
cmake ..
make
sudo make install

The second is unitree_sdk2, which is included in the repository under go2_gym_deploy/unitree_sdk2_bin/library/unitree_sdk2, and you can clone it from Unitree Robotics instead to make sure you have an updated version. The build starts by deleting the shipped build directory and then running the install script and a CMake build:

rm -r build
sudo ./install.sh
mkdir build
cd build
cmake ..
make

The core file is go2_gym_deploy/unitree_sdk2_bin/lcm_position_go2.cpp, which the documentation describes as similar to lcm_position.cpp in walk-these-ways but with unitree_legged_sdk replaced by unitree_sdk2. It is built like the rest of the tree:

cd go2_gym_deploy
rm -r build
mkdir build
cd build
cmake ..
make -j

The LCM message definitions are the contract between the two halves. All the LCM message files in go2_gym_deploy/lcm_types are kept in the same format as in walk-these-ways to ensure a successful connection with the Python files, and they are provided in the project. If you need customised ones, the headers are generated with lcm-gen -x xxx.lcm.

The handshake before a policy is allowed to move the robot

The sequence between a trained policy and a moving quadruped is where mistakes cost you, and the documentation walks through it step by step.

You connect the PC or laptop to the Go2 with an ethernet cable and check the connection by pinging the robot at 192.168.123.161, then run ifconfig to see your own network interface address. If an error occurs, the documentation points at the Unitree support pages.

Next you verify the LCM side. From the build directory you run the receive tool:

cd go2_gym_deploy/build
sudo ./lcm_receive

If LCM and unitree_sdk2 are correctly connected, messages appear in the terminal. Then, and this is the detail that catches people, you make sure lcm_receive has been properly shut down before starting the other program. The documentation is emphatic: it is important not to run lcm_receive and lcm_position_go2 simultaneously.

With that done you start the position server:

cd go2_gym_deploy/build
sudo ./lcm_position_go2 eth0

You replace eth0 with your own network interface, and then, according to the messages shown in the terminal, you press Enter several times and the communication between LCM and unitree_sdk2 is set up.

The safety note attached to that command matters. It will automatically shut down the Unitree sport mode service and set the robot to LOW-LEVEL, and the documentation asks you to make sure the Go2 is hung up or lying on the ground. Only then do you open another terminal and run the policy loader:

cd go2_gym_deploy/scripts
python deploy_policy.py

According to the hints in the terminal, you press the R2 button to start the controller. The joystick mapping is in the get_command function in go2_gym_deploy/utils/cheetah_state_estimator.py, and the default gait in this project is a trot. The caution is clear: press L2 plus B to switch to damping mode if anything unexpected happens, and this is research code used at your own risk.

Two configuration traps the documentation calls out

The known issues section is short and both items are the kind of thing that costs an afternoon if you hit them without warning.

The first is flip_visual_attachments in the go2_config file. It should be set to True, otherwise errors occur when visualizing. That is a rendering configuration flag in the environment, and the failure appears as an error during visualisation rather than during training, which is the awkward way to find out.

The second is about where to change what. To change configuration parameters of the environment or the robot, you should modify parameters in the Go2 config, not in the base legged_robot_config file. That sounds obvious, but it matters because the base configuration is shared with the upstream project, and an edit there does not travel with the Go2 specific overrides in a way the environment expects.

Both files are named in the documentation with paths, the Go2 config living in go2_gym/envs/go2/go2_config.py and the base one in go2_gym/envs/base/legged_robot_config.py.

The broader point is about how this fork is structured. The environment code is split into a Go2 specific layer and a base layer inherited from walk-these-ways, so the rule for a user is that Go2 specific behaviour belongs in the Go2 file, and anything you change in the base file is a change to shared upstream code that you will have to carry when you rebase.

The Jetson path is documented but not finished

The most important limitation is stated at the top of the deployment section. The trained policy is only supported to be deployed through your PC or laptop now, because the author is not familiar with Jetson Orin and hopes to fix it and deploy on Jetson Orin.

The onboard computer on the Go2 is a Nvidia Jetson Orin Nano or NX, running an ARM based architecture, and the documentation gives the default connection details, an IP of 192.168.123.18 with the user name unitree and the password 123, and notes that you can connect over SSH, with VS Code remote development, or by plugging in an HDMI cable.

The requirements listed for the Jetson are cuda, pytorch, miniconda, and cudnn, with the last two explicitly marked as omitted and to be installed by yourself.

The section then says that two different ways are provided to set up correct environments on the Jetson, through the Internet or through Docker, and the documentation for the Internet route is cut off in what is available. So the Jetson path is a stated intention with partial instructions rather than a procedure you can follow end to end.

That matters for planning, because the deployment architecture of the original project assumes a machine on the same network as the robot running the low level control. Whether you can eventually move that onto the robot itself, with the robot talking to its own sensors, is the open question.

There is also a research support dimension. The documentation links two videos of the policy running on a real Go2, one in the author's bedroom and one from another contributor, which is the fastest way to see what a working result looks like before you commit a weekend to it.

Packaging, licences and what the alternative actually is

Two licence statements appear, and they do not agree. The repository licence field records MIT, and the README links a LICENSE file, while the packaging metadata in setup.py declares the license as BSD-3-Clause with the copyright line for Dengting Liao. For a project that is mostly a fork of someone else's Apache licensed work with a new SDK layer, the file in the repository is the one to read.

The dependency list in setup.py is also worth reading as a fingerprint of the era and the stack: ml_logger 0.8.117, ml_dash 0.3.20, jaynes 0.9.2 or later, params-proto 2.10.5, gym 0.14.0 or later, tqdm, matplotlib, and numpy pinned at exactly 1.23.5. The numpy pin is the one that will matter, because it is the kind of constraint that fights with newer packages in the same environment.

The alternative is the project this one was forked from, and the difference is concrete rather than a matter of taste. walk-these-ways targets the Go1 with the older unitree-legged-sdk, which the documentation says can be used on the Unitree A1 with simple modifications, and that path speaks over UDP. This project targets the Go2 and replaces that SDK with unitree_sdk2, which is not UDP based, and pays for it with an LCM bridge, a C++ position server, and the manual handshake described above.

So the choice is between a path that already works on the older robots and a path that matches the current hardware but needs you to run the low level control from your own machine. If you have a Go2, there is no second option in the documentation. If you have an A1, the fork gives you nothing you did not already have.

Editorial conclusion

Adopt walk-these-ways-go2 if you are running gait conditioned sim-to-real research on a Unitree Go2, you have Isaac Gym with a GPU of at least 8GB of VRAM, and you are willing to run the low level control from your own machine over LCM. Do not adopt it if you need a deployment that runs on the robot's own Jetson Orin, since the documentation says the trained policy is only supported through your PC or laptop and the Jetson setup section is unfinished. Verify first that flip_visual_attachments is set to True in the Go2 config, that the robot is hung up or on the ground before the sport mode service is stopped, and that the LCM message definitions in the deployment folder still match the ones your policy expects.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Teddy-Liao/walk-these-ways-go2 on GitHub