Introduction
A humanoid controller is a stack of loops running at different rates. Cameras and language models can operate slowly compared with balance, joint and motor-control loops. Mixing those layers into one number creates bad comparisons.
The useful way to inspect a humanoid is to follow one command from perception to physical torque and ask what data crosses each interface, how often it updates, what happens when data is late and which layer can stop the robot.
Key facts
- High-level perception, planning and low-level motor control usually run on different hardware and update schedules.
- A configured software period is not proof of achieved real-time timing or a motor drive's internal loop rate.
- State estimation combines joint, inertial and sometimes external perception before whole-body control can act on the robot.
- Safety functions need defined behavior when commands, sensors or network links become stale.
The control path from sensors to motors
A common chain is sensors → state estimation → task or motion planning → policy or trajectory generation → whole-body controller → joint position, velocity or torque targets → motor drives. Some robots add a safety controller that can limit or stop motion independently of the main compute stack.
The architecture can differ by task. Walking may use a dedicated locomotion controller while the arms follow a manipulation policy. Whole-body tasks need coordination so arm motion does not destabilize the base.
Why controller rates need context
A 500 Hz command-writing loop means the software attempts to publish a command every 2 ms. It does not prove the operating system met every deadline, that the network delivered every packet on time or that the current loop inside the motor drive also runs at 500 Hz.
When comparing systems, ask for configured rate, measured average period, jitter, missed deadlines and the rate of the layer being discussed. Those numbers answer different questions.
What the Unitree G1 SDK example shows
The official G1 dual-arm example initializes a 0.002-second control interval and schedules separate control and command-writer threads. It reads joint position and velocity plus IMU data, then publishes position and velocity targets, feed-forward torque and proportional and derivative gains through LowCmd.
That source supports a description of one SDK command path. It does not establish every controller used on G1, the internal motor-drive current-loop frequency or the inference rate of a learned policy.
Where latency and failure appear
Camera pipelines can add frame exposure, transport, inference and synchronization delay. Networked commands can arrive late or out of order. State estimates can become stale after sensor loss. A robust controller needs timeout behavior and a safe state rather than continuing indefinitely with old commands.
For manipulation, measure end-to-end latency from observation timestamp to actuator command as well as local loop timing. For balance, also inspect estimator delay and whether safety limits remain active when high-level compute restarts.
Questions to ask a vendor or research team
Ask which loops run on the robot, which run offboard, their configured and measured rates, the communication transport, timestamping method and failure behavior. Request a diagram that names the safety controller, planner, policy, estimator and motor interface.
For learned controllers, ask which outputs the model produces. A policy that outputs end-effector goals has a different control responsibility from one that outputs joint targets or torques directly.
Limitations and missing information
- The Unitree source is one example program and does not document the complete proprietary control stack.
- No timing trace, jitter benchmark or motor-drive measurement was performed by TechniaHQRobot.
- Controller architecture can change with firmware, task and optional hardware.
Conclusion
Controller-rate claims become useful when the layer, measurement method and failure behavior are stated. A reader should be able to tell which loop keeps the robot balanced, which software plans the task and which interface finally commands the joints.
Sources and methodology
The official Unitree SDK2 G1 dual-arm source was inspected. The 500 Hz figure is calculated from its configured 0.002-second interval and is described as a software setting, not a measured motor-loop rate.
Related TechniaHQRobot guides
Share this article
Share the current TechniaHQRobot article page.
Continue reading
Open the latest robotics reporting, Physical AI analysis and hardware notes.