The difference between a robot that can carry a fragile component and one that crushes it is not fundamentally a mechanical question — it is a control question. The hardware can be identical in both cases. What determines the outcome is whether the control system knows how much force it is applying, can detect the moment that force is becoming too large, and can respond fast enough to prevent damage. This is the domain of torque-aware, compliant motion control, and it is the area of the design stack where the quality gap between humanoid robot architectures is most consequential for factory deployment.
Position Control Versus Torque Control: The Core Distinction
Most industrial robots run position control at the joint level: the controller commands a joint to move to a specific angular position, and the servo drive applies whatever torque is necessary to get there. The system is "stiff" — it resists external forces because the control loop sees a position error and corrects it aggressively. For high-speed, high-repeatability tasks with known part geometry, this is exactly what you want. The robot goes where it is told, every time, at the commanded speed, regardless of external perturbations.
The failure mode of pure position control becomes apparent when the task involves contact with objects that have compliance, positional uncertainty, or fragility. If a position-controlled arm reaches for a component that is 3mm off its expected position, the arm will execute the commanded trajectory regardless — it may jam the component into the fixture, apply force well above the design limit, or damage a precision surface. The controller has no native awareness of the forces being generated; it only knows that there is a position error to correct.
Torque control inverts this. At each joint, the controller targets a torque (or equivalently, a desired interaction force at the end-effector) rather than a position. The joint moves to achieve the desired force state, and position emerges as a consequence. A torque-controlled robot reaching for a part that is slightly off-position will comply with the part's actual location rather than driving past it. This compliance is not passive — it is actively maintained by the control loop at every timestep.
How Atom's Joints Sense Torque
Atom's actuator design places a strain-gauge torque sensor in series with the output of each joint's gearbox, between the gearbox output shaft and the link it drives. This is the Series Elastic Actuator architecture, extended with high-resolution torque measurement. The torque sensor reads the actual load on the joint in real time, at measurement bandwidth high enough to feed the primary control loop.
This architecture has a well-known trade-off: the series elastic element introduces some compliance in the kinematic chain, which marginally reduces position repeatability compared to a fully rigid joint. For a manufacturing robot doing micron-level precision positioning on a milling machine, this is a disqualifying limitation. For a humanoid doing assembly tasks with tolerance requirements in the 0.3–1.0mm range — inserting a connector, seating a bracket, placing a sub-assembly into a fixture — the compliance is within acceptable limits, and the force awareness it enables is worth the exchange.
The measurement loop runs at 1kHz at the joint level. The primary motion control loop operates at 500Hz, consuming joint torque data as a primary input. This gives the system sufficient bandwidth to detect contact events — a 50–200ms timescale for human-pace assembly tasks — and adjust output torques before forces reach levels that would damage parts or fixtures.
Whole-Body Dynamics and the Payload Problem
A humanoid robot carrying payload changes its inertial properties in ways that a fixed arm does not have to contend with. A fixed arm's base is mounted; the payload affects the arm's dynamics but not the base. A humanoid that picks up a 6kg casting and begins walking toward the output station has a changed centre of mass, a changed inertia tensor, and changed joint torque requirements for the locomotion task. The motion controller needs to account for these changes continuously, not as a recalibration step each time payload changes.
Atom's whole-body controller models the robot plus estimated payload as a unified dynamic system. The payload estimate is not a fixed number entered by an operator — it is derived continuously from the joint torque readings during the lift, using the known kinematics and the measured torque deviations from the zero-payload baseline. This estimated payload feeds the whole-body dynamics model, which in turn feeds the locomotion gait generator with updated stability margins and foot force targets. The result: gait adjusts when carrying heavy components without requiring a mode switch or operator input.
The practical scenario this addresses: a robot at a Kanto-area auto parts facility transferring engine sub-assemblies (8–10kg) from a machining station to a quality inspection fixture 4 metres away. The transfer requires stable bipedal locomotion across the shop floor, followed by precise placement into the inspection fixture with known positional repeatability. Without payload-aware dynamics, a robot optimised for zero-payload locomotion will either over-compensate (stiff, slow gait that increases cycle time) or under-compensate (gait instability at higher payload that degrades the placement accuracy). Continuous payload estimation eliminates the need for that trade-off.
Force Limits and the Safety Integration
Torque-aware control creates a direct path from physical interaction policy to safety behaviour. Rather than relying entirely on geometric proximity detection to stop the robot before contact occurs, the system can also respond to contact force directly: if a joint's measured torque exceeds a threshold corresponding to an unexpected interaction force — a human arm in the robot's path that the proximity sensors did not detect in time — the system can reduce output torques or halt within the response bandwidth of the control loop.
This is not a substitute for proximity sensing. The geometric detection layer is the primary safety mechanism, because stopping before contact is always preferable to stopping at contact. But torque-limit response as a secondary layer provides defence in depth: if proximity detection fails or the contact event is too fast for the primary stop to engage, the joint-level torque limits provide a fallback that limits the force of any inadvertent contact. The specific limit values are derived from the ISO/TS 15066 biomechanical force and pressure limits for each body region — different thresholds for the same joint operating in a head-proximity zone versus a chest-proximity zone.
We are not saying that a torque-limited system is inherently safe under all operating conditions. We are saying that the combination of geometric proximity detection, joint torque limiting, and whole-body compliance provides a layered safety architecture that is more robust to the failure modes of each individual layer than relying on any single mechanism alone.
The Control Architecture at Runtime
At runtime, Atom's motion control stack runs as a hierarchy of loops at different timescales. The joint-level torque control loop operates at 1kHz, consuming sensor data and commanding actuator current. The task-space impedance controller operates at 500Hz, converting end-effector force/torque targets into joint torque commands via the robot's Jacobian. The whole-body dynamics controller operates at 200Hz, computing joint torque distributions for locomotion tasks that satisfy both the motion goal and the stability constraints given current payload estimate. The task planner and perception layer operate at 30–60Hz, providing updated goal states to the dynamics layer as sensor data is processed.
Each layer is designed to degrade gracefully if the layer above it fails or goes silent: the joint-level loop defaults to holding current position with a soft torque limit; the impedance controller defaults to a safe home pose; the dynamics controller defaults to stopped-standing. This fail-safe layering means that a compute fault at the high-level task layer does not propagate into uncontrolled actuator motion — the lower layers catch it within their own cycle times.
The architecture is not exotic — elements of it have been in research for over a decade in legged robot work and in compliant manipulator research. The implementation challenge is in making it reliable at production cycle times, across the variation range of real factory tasks, with hardware that has been running in a hot, vibration-rich environment for months. That reliability is what distinguishes a deployable system from a laboratory result, and it is where the real engineering work happens.