Four control layers, their update rates, and three common controller architectures.
This is Part 1 of our Physical AI series. Read the other articles: Part 2: Quadruped mechanics · Part 3: Quadruped market survey.
A quadruped controller coordinates joint motion, body balance, and foot placement. These tasks need different information and operate on different timescales, so most systems divide them across several control layers rather than handling everything in one loop.
Model predictive control, whole-body control, central pattern generators, and reinforcement learning are methods used within this arrangement. A robot may use several of them together, with each responsible for a different part of its movement. This article describes those responsibilities, the information each layer uses, and how the layers work together.
Suppose a quadruped is trotting at approximately 1 m/s when someone pushes it sideways. The disturbance reaches every control layer, but each responds on its own timescale.
The joints react within approximately 1 ms. As the push moves them away from their targets, each controller compares the measured position with the requested one and produces corrective torque from the error.
At this level, the controller uses only the local joint error, without information about the push, the robot’s balance, or its expected body motion. The calculation is small enough to run at 1 to 5 kHz, and some motor drives run faster still. Because it does not predict the effect on the rest of the robot, it resists the joint being moved even when yielding in the direction of the push would help recovery.
Within tens of milliseconds, the state estimator detects the unwanted body motion and the force planner adjusts the forces at the feet already on the ground. Those stance feet are commanded to push against the motion.
Many systems use model predictive control for this task. The planner calculates a sequence of actions over a short horizon, applies the first action, and then solves again using the updated state. The solution has to satisfy the robot model and its contact conditions, so its effectiveness depends on the accuracy of that model, the horizon length, the solver’s speed, and the quality of the state estimate.
The force planner specifies forces at the feet, while the actuators need commands at the joints. The whole-body controller makes that conversion, producing joint torques, positions, or velocities.
It works from the robot’s current geometry and enforces hardware and contact constraints: motor torque limits, joint travel limits, and the fact that a foot can push against the ground but cannot pull on it unless mechanically attached.
When the requested tasks conflict, the controller has to relax or drop one. Task weights or a strict priority order determine the compromise. Maintaining body height, for example, may give way to keeping the stance feet stable.
A few hundred milliseconds later, the footstep planner changes where the next foot will land. Placing it farther in the direction of the push widens the support area and helps arrest the body’s motion. The change takes effect during the chosen foot’s swing phase, since a foot carrying body weight cannot move to a new foothold.
Classical systems often choose footholds with a rule, such as moving the landing point farther forward as body velocity increases. Other systems use central pattern generators. Learned systems can also start with rhythmic priors to reduce training time.
These four responses correspond to the layers shown below. A particular control method may implement one layer, several layers, or almost the whole stack. Identifying which functions it performs makes it easier to understand how it fits into the complete system.
In principle, one controller could turn a velocity command directly into motor currents. The difficulty is meeting the computation deadlines with the information available at each stage.
A 1 kHz loop has 1 ms to sense, calculate, communicate, and issue its command. If it misses that deadline, the result is usually no longer useful and the actuator continues using the previous command.
At 4 kHz, a joint loop gets approximately 250 microseconds per update. That is enough for a small number of arithmetic operations, but usually too little for constrained optimization across every joint on the robot.
The footstep planner has a much longer interval to work with: a step can last approximately 300 ms. Running this planner at 4 kHz would produce thousands of candidate foot locations during a step, most of which would be discarded. That computation would also compete with the faster loops for processing time.
The joint controller has the measured and commanded joint states. It normally has no body velocity, terrain map, or future contact schedule. A faster processor cannot give it the missing information needed to choose a safe foothold.
The usual approach is therefore to provide each layer with the information its task needs and run it at the lowest rate that meets its deadline. The loops closest to the hardware can then remain simple enough to finish on time.
| Layer | Main output | Typical rate | Reported examples |
|---|---|---|---|
| Gait and footstep planner | Contact schedule and foot location | 10–100 Hz | Usually linked to step duration |
| Body-force planner | Force for each stance foot | 10 Hz–1 kHz | 30 Hz on Mini Cheetah; approximately 50 Hz for an iLQR planner on Go1, Go2, and H1 |
| Whole-body controller | Joint commands from desired body and foot forces | 200 Hz–1 kHz | 250 Hz on HyQ; 400 Hz on ANYmal; 500 Hz on Mini Cheetah and Go2 |
| Joint controller | Motor torque or low-level target | 1–5 kHz | 1 kHz on HyQ; 2.5 kHz on ANYmal; up to 20 kHz in Unitree internal controllers |
These rates are approximate. The rate used in a particular system depends on robot dynamics, model complexity, the solver, available processing power, and communication delay.
The upper layers use a state estimator to combine sensor measurements with assumptions about the robot model. This provides the body state and contact information that no single sensor can supply on its own.
Encoders report joint angles; joint velocity is usually derived from successive angle readings. The inertial measurement unit reports angular rate and linear acceleration, while motor current gives an estimate of motor torque. Some robots add contact switches or force sensors at the feet.
Proprioceptive sensors do not directly report global body position or body velocity. Nor does the robot directly know which feet are carrying load. Measuring the terrain ahead requires cameras or lidar.
The force planner particularly needs a reliable body velocity. Estimators often obtain it by combining inertial data with leg kinematics, assuming a stance foot stays fixed relative to the ground. Once that foot slips, the assumption starts to fail.
Contact state itself is often an estimate, so a mistake about contact can become a mistake about body velocity. Loose, uneven, or slippery terrain usually makes these errors worse. Motion capture can help in the laboratory, but it is rarely available in the field.
The total delay includes sensor sampling, filtering, the bus, communication between processes, computation, command transmission, and the actuator’s physical response. The controller has to account for their combined effect.
Even a short delay can consume a large share of the control period. A policy running at 50 Hz updates every 20 ms. If inference and communication also take 20 ms, the delay is a full policy period.
Simulation usually supplies exact states without noise or delay, whereas a hardware controller receives noisy estimates of an earlier state. Training and testing need to account for this difference before simulation results can be relied on for the physical robot.
Most systems still need all four functions. What changes is their implementation: fixed rules, optimization during operation, learned policies, or some combination of the three.
In a rule-based controller, the designer specifies the equations and schedules. A fixed gait schedule sets contact timing, a closed-form rule distributes the required body force among the stance feet, and inverse kinematics produces the joint targets.
The controller reacts to the current estimated state according to those rules. Its modest computation requirements and often lower dependence on a precise state estimate can make it robust.
Performance is limited by the terrain, disturbances, and gait transitions covered by the rules. Changes in robot mass or geometry usually require manual tuning as well. These controllers are common in introductory systems and are also used as fallbacks.
An optimization-based controller solves numerical problems as the robot moves. Optimal control or model predictive control can handle body forces, with a constrained quadratic program handling whole-body control. The gait schedule may stay fixed or come from a separate planner.
In this arrangement, force planning predicts future motion while whole-body control responds to the current state. The optimization problem can explicitly include motor limits, contact constraints, friction limits, and task priorities.
The result depends on the starting state estimate and the robot model, along with the horizon length, cost weights, constraints, solver tolerances, and available processing power. Physical effects omitted from the model will not be accounted for in the solution.
A learned controller maps observations to joint targets through a neural network. One network can take over the work of the gait planner, force planner, and whole-body controller.
At each update, the network usually runs a single forward pass. That execution is reactive, though training can encode behavior that anticipates what happens next. Some systems also adapt to changes in payload or terrain during operation.
The policy has to work with inputs the physical robot can supply. Training with exact body velocity, perfect contact state, or complete terrain geometry can leave it dependent on information the hardware does not have. State estimation, observation history, privileged-learning methods, noise, delay, and domain randomization are ways training must address that gap.
Much of the design work moves into the reward, training environment, curriculum, data distribution, and randomization. Diagnosing failures can be harder because the control functions are spread across the network’s parameters.
At the bottom of most quadruped controllers is a proportional-derivative law for each joint. A common form is:
τ = Kp·(q* − q) + Kd·(q̇* − q̇) + τff
Kp sets the stiffness response to position error, and Kd sets the damping response to velocity error. The upper layer supplies the feedforward torque, τff.
Learned policies often request joint positions, leaving this law to produce the motor torques, with target velocity commonly set to zero. Model-based controllers can likewise send joint targets to the manufacturer’s internal controller.
The gains are part of the complete controller because changing stiffness or damping changes the torque produced by the same policy output. When investigating a policy failure, it is therefore important to check the gain configuration as well.
When reading about an unfamiliar controller, it helps to identify which of the four control functions it replaces, which functions remain unchanged, and which measured or estimated states it requires. This describes its role in the system more precisely than the method’s name alone. It also helps locate where computation limits, model errors, estimation errors, and hardware delays may affect its performance.
© 2026 Gödel Machines · hi@goedelmachines.com · web version