Carnegie Mellon Researchers Introduce ELEVATE Framework to Help Quadrupeds Acquire New Controllers from Task Failures
By Jiang Si Qi
Quadruped robots with manipulators face a hard limit when required motions are absent from pre-trained libraries. The new ELEVATE framework enables these robots to autonomously diagnose missing physical capabilities during task failures and train new whole-body controllers using reinforcement learning.
Quadrupedal robots equipped with robotic arms adapt better to complex environments than their wheeled counterparts. Yet they face a hard limitation: every movement must be pre-trained and stored in a motion library. If the library lacks the required movement, the robot cannot achieve the target posture, regardless of how many times the task code is rewritten.
Could a robot autonomously identify which movement is missing upon task failure and then automatically learn that new skill?
To address this, a team from Carnegie Mellon University and Mitsubishi Electric Research Laboratories (MERL) published the paper "ELEVATE: Agentic Controller Acquisition from Task Failure for Quadrupedal Manipulation" on October 28, introducing the ELEVATE agentic framework. When a task program fails repeatedly, the system identifies which whole-body motor capability the robot lacks and then designs a reinforcement learning regimen to teach the robot those movements.
Shiqi Liu is the paper's first author. The author list also includes Ding Zhao, an associate professor in the Department of Mechanical Engineering at Carnegie Mellon University and director of the Safe AI Lab, whose research focuses on robotics and reinforcement learning.
The team developed the ELEVATE framework to enable the agent to make these judgments autonomously.
It continuously rewrites the task code to try again. When multiple code variations hit the exact same physical limitation, it realizes the issue is not the code itself, but a missing whole-body control movement. It then automatically defines the target movement, designs the training parameters, and uses reinforcement learning to train a new controller. Once the new controller passes testing, it is added to the motion library, and the system retries the task.
Across seven simulated test tasks, ELEVATE achieved an average success rate of 99.0% over five independent runs. In contrast, the control groups, which could only rely on a fixed motion library, achieved baseline success rates of just 28.4% and 23.0%.
The researchers also deployed the trained controller directly onto a real Unitree Go2 equipped with a PiPER robotic arm, without any additional tuning. It successfully picked objects from a shelf in 18 out of 20 attempts, and successfully placed objects from the ground onto the shelf in 16 out of 20 attempts.
Whether this approach can be consistently deployed depends on two factors:
- Whether the agent can reliably distinguish between a coding error and a physical limitation of the robot
- Whether the newly learned controller can generalize beyond predefined templates
Identifying capability gaps from failures
ELEVATE distributes the entire workflow across three types of cooperating agents.
The coordinator manages overall scheduling, maintains the capability library, and conducts holdout tests;
The task sub-agent focuses on writing programs for a single task, iteratively testing across 15 development variants, and refining the code based on numerical results, execution trajectories, and visual feedback;
The controller sub-agent is dedicated to designing and training novel controllers.
For every new task and every controller trained, the system spawns a completely new sub-agent with an independent context. These agents exchange information and log findings exclusively through files, without sharing any full conversation history.
Skills are essentially reusable functions: upper-level task programs chain multiple skills into an execution sequence, while low-level controllers translate perceptual observations into motion commands for 18 joints—12 for the legs and 6 for the robotic arm.

ELEVATE sets conservative and strict criteria for determining a "lack of capability."
The coordinator initiates the training process for a new controller only when four conditions are met simultaneously: most development variants fail at the physical level, the execution flow itself contains no logical errors, multiple entirely different implementation approaches all exhibit significant errors, and no viable remediation can be found in the existing capability library.
A lack of capability is confirmed only when multiple viable approaches hit the same physical limit.
This threshold distinguishes between "incorrect code" and "the hardware itself being incapable of the motion," preventing the agent from blindly training new controllers at the first sign of failure.

