BLOGS

Every humanoid joint datasheet leads with torque, ratio and encoder bits. Almost none of them lead with the brake — the small spring-loaded disc buried between the motor and the reducer that is the only thing holding the robot upright the instant power disappears. A widely discussed Chinese industry piece on October 26, 2026 asked the deceptively simple question "does a robot joint even need a brake?" — and the fact that experienced builders still argue about it is exactly why the topic deserves a first-principles answer. The short version: most gravity-loaded joints need one, the interesting engineering is in everything the one-line spec omits, and the details — engage delay, float, wear, coil power — quietly shape the whole joint.

Why a Joint Needs a Brake at All

A joint has exactly two ways to hold a position: push back with motor current, or lock mechanically. The first one dies with the power supply. The moment a robot loses bus voltage — battery drop, e-stop, connector fault, a crashed controller — the current loop disappears, and every gravity-loaded joint in the body becomes a pendulum. Knees, hip pitch, ankle, waist pitch and a lowered elbow all have a lever arm between the joint axis and the center of mass, which means they all have a gravity torque trying to fold the robot into the floor.

A spring-applied brake solves this passively. Its default state — zero power, zero software, zero communication — is engaged. A stack of friction discs is clamped by preloaded springs onto a hub on the motor shaft; energizing a coil pulls an armature plate against the springs and releases the discs. This is the correct default for a safety-relevant function: the failure mode of the mechanism is "hold still," not "move."

The second job is economic. Holding a knee against gravity with the motor costs continuous current, and continuous current means continuous copper loss inside a sealed limb. Take a realistic case: a knee holding 40 N·m through a 100:1 reducer at roughly 80% efficiency needs about 0.5 N·m of motor torque. With a torque constant near 0.05 N·m/A that is 10 A, and 10 A through 0.3 Ω of winding resistance burns about 30 W — forever, in a cavity with no airflow. Engage the brake and the motor current drops to zero while the robot stands still. The brake turns a heating problem into a clamping problem, and clamping costs nothing.

The brake also decouples "position" from "power-on." A parked humanoid with brakes engaged can be transported, flashed, charged or inspected with its drives dead — and its posture will not move a milliradian.

Fail-Safe by Spring, Not by Software

Everything in a modern joint is software-defined except the brake, and that is the point. Drives expose safety functions such as Safe Torque Off (STO) and Safe Brake Control (SBC) standardized in IEC 61800-5-2: STO guarantees the inverter cannot produce torque, and SBC is the logic that commands an external brake. The drive provides the decision; the spring-applied brake is the muscle. A safety function that ended in "the motor will hold position" would be a fiction — current-based holding evaporates with any single electrical fault, which is precisely what safety functions exist to cover.

This is also why a brake is a parking brake, not a service brake. It engages at standstill, holds indefinitely with zero energy, and stays out of the torque path while the joint is moving. Dynamic stopping is the drive's job — the motor can decelerate the joint along a controlled torque profile and the brake simply catches the handoff at the end. Asking a small friction disc to routinely absorb full-speed stops is how linings turn into dust.

The Engagement Delay Is the Whole Ballgame

The dangerous moment is not "power off, holding." It is "power off, falling, brake not yet engaged." A spring-applied brake has a mechanical engage time — the armature must collapse, the springs must clamp, the friction surfaces must build torque — typically somewhere between tens and a few hundred milliseconds depending on size and design. During that window, a gravity-loaded joint is in free fall, and free fall is brutally quantified:

Two hundred milliseconds of latency turns a "safe stop" into a face-plant. This is why competent power-fail sequences never rely on the brake alone: the drive uses residual bus energy to keep actively braking the joint through the delay, and the brake engages only when the joint is nearly stopped — or the controller pre-emptively ramps the joint toward a safe posture the moment a fault is detected. The engage-time spec on the brake datasheet is not a formality; it is the number that decides how much of the fall the motor has to catch.

The energy accounting is similarly lopsided. The kinetic energy stored in a swinging limb is small — a 0.05 kg·m² limb at 3 rad/s carries just 0.5 × 0.05 × 9 ≈ 0.23 J. What the brake actually absorbs during a botched handoff is gravity work: a joint fighting 40 N·m of gravity torque that rotates 0.1 rad before locking has already converted 4 J into motion, nearly twenty times the kinetic term. Every millisecond of delay multiplies that number.

Static Torque, Dynamic Torque, and Thermal Reality

Brake datasheets quote two torque numbers, and they are not the same number. Static holding torque — the clamp at zero speed — is the large one, and sound design practice is to size it at roughly 1.5 to 2 times the worst-case static gravity torque of the joint including payload, leaving margin for friction-coefficient scatter, lining wear, vibration and contamination. Dynamic braking torque — the torque available while slipping — is lower, because the friction coefficient falls with sliding speed and the lining heats up. A brake that holds 20 N·m at standstill may deliver noticeably less while the joint is still rotating through the stop.

