Three loops nested inside every joint

Spec sheets list torque, speed and mass, but a humanoid joint is also a stack of feedback loops running at very different speeds. At the top, a whole-body controller or learned policy on the robot’s main computer decides where each joint should go. In the middle, the joint drive turns that target into a torque request using a spring-and-damper law. At the bottom, a field-oriented current loop in the same drive switches the motor phases so the motor actually produces that torque. Each loop is roughly an order of magnitude faster than the one above it.

The split exists because each layer has a different job. The policy needs to see the whole body and plan, which is computationally heavy, so it runs slowly. The torque law has to react to contact within a millisecond or less, so it runs in the drive next to the encoder. The current loop has to track a motor with very low inductance, so it runs as fast as the power stage switches. Ben Katz’s thesis on the MIT Mini Cheetah actuator is a clean public example: the drive switches at 40 kHz, closes the current loop at 40 kHz and runs the joint PD law synchronously with it.

The five-number command

Most learned humanoid controllers do not send raw torques to the joints. They send a target position, and the drive turns it into torque with a proportional-derivative law: torque equals a stiffness gain kp times the position error, plus a damping gain kd times the velocity error, plus an optional feed-forward torque. Radosavovic and colleagues’ Digit controller is typical. The network runs at 50 Hz and outputs PD setpoints for 16 joints, plus predicted PD gains for 8 leg joints, while the joint PD controller runs at 1 kHz.

The low-cost actuator world has made this law into a wire format. The so-called MIT mode, inherited from the Mini Cheetah driver, packs five numbers into one CAN frame: desired position, desired velocity, kp, kd and feed-forward torque. CubeMars (T-Motor) documents the command for its AK-series motors. RobStride, whose modules appear in many Chinese humanoids and research robots, uses the same five fields over 1 Mbps CAN. Its documentation gives kp ranges of 0 to 500 and kd of 0 to 5 on the small RS-00 to RS-02 and RS-05 motors, rising to 5,000 and 100 on the larger RS-03, RS-04 and RS-06.

Sending gains as well as targets is what makes a joint compliant on demand. A high kp holds a pose stiffly. A low kp lets the limb give way when it touches something, and the controller can change that between one 20 ms tick and the next without touching hardware. This is impedance control, and it only works well if the joint is back-drivable and the inner loop is much faster than the outer one.

Published loop rates, robot by robot

Commercial humanoid makers rarely publish inner-loop rates, so most hard numbers come from research platforms and actuator documentation. The pattern is consistent anyway. Policies run at about 50 Hz, the bus runs at 1 to 4 kHz, and the drive’s own loops run from 1 kHz to 40 kHz.

The bus in the middle: CAN or EtherCAT

The fieldbus sets how often the main computer can update every joint, and it is a real bottleneck. Classic CAN runs at 1 Mbps and is shared by every motor on the line. Katz puts the theoretical limit for the Mini Cheetah at about 4 kHz divided by the number of actuators on a bus. In practice the team reached 1.2 kHz on a three-motor leg. That is why legged robots built from CAN modules split their joints across several buses, typically one per limb.

EtherCAT, the industrial Ethernet standard used by most cobot joints, removes most of that limit. Berkeley Humanoid runs its EtherCAT network at 1 to 4 kHz, with a maximum latency of 0.5 to 2 ms depending on the rate chosen. Synapticon specifies its Circulo integrated joint drives at up to 4 kHz on the standard DS402 servo profile, with FailSafe over EtherCAT for safety data. The cost is more expensive drive electronics and a master controller. That trade explains why bus choice tends to follow price class: CAN for low-cost modules, EtherCAT for industrial and higher-end humanoid joints.

What it means for buyers and builders

• Ask where the PD law runs. A joint that closes its impedance loop in the drive, at kHz rates, will behave consistently whatever the main computer is doing. A joint that waits for torque commands over the bus inherits the bus’s latency and jitter.
• Check the command interface. MIT mode (position, velocity, kp, kd, torque) is now a de facto standard on CAN modules from CubeMars and RobStride, which makes these actuators easy to drop into reinforcement-learning stacks. EtherCAT DS402 drives offer the same modes through a standard industrial profile.
• Gains are part of the spec. Gain range sets how stiff or soft a joint can be made. A 0–500 kp range on a small module and 0–5,000 on a 120 N·m one reflect very different load cases.
• Sim-to-real depends on the inner loop. Learned policies are trained against a model of the PD loop and the motor. The OmniXtreme G1 work models torque-speed limits, friction and back-EMF power limits for each motor type, because an inner loop that behaves differently from the simulator is a common cause of failed transfers.

FAQ

Sources