The gears that make up a robot: the loops in and around it, each running at its own rate

What happens inside a robot in one second

Take the one second it takes a humanoid to reach for a cup. If its motor drivers run at 20 kHz, the current loop runs about 20,000 times in that second. Over the same second, 500 joint commands go out, the policy issues 50 actions, and the camera captures 30 frames. Meanwhile, the VLA (vision-language-action model) regenerates its action chunk (the batch of actions to execute next) a few times.

Now suppose the policy moving this arm finished training last week and is due to be retrained in a few weeks. Line all these numbers up by period and they range from tens of µs to several weeks. To put it dramatically, one period of a 40 kHz current loop (25 µs) and one week differ by a factor of more than 10 billion.

As I promised in the About this blog post, I’ll use a single widget to show how the robot’s components, each running at a very different speed, fit together.

The robot’s components on one time axis

Try the following in the widget.

• Switch the robot type from Biped humanoid to Fixed arm. The locomotion policy, part of state estimation, Nav2 and odometry are dimmed, because a fixed arm doesn’t need them.
• Find the loops that stay lit whichever type you pick: the current and PD loops in the driver, and the training loops. They stay because every robot is built on them.
• Select a bar to open its loop card. Whatever kind of robot interests you, the card gives you what you need to start understanding it.

I’ve grouped the loops into six layers, starting from the fastest: current and joint servo, joint commands and bus, whole-body control, perception and navigation, policy and data, and training and operations. How these layers connect in the legs and in the arms is covered in the From a goal position to joint torquesComing soon and From policy output to the current loopComing soon lessons, respectively.

How to read a single loop: the loop card

A loop repeats three steps at a fixed period: it measures, computes and actuates. A joint servo loop, for example, reads the joint angle from the encoder, computes the torque to apply from the error between that angle and the target, and drives the matching current through the motor. In this series, I’ll summarize each loop in five fields and call the result a loop card.

Figure 2. One loop and its loop card. “Relies on” lists the conditions that must hold for the rest of the card to be true.

Here is the card for the joint servo (PD) loop inside the motor driver.

• Period: a few kHz to tens of kHz. It often runs at the same rate as the current loop (ODrive 8 kHz, moteus 30 kHz, Mini Cheetah 40 kHz).
• Input: the target angle, target velocity, gains and feedforward torque sent by the onboard computer, plus the joint angle measured by the encoder.
• Output: a torque (current) command.
• Relies on: the current loop producing the commanded torque with almost no delay.
• If late or stopped: if commands from the higher layers stop arriving, the driver holds the last target or switches to a damping mode (this varies by implementation). If the PD loop itself runs late or stops, the joint oscillates, or the driver faults and cuts torque output.

From here on, I’ll open the overview lessons for the other parts with a card in the same format. For example, see the From 50 Hz commands to joint torquesComing soon lesson.

What each layer does

• 1. Current and joint servo (tens of µs to 1 ms): PWM switching, the current loop (FOC) and the PD loop run inside the motor driver. The onboard computer doesn’t control this layer directly; it only sends targets. This layer has to respond within microseconds, so the motor driver handles it itself. (From motor to jointComing soon, Joints do not stop at the commanded angleComing soon)
• 2. Joint commands and bus (hundreds of µs to a few ms): the onboard computer sends targets to the drivers. The official G1 SDK example sends low-level joint commands every 2 ms (500 Hz). (The structure of a joint commandComing soon, Designing real-time control systemsComing soon)
• 3. Whole-body control (1 ms to tens of ms): the body’s state is estimated from IMU and joint readings, and whole-body control and the locomotion policy run here. If you model a robot whose center of mass is 0.7 m high as an inverted pendulum, its time constant is √(0.7/9.81), about 0.27 s. Left alone, any tilt grows by a factor of about 2.7 (e) every 0.27 s, so the balance loop has to run at a much shorter period than that. (Why robots stay uprightComing soon, Whole-body control as a QPComing soon)
• 4. Perception and navigation (tens of ms to seconds): cameras typically run at 30 Hz and LiDAR at around 10 Hz. The Nav2 controller runs at 20 Hz by default, and global path replanning at about 1 Hz. (What a vision system gives the robotComing soon, Navigating to a goal with Nav2Coming soon)
• 5. Policy and data (tens of ms to minutes): a VLA regenerates its action chunk a few times a second (about 1–10 Hz), and the actions in a chunk execute one at a time at 10–120 Hz. Teleop input runs at 10–60 Hz, and demonstration recording at 10–50 Hz. Where the VLA runs depends on the design and the situation. (How VLAs output actionsComing soon, Where teleoperation fits in the robot stackComing soon)
• 6. Training and operations (seconds to weeks): training in simulation, fine-tuning, evaluation and retraining belong here. A simulator’s physics step (200–1000 Hz) is measured in simulated time, so don’t confuse it with wall-clock time. (The training pipeline is one of the slowest feedback loopsComing soon, The role of simulatorsComing soon)

The table below lists two representative loops per layer. The ranges are typical and vary somewhat between implementations. Product and SDK figures are as of October 2026.

Why each layer runs about 10 times slower than the one below

