Compliant Actuation and the Physics of Safe Human-Robot Interaction

Safe physical interaction between robots and humans isn't primarily a software problem. That framing is widespread, and it leads teams down a long road of patching software force limits onto hardware that fundamentally wasn't designed to yield. The physics of collision safety — the quantities that determine whether an unexpected contact injures a person — are rooted in actuator mechanics, not in the control layer running above them. Understanding that distinction changes how you specify hardware from the beginning.

The Physics of Collision Injury: Clamping Force and Energy

ISO/TS 15066, the technical specification that governs power-and-force-limiting collaborative robot operation, defines two primary injury mechanisms: quasi-static clamping force and transient impact energy. Clamping force applies when a body part is trapped between the robot and a fixed surface — the hazard is sustained compression. Transient impact applies when a robot limb strikes a person during motion — the hazard is kinetic energy transfer over a short duration.

For a humanoid robot operating in shared human spaces, the transient impact scenario is the more challenging one. A 50 kg bipedal robot with an arm moving at 1.5 m/s delivers meaningful kinetic energy on contact. The peak force experienced by the person depends on the collision contact stiffness — essentially, how quickly the robot decelerates on impact. A rigid actuator that cannot yield drives force levels up sharply. An actuator that complies — that absorbs energy mechanically before any software-level reaction can occur — keeps peak contact force within biologically tolerable limits.

The numbers matter here. ISO/TS 15066 specifies allowable transient contact forces by body region: 65 N for the skull, 75 N for the nose, 110 N for the neck, and 160 N for the sternum. A fast-moving rigid arm can easily exceed the skull threshold in the first few milliseconds of contact — before a software control loop running at 1 kHz has had time to issue a single command update.

Mechanical Compliance vs. Software Force Limits

Software force limits operate on sensed force data, apply a decision, and then command the actuator. That chain has irreducible latency: sensor sampling, filtering, control loop execution, and actuator response. In a well-engineered system, the total latency from contact to actuator response might be 2–5 ms. At 1.5 m/s arm speed, the robot has traveled 3–7.5 mm during that window. For soft tissue contact, that displacement is enough to cause injury before the software even begins to respond.

Mechanical compliance — physical spring elements or backdrivable reduction stages — responds at the speed of mechanics, not electronics. The actuator begins absorbing energy at the instant of contact, without waiting for any sensor or control loop. This is the core argument for Series Elastic Actuators (SEAs) in human-proximity robotics: the spring element decouples the inertia of the motor and gearbox from the contact force, spreading the collision impulse over time and reducing peak force.

Compliance isn't a safety feature you add in software after the hardware is chosen. It's a hardware property you either design in from the start or you don't have it when you need it.

ISO 13482 and the Robot Safety Certification Landscape

ISO 13482 is the international standard for personal care robots — robots intended to operate in direct contact or proximity with humans outside industrial fencing. Its risk assessment framework requires manufacturers to identify contact hazard scenarios, characterize the contact forces and energies involved, and demonstrate compliance with tolerable risk levels. ISO/TS 15066 provides the specific biomechanical force thresholds referenced in many ISO 13482 assessments for manipulator contact events.

Critically, neither standard specifies how compliance must be achieved — hardware spring elements, quasi-direct drive low-impedance actuation, torque-controlled strain-wave gearboxes, or software-limited force control all count. What they require is that the resulting system behavior, under the identified hazard scenarios, stays within the thresholds. That means teams can pass a risk assessment with software-only force limiting if they can demonstrate the actual contact forces stay within bounds. But demonstrating that requires empirical testing of worst-case contact scenarios, and the physics of latency make it genuinely difficult for high-speed joints.

How Backdrivability Changes the Safety Calculation

A backdrivable actuator — one where applying external force at the output can rotate the motor back through the reduction stage — exhibits low reflected inertia at the joint. The person contacting the joint effectively encounters the compliant load of moving the output against low mechanical impedance, not the full inertia of the motor rotor reflected through the gear ratio.

In a strain-wave gearbox with a reduction ratio of 80:1, the motor rotor inertia reflected to the output is amplified by 80² — a factor of 6400. Even a small motor with 0.001 kg·m² rotor inertia presents 6.4 kg·m² at the joint output in a non-backdrivable design. That reflected inertia is what drives peak contact force during an unexpected collision. Backdrivability doesn't eliminate that inertia, but it allows the motor to be physically back-driven during the contact event, dissipating energy rather than reflecting it as a force spike.

This is why we designed backdrivability into our strain-wave reduction stage rather than relying entirely on closed-loop force control for compliance. The torque threshold above which the joint enters compliant mode is set at the hardware level — it will always be enforced regardless of what the control loop is doing. Software force limits are a second layer on top, not the primary safety mechanism.

Practical Design Choices for Human-Proximity Actuators

Teams specifying actuators for human-facing robots should evaluate the following properties explicitly:

• Reflected inertia at the output: lower is safer under collision; compute from motor rotor inertia and gear ratio squared
• Backdrivability threshold: some strain-wave gearboxes backdrive only under high load; the threshold matters for collision safety at operating speeds
• Force-torque sensor bandwidth: a 3 kHz sensor loop provides meaningful improvement over a 1 kHz loop for fast contact detection, but sensor bandwidth alone doesn't compensate for high reflected inertia
• Control loop latency: measure end-to-end from contact event to first actuator command change, not just loop frequency
• Mechanical energy absorption: series elastic elements or compliant housings can absorb meaningful energy during the first milliseconds of contact before any control response

None of these properties are visible from a standard commercial actuator datasheet. You have to test them, or obtain verified test data from the manufacturer. In our experience, the teams that build the safest human-proximity robots are the ones that specify safety requirements at the hardware selection stage — not the ones trying to meet ISO 13482 contact force limits through software tuning after the platform is assembled.

Building for human-robot interaction requires an honest assessment of what your hardware can and cannot guarantee without software. Get that clarity early, and the control engineering becomes much more tractable.