The humanoid development stack

The layers

Software for a humanoid robot is usually built in layers, and the questions worth asking about a platform follow them. What does the maker give you to read sensors and command joints? Does it plug into ROS 2? Is there an official model for simulation? Can you train policies for it, and collect demonstrations? This guide walks through each layer and ends with a table of what every robot in the WBH database publishes.

1. The manufacturer SDK: joint-level and high-level control, usually in C++ with Python bindings.
2. Middleware: ROS 2, where the robot's streams become topics shared with the rest of the stack.
3. Robot descriptions: URDF and MJCF models of the robot's links, joints and inertia.
4. Simulators: MuJoCo, Isaac Sim, Gazebo.
5. Learning frameworks: reinforcement learning (Isaac Lab and makers' own environments) and imitation learning (LeRobot).
6. Teleoperation and data collection: operating the robot to record demonstrations.

The manufacturer SDK

The SDK is the layer every project uses, because it is how the maker exposes the hardware. It decides the languages you work in, how low you can go (joint torques and positions, or only walking commands) and which configurations allow it at all: several makers reserve secondary development for their EDU or developer variants, as the robot records show. Some SDKs are themselves built on DDS, which makes a ROS 2 bridge short; Unitree's, for example, is based on Cyclone DDS ^[1].

Middleware: ROS 2

ROS 2 connects the robot to the wider ecosystem: nodes exchange typed messages on a publish/subscribe graph ^[2], and frameworks such as ros2_control and MoveIt 2 bring control and motion planning. Official ROS 2 support ranges from complete workspaces to nothing; the ROS 2 getting-started guide covers setup in detail.

Robot descriptions: URDF and MJCF

A robot description is the model every other layer depends on. URDF is the ROS format for a robot's geometry and joint structure ^[3]; MJCF is MuJoCo's own scene format, and MuJoCo loads URDF too ^[4]. An official, maintained description from the maker is worth more than a community model: simulation, planning and learned policies are only as accurate as the model they use.

Simulators

MuJoCo is a general-purpose physics engine for articulated structures in contact, open source since May 2022 ^[4]. Isaac Lab is a robot-learning framework built on NVIDIA Isaac Sim, aimed at reinforcement learning, learning from demonstrations and motion planning ^[5]. Gazebo is the simulator paired with each ROS 2 distribution ^[6]. Many humanoid makers publish MuJoCo or Isaac environments for their robots; Gazebo launch files are rarer, so check the development table before assuming one.

Learning frameworks

Reinforcement learning is how most current walking controllers are made, and the fastest start is a maker's own environments. Unitree's unitree_rl_gym, for instance, takes a policy from training through a second simulator to the real robot ^[7]. For manipulation, imitation learning from demonstrations is the common route; LeRobot provides a hardware-agnostic, Python-native pipeline to teleoperate, record and train policies, from small arms to full humanoids ^[8].

Teleoperation and data

Demonstrations have to come from somewhere, which makes teleoperation part of the development stack rather than a demo feature. Unitree's xr_teleoperate, for example, controls its humanoids from XR headsets such as Apple Vision Pro, PICO 4 Ultra Enterprise or Meta Quest 3 and has a recording mode that saves each episode as data ^[9]. Other makers publish their own teleoperation apps; the robot records list them under development.

What each robot publishes

The table below is built from the WBH robot records. A filled dot means the maker publishes official support, a half dot means community or third-party support, and a dashed circle means nothing is published, which is not the same as unsupported. Follow the robot's link for versions, packages and sources.