Let’s follow one representative loop per layer along the time axis, from the lower layers up to the higher ones. The current and PD loops run at tens of kHz, joint commands at 500 Hz, actions at 50 Hz, and VLA chunk regeneration at a few Hz. Each step up a layer is at least 10 times slower.

Nesting a slower loop from a higher layer (the outer loop) around a faster loop from a lower layer (the inner loop) is called cascade control. When you design the outer loop, you treat the inner loop as a component that follows its command almost immediately. For that assumption to hold, the rule of thumb is to set the outer loop’s bandwidth 5–10 times lower than the inner loop’s. If the inner loop isn’t fast enough, its lag adds to the delay the outer loop sees, and the outer loop becomes prone to oscillation.

This rule of thumb relates bandwidths, not update rates. That’s why PWM, the current loop and the PD loop inside the driver often run at the same rate. moteus runs both its position/velocity loop and its current loop at the switching frequency (30 kHz by default). (Control essentials: PID, bandwidth and cascade controlComing soon)

Four ways to connect loops running at different rates

• Hold and interpolation: the fast loop either holds each slow command until the next one arrives (zero-order hold, ZOH), or fills in the values between two commands (interpolation). With hold alone, the target angle the driver tracks jumps each time a new command arrives (every 20 ms at 50 Hz). In between, the driver keeps using the previous value, so its target is on average 10 ms (half the command period) out of date. Interpolating between the two most recent commands, as in the widget below, makes the target change smoothly but delays it by a full period (20 ms), because the driver can’t connect two commands until the second one has arrived.
• Decimation: the slow loop runs once for every N runs of the fast loop. In unitree_rl_gym’s G1 training config, the physics simulation steps 200 times a second (200 Hz), and the policy outputs a new action only once every 4 steps. That’s why the policy runs at 50 Hz.
• Action chunking: one slow inference outputs actions for several steps at once, and a faster loop executes them in order.
• Timestamp alignment: each sensor runs at its own rate, so before combining their readings, you align them by when each one was measured.

Try the following in the widget.

• With the Sine target, change the command rate from 500 Hz to 50 Hz hold. The target angle jumps by about 3° every 20 ms, and the torque spikes at each jump, producing about 2 Nm of torque ripple. This is one reason motion can look choppy during teleop.
• Switch to 50 Hz interpolated. The torque ripple disappears, but the target lags by about 20 ms (versus 10 ms on average with hold alone).
• Set the time scale to 2–4 ms and count how many times the current loop runs during one joint command (2 ms). It runs 40 times, because the current loop runs at 20 kHz and joint commands at 500 Hz, so their periods differ by a factor of 40. Shrink the time scale to 100 µs and a single PWM period (50 µs) becomes visible.
• Open “Settings” and lower Kd to 0. Only viscous friction is left to damp the motion, so the oscillation takes a long time to die out (time constant about 5 s). Set Kd back to its default of 0.8 and the joint settles within a second, because Kd produces a braking torque proportional to velocity.

(The contract between actions and the controllerComing soon, Why ACT and Diffusion Policy output actions in chunksComing soon, Which moment a camera timestamp recordsComing soon)

When a higher layer runs late or stops

Let’s go back to the last field of the loop card. Even when a higher layer runs late or stops, the lower layers keep running. That’s why the decision to stop belongs in the fastest, lowest layer. A watchdog that checks for lost communication every cycle, overcurrent shutdown in the driver, and an E-stop built as a hardware circuit are all examples.

Whether a loop can move off the robot (to an edge server or a data center) comes down to its period, its tail latency, how it handles a dropped connection, and how much data it moves.

The influence also runs the other way. Battery state and motor and board temperatures change slowly, yet they set the limits of the fast loops. When the voltage sags or the temperature rises, the current limit is often lowered (derating), and the torque the joints can deliver drops with it.

(Safety functions belong in the fastest loopComing soon, Which loops can move off the robotComing soon, How thermal and battery constraints affect controlComing soon)

Common misconceptions

(Debugging training–deployment mismatchesComing soon)

Key terms

• Loop: a process that repeats measurement, computation and actuation at a fixed period
• Period and frequency: the time a loop takes to run once (period) and the number of times it runs per second (frequency). At 500 Hz, the period is 2 ms.
• Bandwidth: the highest frequency at which a loop can still properly track changes in its target
• Cascade control: a structure that nests a slower loop from a higher layer (the outer loop) around a faster loop from a lower layer (the inner loop)
• Decimation: running a slow loop once for every N runs of a fast loop
• Action chunk: a batch of actions covering several steps, output by a policy in a single inference
• Watchdog: a monitor that switches to a safe behavior if a command doesn’t arrive within a set time

Symbols and Korean–English term pairs are collected in the Notation and glossaryComing soon lesson.

Series contents: the robot’s components

I’ll cover the loops in this article in detail in the lessons below. For each topic, I’ve listed one main lesson.

Wrapping up

As the series goes on, I’ll take the bars on the time axis one at a time. In the next lesson, I’ll go down to the fastest, lowest layer and explain why a joint doesn’t stop at the commanded angle. Next lesson: Joints do not stop at the commanded angleComing soon