Hey friend,
If you have been following along with this fundamentals series you now understand a lot about the physics, math and control ideas behind humanoid robots. From ZMP and Jacobian to MPC, imitation learning and compliant actuators.
How do you actually put all these pieces together into a real working robot? That’s where ROS2 comes in. ROS2 is the popular framework for building complex robot software and its widely used in humanoid development. From research labs to companies like Figure and even parts of Optimus-related work.
I still remember the time I ran a multi-node ROS2 system on a small robot. Suddenly different parts of the code could talk to each other cleanly. The whole project felt much more organized. Today I’ll walk you through the basics: nodes, topics and services with a humanoid perspective.
What Is ROS2?
ROS2 is a set of tools and libraries that help you build robot applications as a collection of independent programs that communicate with each other. It handles the parts like messaging, timing and running everything on one or multiple computers.
The big idea is to break your humanoid control system into manageable nodes instead of one giant program.
Nodes The Building Blocks
A node is a process that does one specific job.
In a humanoid robot you might have nodes like:
– `joint_state_publisher` which reads motor encoders and publishes current joint positions
– `imu_sensor_node` which reads the Inertial Measurement Unit for balance data
– `foot_force_sensor_node` which processes data from force/torque sensors in the feet
– `walking_controller_node` which runs ZMP or MPC algorithms. Decides where to step next
– `arm_trajectory_node` which plans arm movements using minimum-jerk trajectories
– `hardware_interface_node` which sends commands to the actual motors or simulation
Each node runs independently. If one crashes the others can often keep working. Very useful when you’re debugging a 30+ DOF humanoid!
Topics, The Main Communication Channel
Topics are the common way nodes talk to each other. They use a publish-subscribe model.
Examples in a humanoid:
– `/joint_states` topic, published by the hardware node, subscribed by controllers and visualization tools
– `/cmd_vel` topic for high-level velocity commands
– `/camera/image_raw` for vision data
– `/balance/state` for real-time CoM, CoP and ZMP information
A node can publish data to a topic and any number of nodes can subscribe to receive it. This is perfect for streaming sensor data and commands at frequency.
Services, Request and Response
When you need a one-time “question and answer” interaction you use services.
Examples:
– A node calls a service `/move_arm_to_pose` with a target position. Gets a success/failure response.
– `/get_robot_state` service to request battery level, joint limits or calibration data.
– `/calibrate_imu` service to zero the sensors before starting a walk.
Services are synchronous. The client waits for the server to reply. This makes them great for actions that should complete before the step.
A Simple Humanoid Example
Imagine you want to command the robot to walk forward:
1. A level `navigation_node` publishes a message on the `/cmd_vel` topic.
2. The `walking_controller_node` subscribes to `/cmd_vel` runs its MPC or ZMP planner. Publishes target joint trajectories on `/joint_commands`.
3. The `hardware_interface_node` subscribes to `/joint_commands` and sends the motor commands.
4. Meanwhile the `sensor_fusion_node` publishes real-time balance data on `/robot_balance_state` that the walking controller can use.
All of this happens asynchronously. In real time.
My Personal Take
ROS2 isn’t perfect. Its incredibly powerful for humanoid development. It lets different teams work on parts without stepping on each others toes. Once you get comfortable with nodes, topics and services you can start plugging in all the concepts we’ve covered. Many real humanoid projects use ROS2 as the backbone.