The fifth run of task A02 provides a clear example. The target position was 1.25 meters above the ground and 0.30 meters from the wall.
The task sub-agent first tested the initial controller across 15 development variants, all of which failed. After optimization to its best version, the vertical error decreased from 0.22–0.24 meters to 0.20–0.21 meters, still roughly four times the 0.05-meter allowable tolerance.
The agent concluded that the root cause was insufficient lifting height of the robot's torso and proposed learning two new controllers: one to leverage wall support for elevating the body, and another to adapt to this supported posture while tracking the end-effector position of the robotic arm.
This decision-making mechanism is built on information isolation.
The coordinator cannot access raw debugging trajectories or videos, nor can the task sub-agent access private task definitions, simulation configurations, training parameters, or the held-out test set. The decision to train a new controller relies solely on feedback reports from the development phase; results from the held-out test set are excluded from this decision.
Once the new controller is trained, it must undergo a validation phase.
It must first pass evaluation without any additional assistance. Then, using the same model checkpoint, identical integration procedures, and the same verification protocol, it is tested across 15 development variants for two consecutive rounds. Only if it passes both rounds is it added to the capability library.
Once added to the library, the coordinator assigns a completely new task sub-agent to retry the original task using the expanded capability library. Switching between controllers in the task program has explicit trigger conditions, and at any given time, only one controller outputs joint actions.
Autonomous training within the template
Once the new capability to be learned is determined, the controller sub-agent takes over. The framework provides only two types of base templates: body reconfiguration, which trains the robot to form and maintain a novel posture, and supported manipulation, which trains the robot to stabilize its body while controlling the robotic arm to track a target end-effector position.
The robot model, simulation environment, Proximal Policy Optimization (PPO) trainer, general regularization terms, domain randomization strategy, and maximum training steps are all pre-configured by the framework.
While the template defines the boundaries, the agent autonomously determines all internal details: selecting which body part to use for support, defining the target posture, designing the reward function, scheduling the training curriculum, setting termination conditions for each training episode, and establishing the criteria for determining when a skill is mastered.
It begins by reading the robot's geometric parameters and training configuration to assess the feasibility of the target motion. It then runs a brief PPO pre-experiment before initiating formal training to evaluate candidate controllers, iteratively adjusting parameters based on both numerical metrics and video playback.
To ensure the new controller can seamlessly pick up from the previous state, each training round begins from the exact state reached during the execution of the preceding controller.

The process of learning a wall-supported posture provides a clear illustration of its approach to adjusting rewards.
The initial reward function prioritizes optimizing pitch angle and shoulder height. The resulting policy causes the robot to squat backward: while the pitch angle meets the target, the shoulder height actually drops, and the front legs fail to make contact with the wall.
After reviewing the reward weights and video playback, the agent introduces two new reward terms—elevating the torso and pressing the front legs against the wall—while simultaneously increasing the upward assistive force.
With the assistive force enabled, the robot successfully achieves the supported posture in 96% of diagnostic episodes. After disabling the assist and continuing training, it ultimately maintains the posture stably until the time limit in 100% of evaluation episodes.
This process closely mirrors a graduate student manually tuning reward parameters, except the agent acts as the executor.
The study also tallied the total costs. Across the five complete test rounds from A01 to B03, each round took a total of 20.0 to 22.2 hours. The controller training itself accounted for 4.2 to 6.3 hours of this time, utilizing only a single NVIDIA RTX 5090 GPU throughout the entire process.
The cost of large model API calls per round ranged from USD 253 to USD 343, excluding GPU costs.
In each test round, the agent made between one and five substantive adjustments to the controller configuration, averaging 3.4 modifications. These changes primarily targeted the reward function, training curriculum, and termination conditions. Using just a single consumer-grade GPU, less than a day of compute time, and a few hundred dollars in model API costs, the system autonomously learned three entirely new whole-body controllers.
Simulation evaluation and real-robot deployment
The experimental hardware platform was a Unitree Go2 quadruped robot equipped with a six-degree-of-freedom AgileX PiPER robotic arm. The front of the robot's body was fitted with a camera and a LiDAR, while an Intel D405 depth camera was mounted at the end of the robotic arm.
The task program ran at 10 Hz, the controller at 50 Hz, and the simulated physics environment at 200 Hz. The physical robot used this same hardware configuration, with controller weights transferred directly from the simulation environment. No real-robot data was used for training or fine-tuning at any point.
The seven tasks were executed in a fixed sequence.
Tasks A01 through A04 comprised four reaching tasks: picking up random targets on the ground, reaching for elevated targets, sequentially passing through three elevated waypoints, and retrieving an object from a high position before picking up another from a low position.
B01 through B03 are three object manipulation tasks: picking up bottles and cans from the floor, retrieving a bottle from a 1.05-meter-high shelf and landing steadily on its feet, and placing a bottle from the floor onto the shelf.
A01 and B01 fall within the capability envelope of the initial controller, whereas the remaining five tasks exceed the boundaries of the native action space. Reaching tasks can directly measure the end-effector pose error relative to the target, but object manipulation tasks must rely solely on vision for localization.

