unitree_sdk2: build setup and integration for Unitree robots

Where unitree_sdk2 fits in a Unitree C++ project

unitree_sdk2 addresses the application-development layer around Unitree robots. It is intended for engineers who need to build a C++ program against the vendor's version 2 SDK rather than use the prebuilt examples directly. The repository describes itself concisely as "Unitree robot sdk version 2," and its example directory is organized by robot families and functions, including `a2`, `as2`, `b2`, `b2w`, `g1`, `go2`, `go2w`, `h1`, `h2`, `r1`, `helloworld`, `jsonize`, `state_machine`, and `wireless_controller`.

That layout makes the intended audience fairly clear. A developer integrating motion control, state handling, wireless control, or another robot-specific operation can look for the example corresponding to the target platform. The presence of `helloworld` also gives a repository-provided starting point, although the README does not print its source or explain how to invoke it after compilation.

The SDK is not described as a simulator, a general robotics framework, or a cross-platform package manager distribution. Its documented prebuild environment is Ubuntu 20.04 LTS on `aarch64` or `x86_64`, using GCC 9.4.0. That narrows the adoption decision at the outset. A project running another Linux release or compiler version may still be technically possible, but compatibility is not established by the README.

Repository structure and build surface

Based on the repository layout, the main SDK interface is exposed under `include/`, while library artifacts are stored under `lib/`. Additional build resources live in `cmake/` and `thirdparty/`, and robot-specific usage examples live under `example/`. The repository also contains a top-level `CMakeLists.txt` and a separate `example/CMakeLists.txt`, which indicates that the SDK and examples are built through CMake rather than an ad hoc compiler script.

The README does not document the public API, message types, transport mechanism, callback model, or network addresses. Those details cannot be inferred from the presence of C++ source headers or third-party directories. In particular, repository structure alone does not establish whether an application communicates through a LAN interface, a radio link, another transport, or a hardware-specific mechanism.

For engineering evaluation, the visible division is still useful. A developer can inspect the headers for supported interfaces and select an example by robot family. The release history also shows recent SDK versions rather than a repository consisting only of abandoned example code. However, `include/`, `lib/`, and `thirdparty/` should not be treated as interchangeable extension points. The README does not explain when a prebuilt `lib/` artifact is required or how it relates to locally built headers.

Installing unitree_sdk2 on the documented Ubuntu environment

The README defines Ubuntu 20.04 LTS as the prebuild OS, GCC 9.4.0 as the compiler, and CMake 3.10 or higher as the build-system requirement. On the documented system, install the named build dependencies and libraries first. The package list includes both project dependencies and libraries used by the build, such as `libyaml-cpp-dev`, `libeigen3-dev`, `libboost-all-dev`, and `libfmt-dev`.

The following is the dependency installation command given in the README:

apt-get update
apt-get install -y cmake g++ build-essential libyaml-cpp-dev libeigen3-dev libboost-all-dev libfmt-dev

After that, create a build directory and configure the repository. A successful CMake configuration should prepare the SDK build in `build/` without reporting that a required dependency or compiler feature is missing.

mkdir build
cd build
cmake ..

To compile the examples contained in the repository, invoke Make in the build directory:

make

This is a build-only first use. The README does not document a generic executable invocation, device connection sequence, or verification command, so it does not support claiming that a completed `make` demonstrates communication with a robot.

Installing unitree_sdk2 for a separate CMake application

Developers building their own application can install the SDK into the system directory. The README uses `sudo make install` after configuring with CMake. This approach writes the SDK through its generated CMake installation rules, but the exact installed file layout is not listed.

mkdir build
cd build
cmake ..
sudo make install

The repository also documents a custom installation prefix:

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/opt/unitree_robotics
sudo make install

A custom prefix matters because downstream CMake discovery depends on it. The README states that when unitree_sdk2 is installed somewhere other than `/opt/unitree_robotics`, the directory must be represented in `CMAKE_PREFIX_PATH` so that `find_package()` can locate it. The documented import example is `example/cmake_sample`.

The README does not print that sample's CMakeLists.txt, package name, target names, or include-link configuration. Those details should therefore be read from `example/cmake_sample` rather than reconstructed in an application. This is also why the custom-prefix decision should be made early. A later prefix change can require changes to downstream CMake discovery, although the README does not describe a supported rollback or reinstall procedure.

Robot-family examples and adoption constraints

The strongest selection signal is the set of directories under `example/`. Projects involving Go2 can inspect `example/go2` or `example/go2w`; G1, H1, H2, B2, B2W, A2, AS2, and R1 each have corresponding directories. Function-oriented examples such as `state_machine`, `jsonize`, and `wireless_controller` may be relevant when the immediate need is not tied to one chassis model.

This organization is useful, but directory names do not prove that every feature is interchangeable across robot families. Release `v2.0.1` specifically mentions a Go2 fused motion-control version and a fix for a Go2 `HandStand` call failure. That history suggests some interfaces are platform-specific and that a nominal version number may not summarize all behavior changes.

The SDK is therefore a poor fit if hardware compatibility must be inferred from the project name alone. It is also a weak choice when a team needs documented cross-platform installation, a simulator-only workflow, or an explicit upgrade and rollback policy. None of those features is documented in the README. The Unitree Document Center is supplied as the reference destination, but the README does not map each example to a published hardware compatibility matrix.

The BSD-3-Clause license is a relevant adoption fact because it defines the repository's stated licensing terms. It does not remove the need to inspect `LICENSE`, bundled files under `thirdparty/`, and `licenses/` when distribution obligations matter.

Maintenance, releases, and upgrade cost

The repository is not archived, and the last push was on 2026-10-15. That establishes recent repository activity without, by itself, guaranteeing API compatibility for a particular robot program. The latest listed release is `v2.0.2`, published on 2025-07-07. Earlier listed releases include `v2.0.1` on 2025-06-12 and `v2.0.0` on 2025-06-03.

The version history is compressed around the Go2 fused motion-control release. This makes source-level review necessary when moving between those tags, especially for code touching Go2 behavior. The release note for `v2.0.1` identifies a corrected Go2 `HandStand` invocation, while `v2.0.0` identifies the fused motion-control release itself. The README does not provide a migration guide, deprecation table, supported-version matrix, or rollback command.

Upgrade cost is therefore not limited to rebuilding with CMake. Application owners must compare API and behavior changes in the selected robot example, rebuild for the target `aarch64` or `x86_64` environment, and repeat downstream installation through `find_package()`. The README does not support estimating how much application code will change. That requires inspecting the diff between the version used by the project and the intended release tag.

Editorial conclusion

Adopt unitree_sdk2 when writing a C++ application for a supported Unitree robot and you can work within its Ubuntu, compiler, and CMake environment. Do not choose it solely from the README when your decision depends on transport details, hardware compatibility, or upgrade behavior. Verify first that your exact robot family has a relevant example under `example/`, then confirm the installation prefix and `find_package()` integration in `example/cmake_sample`.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. unitreerobotics/unitree_sdk2 on GitHub