Latest / Embodied AI 101 / AthenaZero: Why Dynamic Manipulation Starts With Lower Inertia
Transcript
- AthenaZero: Why Dynamic Manipulation Starts With Lower Inertia. AthenaZero: A low-inertia, bimanual robot for dynamic manipulation • Andrew S. Morgan and 25 coauthors • RAI Institute • Science Robotics • 2026. The controller is not the whole robot. Imagine a robot catching a ball. Its trajectory estimate is accurate. Its hand arrives at the correct location. Its fingers receive the close command on time. Yet the ball rebounds before the grasp is established. Where should we look for the problem? Perception latency, perhaps. Finger timing, certainly. But there is another possibility: the arm presents the wrong mechanical behavior to the incoming object. The software gets the robot to the collision, while the hardware makes that collision difficult to manage. This distinction matters because fast contact is not simply another tracking problem. Feedback can change the robot’s response, but it cannot provide unlimited bandwidth or instantaneously cancel the mechanics of the transmission. The MIT Cheetah work on proprioceptive actuation established the importance of addressing impact behavior through actuator design, not only through increasingly sophisticated controllers. AthenaZero brings that design question to bimanual manipulation. Its central proposition is that a useful manipulator should combine low inertia with substantial control authority: it should yield readily when that helps the interaction, yet still accelerate deliberately and produce significant forces. The project pursues this combination through quasidirect-drive actuation and strategic relocation of actuator mass toward the body. The contribution is not the discovery that backdrivable arms are useful. Barrett’s WAM already provides a commercially developed example of inherently backdrivable cable-drive manipulation. AthenaZero belongs to that lineage rather than replacing it with an entirely new physical principle. What makes the work interesting for Embodied AI 101 is the research question it exposes: how much of our manipulation software is solving the task, and how much is compensating for an embodiment poorly matched to the task?. That is not an argument against learning. It is an argument for being precise about what we ask learning to overcome. Before increasing the capacity of a policy, it is worth asking whether the robot’s natural response gives that policy a reasonable physical problem to solve. Effective mass is not the number on the scale. The key quantity is effective mass: how much inertia an interaction encounters at a particular point, in a particular direction, at a particular configuration. This is different from weighing the arm. A robot does not respond to an endpoint force by translating all its components together. Its joints rotate, its links follow different trajectories, and the resulting acceleration depends on configuration and direction. The same endpoint can therefore feel relatively light when pushed one way and much heavier when pushed another. In operational-space dynamics, we translate the robot’s joint-space inertia into the motion coordinates relevant to the task. Conceptually, we ask how an applied endpoint force produces joint accelerations, and how those accelerations move the endpoint. Khatib’s object-level treatment of inertial properties provides the established framework for reasoning about these task-space quantities, including systems involving multiple manipulators. For a researcher evaluating hardware, the practical implication is straightforward: “low effective mass” needs coordinates attached to it. Which contact point? Which posture? Which direction? Which joints are free to move?. It also needs to be distinguished from low stiffness. Stiffness concerns the force associated with displacement; inertia concerns resistance to acceleration. An arm can have low restoring stiffness yet remain difficult to accelerate. Conversely, a mechanically light arm can be actively controlled to resist displacement. Calling both properties “compliance” obscures an important distinction. Actuation introduces another contribution that is easy to overlook. Under the rigid-transmission approximation, a motor’s rotor inertia appears at the output multiplied by the square of the transmission ratio. The Cheetah actuator analysis explains why gearing, motor properties, and impact performance must be considered together. Low reduction is valuable, but it is not an independent guarantee of low inertia. Consider a deliberately simplified comparison using the same rotor. An 80-to-one reduction multiplies its inertia by 6,400; a five-to-one reduction multiplies it by 25. That is a factor of 256 in this one contribution. It is not a prediction that changing an entire arm’s gearing will make its endpoint 256 times lighter. A real redesign changes motor size, structural mass, torque capacity, and transmission geometry as well. That qualification is essential. Otherwise, quasidirect drive becomes a slogan rather than an engineering choice. The earlier Blue robot illustrates the broader design space. Gealy and colleagues proposed quasidirect drive for low-cost, force-controlled manipulation, building a human-scale seven-degree-of-freedom arm with a two-kilogram payload. Their objective emphasized accessible manipulation hardware and human operation, rather than the particular athletic performance envelope studied here. My reading is that effective mass should be treated as a task-design variable, not a universal leaderboard score. For catching, low inertia along the incoming object’s motion is attractive. For another task, supporting a tool or maintaining a constrained configuration may matter more. A useful comparison asks whether the robot offers the required combination of inertia, force, motion range, and controllable impedance. How AthenaZero spends its mechanical budget. AthenaZero has one torso degree of freedom, two seven-degree-of-freedom arms, and two underactuated six-joint hands: 22 actuators across 27 joints. Most arm joints use five-to-one reductions, and the project reports planetary transmission efficiencies of at least 97 percent. The mechanism does more than substitute a different gearbox. Elbow flexion uses a belt; a parallel wrist moves its motors toward the elbow. This suggests a useful way to approach mechanical design reviews. Do not ask only whether a component is lightweight. Ask which upstream joints must accelerate it, how far it sits from those joints, and what transmission would be needed to move it elsewhere. A modest reduction in distal mass may be more useful than a larger reduction close to the base. But relocating that mass is worthwhile only if the resulting mechanism remains controllable and maintainable. The hands push this reasoning further. The companion AthenaZero juggling paper describes three fingers per hand, each with two underactuated joints driven through a remotely actuated Bowden transmission. Finger opening and closing each take approximately 80 milliseconds. For adaptation to another platform, I would treat the arm and hand as separate dynamic subsystems. Moving hand actuators away from the wrist may improve the arm’s behavior while introducing another transmission whose friction, routing sensitivity, and timing need characterization. A robot can have excellent endpoint inertia and still lose a fast interaction because its grasp mechanism cannot complete the required transition. AthenaZero estimates actuator torque from motor current rather than dedicated joint or wrist force–torque sensors. The engineering interpretation should be careful. Current-based torque estimation is not the same as directly observing every external contact wrench. I would still want calibration across operating conditions and a clear accounting of which disturbances the estimator can distinguish. Removing a sensor does not remove the identification problem; it changes where that problem lives. The public model documentation also notes that the parallel wrist’s transmission ratio varies with configuration. Its supplied inertia-analysis values apply at the center of the wrist workspace. That is a particularly useful warning for simulation users. A mechanism can be elegantly represented for one analysis without that representation being sufficient for every dynamic experiment. Finally, the appropriate historical comparison is not “AthenaZero versus all previous arms.” WAM’s cable-drive architecture and Blue’s quasidirect-drive design already demonstrate alternative priorities to conventional stiff position-controlled manipulation. AthenaZero’s significance is better framed as a particular integration of actuation, mass distribution, bimanual geometry, and dynamic task execution. What the measurements actually establish. Five gravity-compensated pendulum trials per robot yielded directional effective masses of 0.83 kilograms for AthenaZero and 3.3 kilograms for the Franka FR3; peak forces were 124.1 and 208.3 newtons, respectively. These are valuable measurements because they connect a dynamics argument to a physical collision. The associated public dataset contains time-aligned pendulum velocity, endpoint velocity, contact force, and cumulative impulse, together with measures of variation. Those signals provide a more informative basis for inspection than a single headline mass value. Here is how I would read that experiment. It asks a local question about the response of two configured systems to a particular impact. It does not measure an immutable scalar property that follows either robot into every posture and task. That restriction is not a weakness peculiar to this paper. Configuration and direction dependence are inherent to apparent endpoint inertia. Consequently, a collision measurement in one direction should not be substituted for a worst-case value across the workspace, or compared casually with a directional maximum from another analysis. For an application study, I would therefore combine model-based maps with physical tests near the actual contact configurations. If the intended behavior uses the forearm against a workpiece, endpoint measurements alone would not be my acceptance criterion. If a large tool is attached, I would repeat the analysis with that tool rather than treating the bare-arm result as transferable. There is also an explicit precision tradeoff. Across 30 poses, mean endpoint error was roughly three millimeters unloaded and twelve millimeters with a 1.8-kilogram payload. The useful conclusion is not that one robot is accurate and another is compliant. It is that we need to specify which errors matter. A manufacturing process may care about deflection under sustained load. An interception task may care about arriving inside a capture region with the right velocity and impedance. Those are different acceptance tests. Series elasticity provides another important comparison. Pratt and Williamson’s original work deliberately inserted passive elasticity between actuator and load to improve shock tolerance and force-control behavior, while recognizing a tradeoff in zero-motion force bandwidth. That is a different route through the same design space, not an obsolete approach invalidated by quasidirect drive. My preferred evaluation would preserve these distinctions: physical inertia, passive elasticity, active stiffness, damping, tracking error, and impact outcome. Combining all six under “better compliance” makes it harder to understand what changed and harder to reproduce the benefit. Throwing: optimize the body, calibrate the release. Throwing combines SNOPT direct collocation, inverse-dynamics feedforward, and release calibration; measured command-to-release delays span 39–67 milliseconds. The last item deserves at least as much attention as the optimizer. For a throwing system, the action is not complete when the arm reaches a desired state. It is complete when the object leaves the hand with the intended state. Those two events are related, but they should not be conflated in the software interface. Consider a simple timing illustration. At twenty meters per second, a hand travels about two centimeters in one millisecond. That is not a calculation of landing error: orientation, acceleration, object motion within the grasp, and subsequent flight all matter. It does show why a release command timestamp can be an inadequate representation of the physical event. If I were porting this approach, I would separate three identification problems. First, can the arm execute the commanded motion? Second, how does a hand command translate into object separation? Third, how does the separated object fly? Improving one model while leaving the others implicit can produce a system that looks accurate internally and remains inaccurate at the target. TossingBot offers a closely related algorithmic lesson. Zeng and colleagues combined a physics-based estimate of throwing parameters with learned corrections, while jointly considering grasp selection and throwing. Their emphasis was accurate placement of varied objects, including the effects of object properties and grasp conditions, rather than maximizing anthropomorphic throwing speed. I would view that approach as complementary rather than competitive. A dynamics-aware whole-arm motion generator can provide the nominal behavior, while a data-driven component corrects the relationship between the commanded behavior and the actual object outcome. For learning researchers, this suggests a more targeted objective than immediately replacing the complete controller. Learn where the model is weakest and where the correction has an interpretable effect: release timing, release direction, or a small adjustment conditioned on the grasp state. It also suggests a better dataset. I would log not just successful and unsuccessful throws, but synchronized arm states, hand commands, observed separation events, and landing outcomes. Without that separation, a learner may absorb several distinct errors into a single correction that works only under the original operating conditions. Catching: arrive with the right impedance. Catching biases posture toward low effective mass and switches from joint tracking to directional Cartesian impedance before impact; the baseball demonstrations use a glove. This changes how we should formulate the task. A conventional interception objective asks where the hand should be at a particular time. A more complete objective also asks how the robot should respond when the object arrives. The second question is not merely a final controller setting appended to an otherwise finished plan. It can influence the posture selected, the time spent approaching, and the room retained for motion after contact. Suppose two configurations place the glove at the same point. For adaptation to a new arm, I would compare their directional inertia, available travel after impact, and distance from joint limits. A posture that is convenient for reaching may be inconvenient for yielding. The task objective should distinguish them. Directional impedance is especially useful as a design language. We might want the receiving surface to remain well aligned laterally while allowing greater motion along the incoming object’s path. Describing the entire arm as simply “soft” loses that structure. Passive elasticity research already makes clear that reduced stiffness changes both impact tolerance and achievable force response; the choice is about shaping an interaction, not minimizing every gain. I would also separate four times in the controller: the predicted arrival time, the transition into the receiving behavior, the first contact event, and secure capture. Those are distinct events with potentially different uncertainty. That distinction becomes important when deciding what to learn. A learned policy could adjust the pre-contact posture or receiving impedance without being responsible for every high-frequency actuator command. Alternatively, it could predict capture timing from a history of object motion and hand state. These are proposed extensions, not claims that the paper evaluates those learned policies. A strong follow-on benchmark would vary arrival-speed uncertainty and object rebound properties independently. It would ask not just whether the hand touches the ball, but whether contact leads to capture without excessive rebound, saturation, or loss of a useful subsequent configuration. That last condition matters for repeated manipulation. A catch is not necessarily a good catch if it leaves the robot unable to perform the next action. For a composed skill, the terminal state should be evaluated as the initial condition of whatever follows. Batting: two arms, one object, one deadline. Batting combines phase-parameterized trajectory blending with learned residual motion corrections. A useful way to understand phase parameterization is to imagine labeling a swing from zero to one, independently of the clock. The label says where we are along the movement. A separate progression rule says how quickly we move through it. In an implementation, this gives us two conceptually different adjustments: change the spatial swing, or change its timing. That separation is attractive when the desired contact point and arrival time are both being revised. It also creates questions worth testing explicitly: when does blending preserve a useful motion, and when does a timing correction demand acceleration the robot cannot deliver?. The two-handed grasp adds another layer. Multiple manipulators holding one object do not merely execute independent endpoint tasks. Their forces contribute both to object motion and to internal loading of the closed chain. Khatib’s object-level framework was developed in part to organize this distinction between the manipulated object and the cooperating mechanisms. As a thought experiment, command two independently controlled hands to follow slightly inconsistent poses while rigidly connected through a bat. The shared object prevents both commands from being satisfied exactly. The resulting behavior depends on the mechanisms, gains, and force distribution—not just on whether either isolated arm would track its own reference well. The paper reports that a swing timing error of approximately two milliseconds can cause a miss. That motivates prediction rather than a purely reactive interpretation of feedback. For scale, a hypothetical ball traveling fourteen meters per second moves 2.8 centimeters in two milliseconds. A controller cannot wait until every relevant event has become unambiguous and still expect to act at the right instant. For a new bimanual platform, I would therefore evaluate spatial adaptation, timing adaptation, and closed-chain loading separately before combining them. Otherwise, a missed strike tells us very little. It could reflect the prediction, the swing geometry, the time law, the grasp, or antagonistic forces between the arms. The valuable research problem is not merely generating a fast swing. It is preserving a feasible, coordinated swing while the target is still changing. Read the operating envelope, not just the speed record. Using external 240-hertz OptiTrack tracking, the maximum throw was 30.8 meters per second with a 57-gram tennis ball. Accurate baseball throws reached 21.4 meters per second into a 25-centimeter-square target 7.3 meters away. Catching reached 18.3 meters per second but was more reliable around 13.4. Batting reached 13.9 meters per second; around 13.4, the team recorded 27 hits from 33 swings. These conditions should remain attached to the numbers. Maximum throwing speed, accurate throwing, maximum successful catching speed, and an observed batting success proportion answer different questions. Collapsing them into a single description of “baseball ability” would erase much of the useful engineering information. The institute also describes a comparison to a professional-speed pitch based on matching flight time over a longer distance. That is a reaction-time comparison, not an impact-equivalence result. As an illustrative calculation, the same ball traveling at 46 meters per second carries about 6.3 times the kinetic energy it carries at 18.3 meters per second. Equal time to respond does not imply equal difficulty in absorbing or redirecting the object. Repeated execution supplies another perspective. Reported catch-to-throw cycles were approximately eleven seconds, with maximum exchanges of eight in robot-to-robot play and twelve in human-to-robot play. I would read those demonstrations as evidence about composition, not just athletic peaks. A repeated interaction forces the system to prepare the next action from the state actually produced by the previous one. That is a more demanding question than executing a single movement from a carefully initialized state, even if the cycle contains relatively slow preparation. For evaluation, I would keep three plots separate: maximum capability, reliability over a task distribution, and sustained cycle performance. A platform can improve strongly on one axis while still needing substantial work on another. That reporting discipline also makes hardware–algorithm comparisons fairer. We should not compare one system’s best observed trial against another system’s conservative operating specification and call the difference an algorithmic or mechanical breakthrough. Where learning fits. A companion project makes the connection to learning concrete. In Rapid On-Robot Learning for Dynamic Manipulation Skills: Robot Juggling, Taeyoon Lee and colleagues use AthenaZero with onboard vision, model-based control, and regularized memory-based adaptation. The learner adjusts reusable throwing skills from accumulated physical experience, while a precomputed mutually reachable set constrains how successive actions can be composed. That work reports rapid acquisition of several juggling patterns, but its timing results distinguish active physical interaction from manual-reset time, and the more difficult patterns are less consistently sustained. It is a separate evaluation, not evidence that the baseball experiments used onboard vision or the same learning framework. The architectural direction is nevertheless useful. Here is how I would translate the AthenaZero results into a learning research program. First, I would let a task-level policy choose meaningful interaction parameters: where to intercept, which posture family to use, how to orient the receiving impedance, and when to transition between behaviors. I would not initially require that policy to generate raw actuator commands at the fastest control timescale. Second, I would make the low-level contract explicit. If the policy outputs a desired pose, what stiffness, damping, feedforward dynamics, and saturation behavior accompany it? Two systems can expose the same nominal action space while implementing very different physical actions. For cross-embodiment learning, that ambiguity is something to measure, not something to hide inside the environment wrapper. Third, I would treat timestamps and uncertainty as part of the observation. A predicted contact point without its predicted time and confidence is incomplete input for a dynamic interaction. Likewise, a sequence of future actions should specify how it may be interrupted or retimed when new information arrives. Fourth, I would target residual learning at experimentally identified weaknesses. The connection to TossingBot is useful here: learned corrections can complement a physics-based parameterization without replacing every part of the system. These are design proposals. They should not be mistaken for established benefits of a particular policy family. The most important hypothesis to test is whether favorable mechanics make learning more efficient or robust. I would compare matched tasks and learning objectives while varying the embodiment or its rendered interaction behavior. Relevant outcomes would include successful interactions per unit of physical experience, recovery after disturbances, intervention frequency, and sensitivity to object variation. I would also resist equating low inertia with permission for unrestricted exploration. A training system still needs an operating envelope. The question is whether the embodiment enlarges the set of useful, recoverable experiments—not whether it eliminates the need to define that set. What you can reproduce now. The public repository is a useful starting point. It consolidates robot models and actuator-inertia parameters, provides links-only and links-plus-actuators comparisons, and includes a simplified AthenaZero model. Its documentation explicitly warns that the convenient simulated PD actuators do not represent the hardware’s actual actuator or control scheme. That scope matters. I would use the package to investigate inertial properties, not assume it is a ready-made simulator for reproducing all the baseball behaviors. The analysis script distinguishes structural inertia from added reflected actuator inertia and allows joints to be treated as locked. These choices are part of the experiment definition. Changing them changes the mechanical system being analyzed, even if the rendered robot looks identical. For a laboratory adaptation, my first exercise would be to repeat the calculation for the actual contact point and tool used in our task. I would then vary the relevant posture distribution, rather than relying only on a convenient neutral pose. Finally, I would identify a small number of configurations where a physical impact or force-response experiment could check the model. The baseline models also warrant inspection. The repository documents that some parameters are reconstructed or estimated; for example, its KUKA actuator-inertia assumptions draw on a related DLR design. That does not make the comparison useless, but it makes parameter sensitivity part of responsible interpretation. The accompanying Zenodo release provides AthenaZero and FR3 impact data, stiffness-evaluation data, and an archived analysis package. These are concrete artifacts for examining the reported measurements rather than relying entirely on the demonstrations. One further experiment would be essential before selecting a similar architecture for a new application: sustained operation. The institute identifies thermal limitations during prolonged static loading as a tradeoff of the design. I would therefore test not just the task’s most dramatic instant, but its entire duty cycle: waiting, holding, resetting, recovering, and repeating. For practical manipulation, those phases can determine whether an otherwise impressive mechanism is appropriate. The larger lesson. AthenaZero is most useful as a challenge to how we define the manipulation problem. It asks us to consider the body’s natural response alongside the policy, planner, and estimator. It also encourages a more disciplined vocabulary: inertia is not stiffness, maximum speed is not reliability, a controller update rate is not interaction bandwidth, and a successful contact is not necessarily a successfully composed skill. For roboticists, the opportunity is to design mechanisms and controllers around the same interaction requirements. For ML researchers, it is to investigate whether a better-matched embodiment changes what must be learned, how much experience is required, and which mistakes remain recoverable. The central takeaway is not that every arm should resemble AthenaZero. It is that hardware should enter the research hypothesis explicitly. Before asking a policy to become better at managing contact, ask what kind of contact the robot has been built to make.