To control variables as strictly as possible in the control group, all three methods uniformly used Claude Opus 5.5 executed via Claude Code. Inference parameters, the initial skill library, task order, observation inputs, evaluation variants, and success criteria were kept identical across all setups.
The only difference between ASPIRE and ELEVATE is that the autonomous training of new controllers is disabled in ASPIRE. Code-as-Policies goes a step further by disabling feedback-driven program iteration, generating only a single fixed program per task. Each task included 15 development variants and 50 held-out test variants. Each method was run independently for five rounds, resulting in a total of 1,750 held-out tests.
The results must be evaluated separately. For tasks A01 and B01, which the initial controller could already perform, ELEVATE showed no clear advantage, and ASPIRE actually achieved a slightly higher average success rate.
The performance gap is concentrated in the remaining five tasks that exceed native capabilities: both baseline methods failed completely in the held-out tests, whereas ELEVATE maintained a stable average success rate of 98.4% to 100%.
Aggregated across all seven tasks, ELEVATE achieved a 99.0% success rate, compared to 28.4% for ASPIRE and just 23.0% for Code-as-Policies. The single-round records are even more striking: before acquiring new controllers, A02 and A04 failed all 50 test trials; after acquiring the new controllers, they succeeded in all 50 trials.

The acquired skills can be continuously reused. Over the five rounds of testing, the system expanded its skill library from one to four controllers during the A02 and A04 stages; for the subsequent A03 and B01 through B03 tasks, no new controllers were trained.
In the fifth round of testing, the wall-leaning support posture and manipulation learned by A02 were directly reused by A03. A04 additionally trained a controller to detach from the wall, combining it with the support skill to execute a return-to-flat-ground maneuver. B02 relied on its ability to elevate its body by leaning against the wall to retrieve an item, then carried the bottle back to the ground with a stable landing. B03 combined ground grasping and wall-leaning elevation to place the bottle on the shelf.
Results were not carried over between the five rounds of testing. In each round, the autonomously learned support postures featured different parameters and naming conventions, with pitch angle targets distributed between 0.68 and 0.85 radians, yet their functional logic converged. The different agents explored independently but ultimately converged on the same underlying solution.
The researchers also introduced a box as an obstacle in the A02 scenario. Without any additional prompting, the agent autonomously shifted its support point, learning to rest its front legs on the box to maintain support.
The real-robot tests utilized a revised perception pipeline. Object masks were generated by Meta's SAM 3 segmentation model, while the front camera on the Go2 handled target search and approach. The end-effector D405 camera output masks that, combined with depth information and calibration parameters, localized the manipulation target within the robot's coordinate frame. The task program then planned the subsequent actions, including approaching, grasping, switching controllers, and placing.