That gap matters because the brake's thermal capacity is tiny. It is a passive stack of steel and friction material inside a sealed joint, not a ventilated industrial brake. One emergency stop is fine — a few joules spread over a small disc. A control scheme that "brakes into position" on every cycle will cook the lining, shift the friction coefficient, change the air gap as the facing wears, and eventually produce a brake that no longer holds its nameplate torque. The brake is a wear part with a cycle life defined at a specific absorbed energy, and it belongs on the same maintenance ledger as every other wear item in the joint.

Where the Brake Sits — and Why Its Backlash Is Multiplied

In nearly every integrated joint, the brake sits on the motor shaft, before the reducer. That placement buys the biggest advantage in the book: the brake only has to hold motor-side torque, which is the joint torque divided by the gear ratio. Holding 40 N·m at the output of a 100:1 reducer takes a 0.5 N·m-class brake — grams of springs and a coin-sized disc. Put the same brake after the reducer and it must be rated for the full 40 N·m: heavier, larger, slower, and harder to fit inside a sealed cylindrical joint.

The cost of that placement is precision. Any rotational float in the brake's hub and disc — spline clearance, spline wear, armature plate slop — happens upstream of the gear ratio, and the ratio multiplies it at the output. A float of just 0.01° at the motor shaft of an 80:1 joint becomes 0.8° of drift at the flange before the discs bite. This is why brake hubs are splined rather than keyed, why the float specification is quoted in fractions of a degree at the motor shaft, and why "brake backlash" is a real line item when a joint's overall lost-motion budget is assembled. It also explains a subtle commissioning step: after the brake engages and releases thousands of times, wear in the spline shows up as slowly growing position scatter on power-up — long before anything slips.

The alternative — sensing position only downstream of the brake and re-homing after every power cycle — trades the float problem away and buys a startup ritual instead. Multi-turn absolute sensing behind the brake is how production joints avoid both.

Backdrivability Decides Who Needs One

The brake requirement tracks almost perfectly with how easily a joint backdrives — how willingly an external load can turn the motor through the transmission:

Two misconceptions live in this table. First, "high ratio means self-locking" is wrong: a strain wave gear's internal friction resists backdriving but is neither specified nor repeatable enough to be a holding device — treat any geared joint as backdrivable unless the transmission is explicitly self-locking by design. Second, the linear joints that carry the heaviest loads are also the most eager to backdrive; a roller screw under body weight will happily convert the robot's weight into screw rotation, which is why every serious linear knee and hip pairs its actuator with a brake. The backdrive-vs-reduction trade runs through the whole direct drive or reducer architecture debate, and the brake is the quiet tax collected on whichever side wins.

Research is exploring brakes that need no holding power at all — electrostatic clutches that latch individual joints of underactuated robots without continuous current — but these remain lab-stage for humanoids. Source: "Electrostatic Brakes Enable Individual Joint Control of Underactuated, Highly Articulated Robots," arXiv, 2022.

The Parasitic Load Nobody Budgeted

Here is the detail that surprises system engineers: releasing a brake costs continuous power for as long as the joint is moving. The spring holds for free, but the release coil — typically a 24 V winding drawing on the order of 5–10 W in joint-class brakes — must stay energized through every step, squat and reach, on every moving joint, simultaneously. In a robot with twenty to thirty actuated joints, brake coils alone can represent on the order of 100–300 W of parasitic load while the robot is active. That is not a rounding error in a machine whose entire thermal and energy budget is already contested — it competes directly with compute, and it lands as heat inside the same sealed cavities the windings occupy, on top of the thermal wall that already limits continuous joint torque.

This is one of the quiet arguments for architecture-level alternatives: gravity compensation springs that unload the brake, per-joint brake scheduling that parks idle joints instead of floating them, and drive-side strategies that de-energize coils whenever a joint is commanded to hold. Every watt reclaimed from a brake coil is a watt the battery and the heatsinks do not have to find.

What to Actually Check on the Datasheet

The brake line on a joint datasheet is usually one number. It should be at least nine:

Read against that list, the lightweight joint modules and humanoid actuator units worth buying are the ones where the brake appears as a specified subsystem — engage time, float, coil power, life — rather than a checkbox. And when a supplier's joint quietly omits the brake entirely on a gravity-loaded axis, ask exactly one question: what holds the robot up when the power dies? If the answer involves firmware, walk away.

The brake will never headline a launch event. It is small, it is invisible, and it does nothing — which is precisely its job. But the difference between a humanoid that collapses like a marionette at every power event and one that settles calmly into a parked stance is a spring, a disc and a spline — specified by engineers who read past the first number on the datasheet. Source: Chinese robotics industry discussion, "Does a robot joint need a brake?", Oct 26, 2026; joint wear behavior cross-checked against "How a Robot Joint Actually Wears Out" (Ti5ROBOT).