Each of the two real-robot tasks was evaluated over 20 trials. B02, which involved retrieving a bottle from a shelf and landing smoothly while holding it, succeeded 18 times. B03, which required picking a bottle up from the ground and placing it on the shelf, succeeded 16 times. Most failures occurred during the grasping phase. The two failures in B02 were caused by insufficient contact area between the gripper and the bottle, combined with high acceleration as the robot descended from the wall, causing the bottle to slip. The failures in B03 primarily resulted from the gripper accidentally colliding with the bottle during the pickup phase.
Two approaches for coding agents
Almost concurrently, a team led by Xue Bin Peng at NVIDIA published a separate study that also bridges coding agents with whole-body control. Titled METATRON: A Promptable Whole-Body Execution Layer for Humanoids, the paper presents an approach that is the exact opposite of ELEVATE. The first author is Chen Tessler, and the team comprises researchers from NVIDIA and Dollhouse Robotics.
METATRON first jointly trains a prompt-conditioned whole-body base policy using human motion capture data, synthesized fall-recovery trajectories, and retargeted scene interaction motions. This base policy is immediately frozen upon completion of training. The prompts consist of fragmented goals, such as the desired position of specific body parts at a given moment, velocity commands, or style tags. New skills are implemented as standard programs. The coding agent analyzes the motion data and distills concise rules; during each control cycle, it translates the task intent into prompts and feeds them to the frozen policy to generate whole-body movements.

The two studies take fundamentally different approaches to the role of the coding agent. When ELEVATE encounters a capability gap, it trains a new low-level controller, continuously expanding its skill library. In contrast, METATRON's low-level policy remains frozen throughout, with the agent responsible only for orchestrating skills at a higher level; its capability ceiling is determined by the motions seen during pre-training. Simply put, the former effectively casts the agent as a reinforcement learning engineer, while the latter has it double as an animator and a programmer.
All quantitative tests for METATRON were conducted in simulation. Across 54 whole-body reaching tasks in MuJoCo, METATRON achieved an 83% success rate, compared to just 39% and 28% for two baseline reference trajectory tracking methods, and 0% for a GRU-based approach without arm inverse kinematics. When the robot walked at 1 m/s and was subjected to a 100-millisecond impulse force on its torso, METATRON's recovery success rate was 75% under 800 N and 1000 N pushes, while both baselines failed completely. At a 600 N push, the success rate dropped to 62%, then rebounded to 75% at 800 N and 1000 N. This non-monotonic result should not be interpreted as meaning that greater force leads to better stability.
In real-robot demonstrations, METATRON used frozen model weights on the Unitree G1 humanoid robot to perform joystick-controlled walking, PICO headset teleoperated grasping, sitting on a sofa and standing up, and autonomously recovering from various fallen postures. The real-robot trials did not include accompanying quantitative data, and the sofa-sitting task required manually placing the robot next to the sofa beforehand and inputting the target prompt. ELEVATE's real-robot tests involved a small sample size but reported explicit success counts. METATRON targets more structurally complex humanoid robots and enables a richer set of behaviors; its complete code and model weights have been open-sourced alongside NVIDIA's ProtoMotions.
Viewing the two studies together reveals that the capabilities of coding agents are continuously moving down the stack: from simply writing programs that call interfaces, they are progressively delving into the whole-body motion control of robots.
For researchers, a controller library does not need to be fully planned from the outset; it can be dynamically expanded to meet task requirements. The focus of researchers' work shifts to designing training templates, controlling compute costs, and defining acceptance criteria.
For companies developing quadruped and humanoid robots, the appeal of this approach lies in its cost: a single full test run using large model calls costs only a few hundred dollars, and training requires just a single consumer-grade GPU.
Whether this paradigm can be transferred to more robot form factors, expanded to more actions, or break free from template constraints to generate entirely new postures remains an open question. However, robots autonomously learning new capabilities from task failures have already taken their first steps on quadruped robots equipped with robotic arms.