ELEVATE: Agentic Controller Acquisition from Task Failure for Quadrupedal Manipulation

Vector (PDF)

Introduction

Quadrupedal manipulators combine mobility with rich whole-body interaction capabilities [1]. Beyond walking and manipulating objects with an arm, their morphology allows them to rear up, brace against the environment, use their legs for manipulation, and exploit contact with surrounding structures to extend their workspace [2], [3]. These capabilities make quadrupedal manipulators promising platforms for operating in complex real-world environments [4], but also create a fundamental challenge: the set of useful behaviors can be difficult to anticipate in advance. A task that appears impossible under the robot’s current controller may become feasible once the robot discovers a different mode of physical interaction. For example, a target mounted high on a wall may be unreachable using a standard loco-manipulation controller, yet accessible if the robot first places its front feet on the wall and raises its body.

This work was fully supported and conducted at Mitsubishi Electric Research Labs (MERL).

Recent advances in foundation-model-based robotics enable flexible task planning, program synthesis, and skill composition [5, 6, 7, 8, 9]. However, composing existing skills remains bounded by the physical capabilities of the underlying controllers. This limitation is especially important for legged mobile manipulators. In many tabletop manipulation settings, a generic end-effector controller provides a sufficiently expressive interface for composing a broad range of tasks. A quadrupedal manipulator, in contrast, may need qualitatively different modes of whole-body control for locomotion, rearing, bipedal motion, wall bracing, leg manipulation, or contact-rich arm manipulation. Prior work has therefore developed specialized learned controllers for different behaviors [2], [3]. For example, some systems combine locomotion with wall manipulation [2], while others use separate locomotion, bipedal, and manipulation policies to solve long-horizon tasks [3]. Although such controller libraries can support diverse behaviors, the choice of which controllers to pretrain remains task-dependent. Future tasks may require capabilities that were not anticipated when the library was constructed.

A plausible alternative is to automate controller acquisition. Existing methods automate reward and training design for human-specified behaviors [10], [11], or propose tasks and acquire skills from environmental context [12], [13]. However, a key challenge remains: how can an agent determine which new whole-body capability is needed when its existing controllers cannot solve a task? We study how persistent failures during task-program refinement can guide an agent to identify a missing reusable capability, formulate its reinforcement learning (RL) problem using supplied training templates, and integrate the learned controller to retry the original task, without a human specifying the new behavior to learn.

We present ELEVATE, a framework that uses task failures to guide the acquisition of new whole-body capabilities for quadrupedal manipulation. Following the task-program refinement pipeline used in ASPIRE [9], the agent iteratively refines task programs using its available skills. When persistent failures suggest a missing physical capability, it learns a new controller through reinforcement learning and composes it with existing controllers to resume task solving. The acquired controllers and composed skills are retained for subsequent tasks, allowing the robot’s capability library to grow with task demands.

We demonstrate this framework through autonomous controller acquisition and composition for elevated reaching, posture transitions, and object manipulation on a quadrupedal manipulator. The agent identifies missing capabilities, constructs their reinforcement-learning problems, trains the corresponding policies, and reuses previously acquired behaviors when solving subsequent tasks. We further validate the acquired capabilities by deploying the controllers without additional policy training for rack retrieval and floor-to-rack placement on a physical robot.

Our contributions are:

• Identifying missing capabilities from task failures. We introduce a framework that uses persistent task-program failures to identify missing whole-body capabilities, without a human specifying the new behavior to learn.

• Automatically training the required controllers. The agent uses reusable training templates to design and iteratively refine rewards, curricula, and termination conditions for acquiring the identified capabilities.

• Reusing learned capabilities across tasks. The framework retains learned controllers and composed skills for subsequent tasks. We demonstrate acquisition and reuse across seven simulation tasks and validate the acquired capabilities on a physical quadrupedal manipulator without additional policy training.

RELATED WORK

Foundation Models for Planning and Skill Acquisition

Foundation models enable language-based planning, program synthesis, and skill composition over robot interfaces [6, 7, 8]. Code-as-Policies [5] generates programs that invoke APIs for perception and control, while ASPIRE [9] iteratively refines task programs from execution feedback and retains reusable Python skills. These methods expand task-level behavior by recomposing available interfaces, but task execution remains bounded by the physical capabilities exposed by the underlying controllers.

A complementary line of work uses foundation models to automate skill acquisition. Text2Reward [14] and Eureka [10] generate reinforcement-learning rewards, while DrEureka [11] additionally designs domain randomization for sim-to-real transfer. RoboGen [12] generates tasks, environments, and training supervision, and RL-GPT [15] integrates coded actions into reinforcement learning in Minecraft. Agentic Skill Discovery [13] learns and chains policies for simulated tabletop manipulation, acquiring missing skills during task decomposition.

ELEVATE connects these two lines of work. It begins with task-program synthesis and refinement; when persistent execution failures suggest a missing physical capability, the agent formulates and refines a whole-body controller-training problem using supplied training templates. The validated controller is then integrated through reusable Python skills so that task solving can resume with the acquired capability.

Quadrupedal Loco-Manipulation

Quadrupedal loco-manipulation builds on whole-body controllers that coordinate locomotion and arm motion [1, 16]. Legos Manipulator [2] uses a behavior tree to compose locomotion and leg-manipulation policies. Learned planners select pretrained controllers for goalkeeping [17] and ball manipulation on rugged terrain [18]. In locomotion, ANYmal Parkour [19] selects obstacle-specific policies, while Yu et al. [20] continuously compose frozen gait and recovery policies through a learned gating network. At the task level, Ouyang et al. [3] generate programs over locomotion and manipulation skills and fine-tune policies using predecessor terminal states to improve transitions, while WildLMa [4] uses a large language model (LLM) planner to compose visuomotor skills and analytical navigation routines above a shared whole-body controller.

These systems demonstrate the value of composing specialized behaviors from prepared repertoires. ELEVATE studies how task-execution failures can motivate expansion of the repertoire itself: the agent hypothesizes a missing whole-body behavior, trains and validates a corresponding controller, and retains it for composition and reuse in later tasks.

Methodology

ELEVATE enables a quadrupedal manipulator to learn new controllers in response to persistent task failures. Given a language instruction and a simulation environment, the agent first attempts the task using its existing controllers and skills. It refines the task program based on feedback from development trials. When persistent failures suggest a missing physical capability, the agent formulates and refines a reinforcement-learning problem to train a new controller. It then integrates the new controller into task programs alongside existing ones and retries the original task. Figure 2 summarizes the three stages: task refinement and capability diagnosis, controller formulation and training, and controller integration and skill reuse.

A task program is executable Python code for a particular task; it can invoke skills and include task-specific logic. Task programs use a capability library containing two types of reusable components: controllers and skills. A controller is a learned policy that maps numerical observations and supported commands to joint actions. A skill is a reusable Python function that packages a task-level robot behavior using available controllers and environment feedback, such as reaching a target or picking up an object. Helper functions provide supporting operations for skills and task programs, including perception estimates, measurements, geometric calculations, base navigation, and end-effector pose control. Both skills and helpers can issue controller commands; skills combine supporting operations into reusable task-level behaviors.

The library initially contains a pretrained loco-manipulation controller (loco_manipulation) for base motion and 6D end-effector pose control, together with the supplied floor_pickup skill, which uses this controller for visually guided object pickup from the floor. The agent expands this library by training new controllers and developing reusable skills. Figure 3 summarizes how the coordinator and subagents collaborate in this process.

Vector (PDF)

Task Refinement and Capability Diagnosis

Given a task, ELEVATE first generates and refines a Python program that uses its available controllers and skills. A coordinator assigns this process to a task subagent in a fresh context. Following ASPIRE’s exploration-and-repair loop [9], the subagent inspects an initial observation, generates a Python program that invokes available skills, and tests it across development variants. Between executions, it uses numerical outcomes, execution traces, and visual feedback to refine the task program. Each failed variant receives a bounded number of repair replays. Controller weights remain fixed throughout program refinement.

When program refinement repeatedly fails, the task subagent assesses whether the task requires a physical capability missing from its current controller library. A capability gap is suggested when different valid strategies encounter the same physical limitation, such as consistently falling short of an elevated target despite successful approach motions. The task subagent records the attempted strategies and remaining errors to support this diagnosis.

When failures across most development variants suggest a missing physical capability, the task subagent reports the suspected capability gap and supporting evidence to the coordinator. The coordinator reviews the report and, if acquisition is warranted, dispatches a controller subagent. This subagent identifies a reusable behavior to learn and formulates and refines a reinforcement-learning problem to train the corresponding controller. Acquisition decisions use only development feedback; Appendix A-C details the full procedure.

Controller Formulation and Training

Given the diagnosed capability gap, the controller subagent identifies the behavior to learn and designs the reinforcement-learning setup needed to acquire it. It inspects robot geometry and training code to assess feasibility, then specifies the training scene, supported commands, and initial states. It designs behavior-specific rewards, curricula, termination conditions, and measurable success criteria, and defines when control transfers from the preceding controller.

Stage	Provided by framework	Agent decisions and outputs
Capability identification	Initial capability library; public task interface	Failure diagnosis; reusable behavior to acquire
Training formulation	Two behavior templates; command modes; posture and support guidance	Scene and reset configurations; rewards, command distributions, curricula, terminations, and success criteria
Training and validation	Robot model, simulator, PPO settings, shared regularization and randomization	Revisions based on training feedback; training execution; checkpoint selection and validation
Integration and reuse	Controller registry; guarded switching; bounded target correction	Switch conditions; reusable skills; controller composition and library updates

The framework supplies the robot model, simulator, proximal policy optimization (PPO) trainer [21], and reusable training templates. Table I summarizes this division of responsibility.

Each controller is a policy $u_t = \pi_{\theta}(o_t, c_t)$ with learned parameters $\theta$. The controller observation $o_t$ contains robot and environment feedback and action history, while the controller command $c_t$ specifies supported targets or modes. Supported manipulation encodes the pose command as keypoint errors in the measured end-effector frame, together with an arm-motion flag (Appendix C-A). These state-relative targets remain commands. Together, $(o_t, c_t)$ form the controller input; for a controller without commands, the input consists of $o_t$ alone. The policy outputs an 18-dimensional action vector $u_t$. The runtime converts it to joint-position targets $q_t^{\mathrm{tg}} = q^{\mathrm{default}} + 0.25u_t$, where $q^{\mathrm{default}}$ contains the controller-specific default positions for the 12 leg and 6 arm joints. Controllers share this action space, while their supported commands depend on the behavior.

We provide two templates to guide behavior-specific controller training. The body reconfiguration template trains a controller to move the robot into a new posture and hold it. The template also includes reward terms that encourage the arm to remain near its gravity-compensated home pose for balance. The controller subagent chooses the support structure and target posture, then uses the supplied guidance to design rewards for posture progress, support contacts, and stability. The template provides optional temporary pose assistance to help the robot reach the target posture selected by the controller subagent. Assistance may be used in diagnostic evaluations during training, but is disabled for final controller validation and task evaluation.

The supported manipulation template trains a controller to track commanded end-effector poses while maintaining a supported stance. During arm motion, the robot is encouraged to keep its leg-joint configuration and base pose close to their initial values. Training targets are sampled from a dataset of reachable end-effector poses, which we construct by sampling arm configurations within joint limits and recording the resulting end-effector poses in simulation.

After selecting a training template, the controller subagent initializes training episodes from states recorded during rollouts of the preceding controller. This allows the new controller to learn from states that its predecessor can produce. The subagent then runs configuration and simulation checks, conducts a short PPO pilot, and trains and evaluates candidate controllers. Numerical measurements and recorded rollouts guide revisions to rewards, training conditions, and termination thresholds. Inherited termination rules are adjusted when they conflict with the intended posture, while criteria for falls and undesired contacts are retained. The subagent trains or resumes the revised candidate and checks whether it achieves the intended support contacts, body configuration, or reaching behavior. This validation precedes integration into task programs. Shared regularization, PPO settings, domain randomization, and training budgets are supplied by the framework.

Controller Integration and Skill Reuse

After completing training and validation, the controller subagent reports the results to the coordinator, which adds the new controller to the capability library. Task programs switch controllers only when the target controller’s switch conditions are satisfied; implementation details are provided in Appendix C-E.

One task may require successive controller acquisitions. A prerequisite controller is validated on its intended behavior without requiring completion of the original task. For example, a body reconfiguration controller can raise the robot into a wall-supported posture, followed by a supported manipulation controller for reaching from that posture. Once the required controllers are available, the coordinator dispatches a fresh task subagent to retry the original task using the expanded library. The task subagent refines the program and develops skills for reusable robot behaviors using the available controllers. Controller weights remain fixed during this process.

Following ASPIRE [9], task subagents identify reusable task behaviors during program refinement and report them to the coordinator. The coordinator retains these behaviors as parameterized skills, with documentation of their applicability, usage, and limitations. Both learned controllers and reusable skills remain in the library for subsequent tasks, while the environment resets between tasks.

Experiments

Our experiments evaluate whether ELEVATE can autonomously expand a quadrupedal manipulator’s capabilities in response to task failures within the supplied controller-training framework. Specifically, we ask whether the agent can (i) identify missing control capabilities from task failures, (ii) acquire usable controllers to address those failures, and (iii) reuse them on later tasks. We additionally validate the acquired capabilities by deploying the resulting controllers on a physical robot without policy fine-tuning.

Experimental Setup

The task suite comprises four reaching tasks (A01–A04) followed by three object-manipulation tasks (B01–B03). It progresses from floor-level reaching to elevated targets and posture transitions, then tests whether the accumulated capabilities support object manipulation. A01 and B01 are within the initial controller library capability; A02–A04 and B02–B03 require elevated reaching beyond its workspace. We conduct five independent runs using Claude Opus 5.5 through the Claude Code harness. Figure 4 illustrates the tasks and the reuse of controllers and skills in Run 5; Table II defines each task and its success criterion.

Vector (PDF)

Task	Objective and success criterion
A01	Reach a random floor-level target.
A02	Reach a target 1.25 m above the floor, 0.30 m from the wall.
A03	Reach three elevated waypoints in order.
A04	Reach targets at 1.25 m on the 0.40 m in the same wall column.
B01	Lift a floor bottle or soda can at least 0.30 m above the floor.
B02	Retrieve a bottle or can from a 1.05 m-high rack; stop upright with four feet on the floor, arm homed, and object held.
B03	Pick up a floor bottle or can and place it upright on the rack.

We use a Unitree Go2 quadruped with 12 leg joints and a 6-DoF AgileX PiPER arm. The robot carries a built-in front camera and LiDAR on the base and an Intel D405 RGB-D camera at the end effector (Figure 7). Task programs operate at 10 Hz, controllers at 50 Hz, and simulation physics at 200 Hz. Task programs access proprioceptive observations comprising joint positions and velocities and IMU-based estimates of base orientation. Object segmentation masks are provided by Isaac Lab [22] in simulation and SAM 3 [23] on the physical robot. We use the front LiDAR only to estimate the robot’s distance and heading relative to the surface ahead. A01–A04 additionally provide end-effector-to-target pose errors, while B01–B03 rely on vision for target localization and receive no target-position observations. The physical perception pipeline is described in Sec. IV-F.

Vector (PDF)

Tasks run in the order A01 $\to$ A02 $\to$ A03 $\to$ A04 $\to$ B01 $\to$ B02 $\to$ B03. The initial library contains a pretrained loco-manipulation controller for base motion and 6D end-effector pose control, together with the supplied floor_pickup Python skill and perception and manipulation notes. The environment resets between tasks, while previously acquired controllers and skills remain available.

We compare ELEVATE with Code-as-Policies [5] and ASPIRE [9] to evaluate how acquiring new controllers expands the range of tasks the robot can solve. We implement both baselines as controlled variants in the same framework: ASPIRE uses ELEVATE’s task-program synthesis, feedback-based repair, and reusable-skill accumulation with controller acquisition disabled. Code-as-Policies additionally disables program repair, executing one initial program per task unchanged across variants. Both baselines retain the initial low-level controller throughout the sequence; ELEVATE can train and add controllers when development failures indicate a missing capability.

All three methods use the same language model and reasoning setting, initial capabilities, task order, task observations, evaluation variants, success rules, and episode limits. ELEVATE and ASPIRE share the development-selection rule and allow at most three repair replays per failed development variant; Code-as-Policies allows none. Controller training and the subsequent program development enabled by library expansion are additional computation used by ELEVATE; total computation is therefore not matched across methods.

Each simulation task contains 15 development variants and 50 separate evaluation variants. Reaching variants vary target poses or initial robot poses; object-manipulation variants vary object placement. Each variant is fixed across resets and retries. The coordinator runs held-out evaluation; subagents never receive its results. Evaluation outcomes are not used for task-program refinement or controller acquisition.

Task programs, reusable library code, and controller weights remain fixed throughout held-out evaluation. The seven-task aggregate includes the final 50 trials per task in each of five independent runs (1,750 trials per method). We report mean success rates and sample standard deviations across the five run-level rates; detailed protocols and per-run outcomes appear in Appendices D-B and E and Table X.

Method	Run	A01	A02	A03	A04	B01	B02	B03	Total
Code-as-Policies	1	42	0	0	0	50	0	0	92
Code-as-Policies	2	35	0	0	0	48	0	0	83
Code-as-Policies	3	36	0	0	0	28	0	0	64
Code-as-Policies	4	28	0	0	0	45	0	0	73
Code-as-Policies	5	42	0	0	0	49	0	0	91
ASPIRE	1	50	0	0	0	50	0	0	100
ASPIRE	2	50	0	0	0	50	0	0	100
ASPIRE	3	49	0	0	0	50	0	0	99
ASPIRE	4	50	0	0	0	48	0	0	98
ASPIRE	5	50	0	0	0	50	0	0	100

Task Performance and Coverage

On A01 and B01, which are supported by the initial controller, ELEVATE shows no advantage over ASPIRE (Table III). The coverage gain occurs on A02–A04 and B02–B03, where both baselines with a fixed controller library fail on every held-out trial and ELEVATE achieves 98.4%–100% mean success. These results reflect the task suite’s deliberate inclusion of missing physical capabilities and do not establish superior high-level program synthesis.

Task	Code-as-Policies	ASPIRE	ELEVATE
A01	73.2 ± 11.6	99.6 ± 0.9	99.2 ± 1.1
A02	0.0 ± 0.0	0.0 ± 0.0	100.0 ± 0.0
A03	0.0 ± 0.0	0.0 ± 0.0	98.4 ± 2.6
A04	0.0 ± 0.0	0.0 ± 0.0	100.0 ± 0.0
B01	88.0 ± 18.3	99.2 ± 1.8	97.6 ± 3.6
B02	0.0 ± 0.0	0.0 ± 0.0	99.6 ± 0.9
B03	0.0 ± 0.0	0.0 ± 0.0	98.4 ± 0.9
Overall	23.0 ± 3.4	28.4 ± 0.3	99.0 ± 0.7

Across the seven tasks and five runs, ELEVATE achieves 99.0% overall success, compared with 28.4% for ASPIRE and 23.0% for Code-as-Policies. This comparison includes additional controller training and subsequent program development only for ELEVATE. Acquiring the required working postures resolves the observed workspace limitation while leaving execution failures within the expanded workspace.

Autonomous Controller Acquisition

On A02 in Run 5, repeated development sweeps with the initial controller yield 0/15 successes. The best revised program reduces vertical error from 0.22–0.24 m to 0.20–0.21 m, still about four times the 0.05 m tolerance. The agent diagnoses insufficient arm-base elevation and proposes wall_stance for wall-supported elevation and wall_reach for end-effector tracking from that stance.

Using the supplied templates and PPO infrastructure, the agent autonomously specifies and revises environment configurations, rewards, termination conditions, and curricula, and selects checkpoints based on training and evaluation feedback.

Training wall_stance illustrates feedback-driven revision of the training formulation (Figure 5). The initial policy sits

Vector (PDF)

backward, increasing pitch without sufficient body elevation or wall support. After inspecting reward components and recorded rollouts, the agent revises the formulation to encourage elevation and appropriate support contacts. Following these changes and further training, the selected controller establishes the intended stance in evaluations with simulated body assistance disabled.

On A04 in Run 5, the agent learns a wall_descent controller for returning from wall support to the floor. The floor-recover skill combines it with loco_manipulation to restore a stable four-foot stance and resume standing loco-manipulation, enabling the robot to reach the low target.

In all five reported runs, ELEVATE acquires wall-supported elevation and supported manipulation on A02, followed by wall descent on A04. Each run starts without controllers, skills, or findings acquired by another run. In every run, A02 and A04 each improve from 0/50 held-out successes before acquisition to 50/50 afterward. Total controller training uses 4.2–6.3 h of computation per run on one NVIDIA RTX 5090, summing rollout-collection and learning times across pilots, restarts, and resumed segments. Appendix E-D reports the per-run effort and full workflow timing. All five runs use the same initial repository configuration, task interfaces, task success rules, held-out variants, and training budgets. Appendix E details these conditions and the individual outcomes.

Different Environment, Different Strategies

In a qualitative variant of A02 with an added box, ELEVATE acquires two controllers: box_stance for front-foot support on the box and box_reach for end-effector tracking from that stance (Figure 6). The initial controller library and task instructions remain unchanged, and the agent is not instructed to use the box. Together with the wall-supported behavior, this example illustrates how the agent can select an available support structure when acquiring a capability for elevated reaching.

Vector (PDF)

Capability Reuse Across Tasks

In all five runs, acquisition on A02 and A04 expands the library from one to four controllers, with no additional controller training on A03 or B01–B03. The following examples illustrate reuse in Run 5 (Figure 4); Appendix E-C lists each run’s controllers, skills, and helpers.

On A03, the two controllers acquired at A02 are reused unchanged without additional controller training. Its program adapts the wall_high_reach skill to visit three elevated waypoints, demonstrating reuse for a longer reaching sequence.

Reuse also extends from reaching to object manipulation. B02 uses the wall_high_reach skill for elevated retrieval, then reuses floor_recover to return to the floor while retaining the bottle. B03 combines floor pickup with the elevated-reaching skill to transport and place the bottle on the rack. No additional controllers are trained in B01–B03. These executions extend the use of the acquired controllers from reaching to retrieval and placement through task-specific perception and manipulation code.

Zero-Shot Deployment on the Physical Robot

We deploy the acquired controllers on the physical robot for B02 and B03, which combine floor-level and elevated manipulation (Figure 7). B02 requires retrieval and a return to a settled four-foot stance while retaining the bottle; B03 requires floor pickup and upright placement on the rack. Across the two tasks, the programs compose controllers for loco-manipulation, wall-supported elevation, supported manipulation, and wall descent. All controller weights transfer unchanged from simulation, with no training or fine-tuning on real-robot data.

Physical execution uses image-based perception and the real gripper. SAM 3 [23] supplies object masks. The Go2’s front camera supports search and approach, while masks from the end-effector D405 camera are combined with aligned depth and calibration to localize manipulation targets in the robot frame. Task programs use these estimates to coordinate approach, grasping, controller transitions, and placement.

Over 20 trials per task, B02 achieves 18/20 successes (90%) and B03 achieves 16/20 (80%). In the two B02 failures, limited gripper–bottle contact allows the bottle to slip during the large accelerations of floor recovery. B03 failures mainly arise from unintended gripper contact during floor pickup. These trials demonstrate physical execution of the composed capabilities without policy fine-tuning, while identifying grasp robustness during pickup and body transitions as a remaining limitation.

Conclusion

We presented ELEVATE, a framework that uses persistent task-execution failures to drive the acquisition of missing whole-body control capabilities for quadrupedal manipulation. When execution feedback suggests a missing physical capability, ELEVATE formulates and refines a reinforcement-learning problem using supplied training templates, validates the resulting controller, and integrates it into task programs alongside existing controllers. Across the evaluated seven-task sequence, the controller library grows from one pretrained loco-manipulation controller to four controllers. The acquired capabilities enable 98.4%–100% mean success across five independent runs on five tasks beyond the initial controller’s workspace and are reused across subsequent reaching and object-manipulation tasks. Zero-shot deployment of the resulting controllers achieves 18/20 successes on rack retrieval and 16/20 on floor-to-rack placement on a physical quadrupedal manipulator.

This appendix details the implementation and evaluation of ELEVATE. Appendix A presents the pipeline and scope of agent autonomy. Appendix B traces controller acquisition and reuse through worked examples, and Appendix C provides the training and integration specifications. Appendix D describes the tasks, evaluation protocols, and baseline results. Appendix E compares performance, acquired capabilities, training and revision effort, runtime, and estimated model cost across the five independent Claude acquisition runs used in the main-text aggregate. Unless stated otherwise, worked examples and controller specifications refer to Claude Run 5.

Appendix A: Pipeline and Autonomy Boundaries

This section presents the workflow through which ELEVATE develops task programs, acquires missing controllers, and integrates them into a reusable library. We first describe the initial capabilities, task interfaces, and agent responsibilities, then explain the end-to-end procedure. Finally, we clarify which constraints the framework fixes and which decisions the agents make about behaviors, training formulations, and controller integration.

Initial Capabilities and Task Interfaces

A task program is executable Python code for a particular task; it can invoke skills and include task-specific logic. ELEVATE maintains two kinds of executable capability. A controller is a learned policy that maps controller observations and supported commands to an 18-dimensional action vector, which the runtime converts to joint-position targets. A skill is a reusable Python function that packages a task-level robot behavior using available controllers and environment feedback. Helper functions provide supporting perception, measurement, geometric, navigation, and pose-control operations for skills and task programs. Both skills and helpers can issue controller commands. The agent trains controllers during acquisition. When developing task programs, it uses the available controllers without changing their weights.

The initial library contains the frozen loco_manipulation controller, the floor_pickup skill, and written perception and manipulation notes. The loco_manipulation controller tracks base-velocity commands for Go2 locomotion on the floor and 6D PiPER end-effector pose commands (position and orientation) specified in the robot’s base frame. The floor_pickup skill uses visual input and object segmentation masks to pick up objects from the floor by issuing commands to the loco_manipulation controller. The training framework supplies the robot model, simulator, PPO trainer, two controller templates, 10,000 reachable PiPER end-effector poses, and settled start states of the initial controller. Thus, the agent starts with functioning locomotion, arm control, and floor pickup, together with a structured controller-authoring framework.

All task programs receive proprioceptive observations, robot state, and front-surface distance and heading measurements. A01–A04 additionally provide ground-truth end-effector-to-target pose errors. B01–B03 instead provide front RGB and wrist RGB-D images, camera calibration, and segmentation masks, without ground-truth object or rack poses. These tasks therefore require the program to estimate target locations from visual observations.

Agent Roles and Information Access

A coordinator dispatches a fresh task subagent for each task attempt and a fresh controller subagent for each acquisition. They exchange findings and controller documentation through files rather than sharing full conversations. The coordinator publishes shared-library updates; controller subagents author controller integration code before publication. Table IV summarizes the division of work and information access.

Role	Responsibilities	Available information	Restrictions
Coordinator	Assigns work to subagents, publishes library updates, starts controller acquisition, approves controllers for the library, and runs held-out trials.	Development findings and reports of blocked variants; controller documentation and result summaries.	No access to raw debugging traces, keyframes, videos, or program output. Held-out results cannot guide development.
Task subagent	Develops and repairs task programs, selects the final program, and records reusable findings.	Public task and API documentation; available controllers and skills; outcomes and traces from its own development trials.	No access to private task definitions, simulator or training code, assets, datasets, or held-out variants and results.
Controller subagent	Defines the capability and training design, revises training, selects a checkpoint, writes controller integration code, and runs confirmation sweeps.	Findings from blocked tasks; public interfaces; robot geometry; training and environment code; controller evaluations and development replays.	No access to private task definitions or held-out variants and results. Cannot modify the initial controller or other controller packages.

End-to-End Procedure

The sequence is A01 $\to$ A02 $\to$ A03 $\to$ A04 $\to$ B01 $\to$ B02 $\to$ B03. The library persists across tasks, while each execution resets the environment. The following procedure connects program repair to controller acquisition; detailed evaluation rules appear in Appendix D-B.

1. Develop a task program. A task subagent inspects an initial scene, states a hypothesis, and executes its initial program on the 15 development variants. It repairs failed variants with at most three further replays each, classifying exhausted variants as physical, perceptual, or algorithmic failures.

2. Select and freeze. The subagent selects one program using development evidence and reports reusable patterns. The coordinator publishes the selected patterns, freezes the program and library snapshot, and runs the 50 held-out variants once. These outcomes are reported without feeding back into development.

3. Assess the capability gap. After held-out evaluation is complete, the coordinator assesses the gap using only the development reports. Acquisition requires physical failures on most development variants, valid completed executions, a substantial residual error across materially different programs, and no plausible remedy within the existing library.

4. Formulate and train. The controller subagent receives development failure reports. By diagnosing the failure, it defines a reusable behavior, its switch conditions, and measurable success criteria. It sets up the training scene and initial robot states, and writes the behavior-specific rewards, curriculum, commands, and termination conditions. It then refines the training configuration using numerical measurements and visual evidence from controller rollouts within the acquisition budget (Appendix B).

5. Evaluate and integrate. The subagent evaluates checkpoints, writes controller integration code, and runs two confirmation sweeps over the development variants with an unchanged checkpoint, integration code, and confirmation program. The coordinator reviews its summary and README; promotion requires both sweeps to pass. If the controller is a prerequisite, acquisition of the dependent controller follows before task development resumes.

6. Resume or stop. If acquisition succeeds, a fresh task subagent retries the task using the expanded library. Evidence from the previous attempt is archived separately, and the new attempt follows the same development, program selection, freezing, and held-out evaluation procedure. If the acquisition budget is exhausted or the declared criterion remains unreachable, the task is recorded as physically blocked; the controller is not reopened under another name. As the sequence proceeds to later tasks, acquired controllers and skills remain available for reuse.

Figure 3 in the main text summarizes the agent workflow and the refinement loops for task programs and controller training.

Scope of Agent Autonomy

The framework supplies the workflow and controller-training templates, while the agents choose the behaviors to learn and design their training problems. Table V summarizes the supplied constraints and the decisions left to the agents; detailed training and integration specifications appear in Appendix C.

Component	Provided by framework	Agent decisions
Task program development	Public task API; success criteria; development/held-out split; repair limits	Program logic, perception strategy, and controller commands; failure diagnosis and reusable skills
Controller training	Robot and simulator; joint-action interface; PPO settings; shared regularization and disturbances; frozen initial controller	Training launches, revisions, restarts, and resumptions; checkpoint selection
Body reconfiguration template	Uncommanded posture transition followed by holding; four-foot support; arm near home	Support structure and target posture; rewards, resets, terminations, assistance schedule, and success criteria
Supported manipulation template	Entry from a supported stance; end-effector pose commands and arm-home mode; recorded-state resets	Supported workspace and target filtering; rewards, evaluation metrics, and termination conditions
Controller integration	Controller registry; guarded switching mechanism; public observation interface; bounded target correction	Switch conditions; reusable Python functions; controller composition and confirmation programs
Budgets and validation	Training-step cap; development-only refinement; two successful confirmation sweeps before promotion	Allocation of training and debugging effort within the budget

For example, on A02, the controller subagent decided to learn a wall-supported elevated stance (wall_stance) to raise the arm mount. It used the body-reconfiguration template, which requires a single transition followed by holding the resulting stance with the arm near home. Following this template, the subagent specified a posture with the front feet on the wall and hind feet on the floor, and designed rewards for elevation, wall contact, and stability.

Detailed numerical constraints and controller-training settings appear in Appendix C.

Appendix B: Controller Acquisition and Reuse: Worked Examples

This section explains ELEVATE through controller acquisition and the development of two reusable skills in Claude Run 5. A02 follows the process from failed task programs to new controllers, the wall_high_reach skill, and renewed task execution. A04 adds a wall descent controller and the floor-recover skill; B02 and B03 show how these acquired capabilities support later tasks. Training and integration specifications appear in Appendix C; cross-run comparisons appear in Appendix E.

Reading the Worked Examples

The initial library contains the frozen loco_manipulation controller for standing locomotion and arm control, the supplied floor_pickup skill, and perception and manipulation notes. A controller is a learned policy that maps controller observations and supported commands to joint actions. A skill is a reusable Python function that packages a task-level robot behavior using available controllers and environment feedback. Helper functions provide supporting perception, measurement, geometric, navigation, and pose-control operations for skills and task programs. Both skills and helpers can issue controller commands. A task program is executable Python code for a particular task; it can invoke skills and include task-specific logic. Controller training adds physical behaviors; skills use them to accomplish subgoals such as reaching a target or picking up an object. The runtime checks switching guards, with one controller producing joint actions at a time.

The five steps below connect task failure to a reusable capability. All decisions and revisions use development feedback: controller evaluations assess the learned behavior, and confirmation sweeps test its integration on development variants. Held-out outcomes evaluate frozen task programs and do not guide development.

A02: From Failed Reaching to a Reusable Skill

Step 1: Diagnose the reaching failure. A02 requires the end effector to reach a goal 1.25 m above the floor, within a 0.05 m position tolerance and with a horizontal approach toward the wall. Using only loco_manipulation, the initial task program left final position errors of 0.22–0.24 m, entirely vertical: the robot approached the wall and aligned the end effector, but could not reach the required height. Two revised programs also failed on all 15 development variants. The best revision reduced the error to 0.20–0.21 m, still about four times the tolerance. The persistent vertical shortfall across all three programs motivated a behavior that raises the arm mount.

Step 2: Formulate the new controllers. The controller subagent divided the solution into two physical behaviors. The wall-supported elevation controller, wall_stance, places the front feet against the wall while keeping the hind feet on the floor, raising the arm mount with the arm homed. The supported manipulation controller, wall_reach, then tracks commanded end-effector poses while maintaining that stance. Elevation supplies the second controller’s entry state; holding the elevated posture alone does not provide commanded manipulation (Figure 8).

Vector (PDF)

Using the supplied templates, the agent formulated elevation rewards for pitch, shoulder height, support contacts, and stability, with temporary pose assistance during training. The supported manipulation controller is trained to track poses while retaining the supported body configuration, starting from recorded elevation states. The formulation, refinement, and validation process is applied first to wall-supported elevation and then to supported manipulation. Appendix C-C gives the final controller formulations.

Step 3: Train, inspect, and revise. Figure 9 follows elevation training from left to right. Initially, the robot sat back on folded hind legs: pitch increased while shoulder height fell, and the front feet remained at the wall’s base. The agent revised rewards for raising body height, measured at the shoulder, and placing the front feet on the wall, strengthened the upward assist force, and restarted training. With assistance enabled, 96% of diagnostic episodes reached the supported stance (middle). The assistance curriculum then reduced the upward force to zero; the final controller passed unassisted evaluation and was selected and exported (right).

Vector (PDF)

Step 4: Validate the behaviors and integrate the controllers. The controller subagent implemented the controller integration code and confirmation programs, with runtime guards checking each controller transition. Each controller passed assistance-free evaluation and two confirmation sweeps over the same 15 development variants with an unchanged checkpoint, integration code, and confirmation program. Wall-supported elevation confirmation tested stance entry and maintenance with the arm homed; supported manipulation confirmation tested A02 completion. This validates the prerequisite before solving the original task (Appendix C-D). The coordinator then added the validated controllers and their integration code to the library.

Step 5: Retry the task and retain the capability. A fresh task subagent retried A02 with the expanded controller library and developed the wall_high_reach skill during task-program refinement. The skill first uses loco_manipulation to align the robot with the wall and home the arm, then switches to wall_stance to establish the supported stance, and finally switches to wall_reach to reach the target. Public observations guide skill execution, and runtime guards check each controller transition (Figure 10). A02 improved from 0/50 held-out successes with the selected pre-acquisition program to 50/50 after acquisition. The coordinator retained the skill and its usage guidance for later tasks.

Vector (PDF)

A04: Acquiring Wall Descent

Diagnose the wall descent gap. A04 requires an elevated waypoint followed by a waypoint 0.40 m above the floor. Reusing A02’s wall_high_reach skill reached the first waypoint, but repeated program revisions failed at the second. That target was reachable while standing, yet runtime guards rejected direct switches from the supported stance to loco_manipulation. The missing capability was to recover to the floor: a wall descent controller must leave wall support before loco_manipulation can establish stable standing and reach the second waypoint (Figure 11).

Acquire and refine wall descent. The agent trained wall_descent from states recorded during rollouts of the supported manipulation controller with the arm homed, initially rewarding the target standing pose. Figure 12 follows three stages. Initially, the robot leaned low against the wall with crouched hind legs and front legs splayed sideways. The agent continued training without changing the formulation. The resulting reward exploit was a “table” posture: the body was level at standing height, but the front feet still pressed against the wall. The agent then penalized feet on the wall and rewarded feet on the ground. After further action-offset and posture refinements and retraining, the controller returned to a four-foot stance and was selected and exported (final configuration in Appendix C-C).

Vector (PDF)

Integrate the wall descent controller and retry A04. After validation and development confirmation, the coordinator added the wall descent controller to the library. A fresh task subagent then retried A04 and developed the floor_recover skill during task-program refinement. The skill first uses wall_reach to move the arm to its home pose, then switches to wall_descent to descend, and finally switches to loco_manipulation for a force-stand action that establishes a stable four-foot stance (Figure 13). A04 can now compose wall_high_reach for the high waypoint with floor_recover and subsequent reaching under loco_manipulation for the low waypoint.

Vector (PDF)

The resulting frozen task program improved A04 from 0/50 to 50/50 held-out successes. A04 adds the wall_descent controller and the floor_recover skill with its integration code to the library while retaining A02’s controllers and wall_high_reach. Its new lesson is that manipulating within a useful stance and leaving that stance require distinct physical capabilities.

Reusing the Accumulated Library

The acquired controllers and skills support later tasks without further controller training. B02 and B03 reuse the library accumulated through A04, with controller weights and guards fixed. Task programs can still add perception, manipulation logic, and reusable helpers. Written guidance records applicability and failure signatures for later tasks.

B02: Rack Retrieval with Existing Capabilities

B02 reuses wall_high_reach to access the elevated object and floor_recover to return to standing after grasping it. Their controller integration code is reused unchanged. New task logic adds wrist-camera localization, lateral centering, and grasp targets in a gravity-levelled frame. The measurement and centering routines were published as helpers for later tasks.

The floor_recover skill uses the same homing, descent, and force-stand sequence developed on A04. The recovery skill originally developed for a low waypoint therefore also serves rack retrieval. B02 achieved 50/50 held-out successes.

B03: Rack Placement with Reused Components

B03 first picks up an object from the floor, using floor_pickup routines repaired on B01, then reuses wall_high_reach and B02’s measurement helpers. New logic models the held object and plans its placement. The program enters the stance beside the panel to avoid striking the rack board during elevation, places and releases the object, and ends in the supported stance. It therefore does not invoke floor_recover. B03’s placement procedure was documented, with no downstream reuse demonstrated.

B03 achieved 49/50 held-out successes. In the remaining variant, heading drift caused the elevation switch guard to reject the switch; the program ended with the robot still standing and holding the object.

The B02–B03 comparison shows how new tasks reuse acquired controllers, the wall_high_reach and floor_recover skills, and selected helpers while supplying different task logic. Appendix C-E gives the controller-transition implementation.

Appendix C: Controller Training and Integration Specifications

Policy Interface and Shared Optimization

All acquired controllers share the same 60-dimensional observation, comprising proprioceptive feedback and the previous action, and output 18-dimensional action vectors that the runtime converts to joint-position targets for the 12 Go2 leg joints and 6 PiPER arm joints. Commands differ by controller: body reconfiguration uses no commands, whereas supported manipulation receives a 10-dimensional command comprising one arm-motion flag and nine end-effector keypoint-error coordinates. Combining the shared observation with the controller-specific command yields 60 input dimensions for body reconfiguration and 70 for supported manipulation in Claude Run 5. The frozen loco_manipulation controller uses a 222-dimensional input. Tables VI and VII give the recorded interfaces and supplied optimization settings. The agent can choose the default joint positions for each controller to help the robot transition between controllers.

Pose-command encoding. Three non-collinear keypoints encode both position and orientation. Their fixed offsets form an equilateral triangle in the end-effector’s local $xy$-plane:

The commanded pose is supplied in the robot-root frame and transformed into the measured end-effector frame. Let $(p_t^{\mathrm{cmd}}, R_t^{\mathrm{cmd}})$ denote its position and rotation matrix in that frame. The current keypoints are $d_i$, and the commanded keypoints are $p_t^{\mathrm{cmd}} + R_t^{\mathrm{cmd}}d_i$. Thus, the target-minus-current errors and full command are

where $m_t$ is the scalar arm-motion flag selecting target tracking or arm homing. The nine error coordinates concatenate the $xyz$ error for each keypoint in the order above, replacing a separate position-and-quaternion command representation. When corruption of the controller command is enabled during training, the commanded keypoints receive a shared random translation of up to $\pm5$ mm per axis and a shared rotation of up to $\pm5^\circ$ in roll and pitch and $\pm2^\circ$ in yaw. The critic receives the uncorrupted command encoding, and this corruption is disabled for evaluation and task execution.

Item	Setting
Action	Policy output: 18-dimensional vector $u_t$. Runtime joint-position targets: $q_t^{\mathrm{tgt}} = q^{\mathrm{default}} + 0.25u_t$, where $q^{\mathrm{default}}$ contains the controller-specific default joint positions
Rates	Physics 200 Hz, controllers 50 Hz, task programs 10 Hz
Controller observation	Shared by all acquired controllers: base angular velocity (3), projected gravity (3), joint positions relative to default (18), joint velocities (18), previous action (18), totaling 60 dimensions
Controller command	Body reconfiguration: none. Supported manipulation: one arm-motion flag and three 3D target-minus-current keypoint errors in the measured end-effector frame ($1 + 9 = 10$ dimensions)
Controller input	Shared observation plus controller-specific command: 60 dimensions for body reconfiguration and 70 for supported manipulation. The frozen loco_manipulation controller has its own 222-dimensional input
Critic input	Uncorrupted controller input plus privileged feedback: base linear velocity and foot contacts, plus controller-specific terms (e.g., base height, front-sensor clearance, foot distances to the wall, foot heights); 78–82 dimensions
Parallel environments	4,096
Episode length	Chosen per controller

Setting	Value	Setting	Value
Rollout steps per environment	24	Clip parameter	0.2
Actor and critic MLP	512-256-128, ELU	Value loss coefficient	1.0 (clipped)
Initial action std	1.0	Entropy coefficient	0.01
Learning rate	$10^{-3}$, adaptive	Learning epochs $\times$ minibatches	$5 \times4$
Desired KL	0.01	Discount $\gamma$, GAE $\lambda$	0.99, 0.95
Max gradient norm	1.0	Observation normalization	None
Checkpoint interval	100 iterations	Steps per iteration	98,304

Parameter	Range	Parameter	Range
Go2 static friction	$[0.6, 1.4]$	PiPER static friction	$[0.5, 1.2]$
Go2 dynamic friction	$[0.5, 1.2]$	PiPER dynamic friction	$[0.5, 1.2]$
Go2 restitution	$[0, 0.15]$	PiPER restitution	$[0, 0.1]$
Go2 base mass	$+[-1, 3]$ kg	PiPER link mass	$\times[0.8, 1.2]$
Go2 base center of mass	$\pm0.05$ m per axis	PiPER link inertia	$\times[0.8, 1.2]$
Go2 link inertia	$\times[0.8, 1.2]$	PiPER end-effector payload	$+[0, 0.5]$ kg
Go2 actuator stiffness	$\times[0.8, 1.2]$	PiPER link center of mass	$\pm0.1$ m per axis
Go2 actuator damping	$\times[0.75, 1.5]$	PiPER actuator stiffness	$\times[0.8, 1.2]$
Go2 joint friction	$[0, 0.05]$	PiPER actuator damping	$\times[0.75, 1.5]$
Push linear velocity $(x,y)$	Set to $\pm0.3$ m/s	PiPER joint friction	$[0, 0.05]$
Push yaw velocity	Set to $\pm0.3$ rad/s
Term	Weight	Term	Weight
Support-polygon margin	$+0.8$	Foot slide (BR)	$-0.1$
Joint velocity	$-10^{-3}$	Leg action rate (BR)	$-0.01$
Joint acceleration	$-2.5 \cdot10^{-7}$	Arm action rate (BR)	$-0.01$
Joint torque	$-2.5 \cdot10^{-4}$	Leg posture prior (BR)	$-0.01$
Energy	$-2 \cdot10^{-5}$	Arm action rate (SM)	$-0.1$
Joint limits	$-1.0$	Initial leg posture (SM)	$+0.4$
Undesired contacts	$-1.0$	End-effector excess linear speed (SM)	$-2.0$
		End-effector excess angular speed (SM)	$-0.05$

Training Templates and Initialization Data

Body reconfiguration. This category learns one transition from its entry stance to a target stance, then holds that stance without commands or termination on success. The template limits orientation change to below 1.0 rad and requires at least 0.05 m front clearance to protect the front LiDAR and camera from contact with the support surface. The supplied starter rewards default base height, penalizes base tilt, and tracks the gravity-compensated arm-home pose through end-effector tracking. The agent replaces the behavior formulation with progress, contact, and stability terms for the chosen maneuver. The intended terminal contract requires all four feet in contact with the floor or supporting structure and no other supporting body contact. The success predicate also measures the pose change and must be false at reset.

Supported manipulation. This category tracks end-effector pose commands while preserving a supported stance. An arm-motion flag selects target tracking or return to the gravity-compensated home pose; the tracking reward remains active in both modes. With measured pose $(p,Q)$ and selected target $(p^{*},Q^{*})$, the weighted term is

Here, $p$ and $p^{*}$ are the measured and selected-target end-effector positions, $Q$ and $Q^{*}$ are their orientation quaternions, and $d_{R}(Q,Q^{*}) \in[0,\pi]$ is their angular orientation error in radians. The widths begin at $\sigma_{p}=0.40$ m and $\sigma_{R}=2.0$ rad and shrink by 0.7 when normalized tracking reward exceeds 0.8, with floors of 0.10 m and 0.50 rad. These floors specify the curriculum limits, not a claim that every checkpoint reached them.

Pose assistance helper. We provide the agent with optional pose assistance, which it can choose to enable during training. A world-frame spring wrench can pull the base toward the target pose. When enabled, sustained behavior success reduces the stiffness until it reaches zero. Assisted diagnostic evaluations may be used to inspect intermediate training progress. Assistance is disabled for final controller validation, export, and task execution; if used during training, its curriculum must be completed before a checkpoint is eligible for validation and export.

Reach-target data. The supplied dataset contains 10,000 end-effector poses obtained by sampling fixed-base PiPER configurations within joint limits. Training perturbs sampled targets, clips lateral displacement to $\lvert y\rvert< 0.35$ m, and rejects targets violating a 2 cm floor clearance or protection regions around the body and arm mount. The agent adds support-specific data and filtering: wall-reach adds 12,000 wall-facing targets verified by inverse kinematics in the reared stance, and rejects targets whose end-effector or fingertip point lies within 0.06 or 0.03 m of the wall.

Final Controller Configurations

The following list specifies the final behavior formulations. For wall_stance, stance progress rewards pitch only together with shoulder height (Appendix B-B). For wall_descent, standing progress combines uprightness, base height, and the fraction of feet on the floor, while posture progress encourages the initial controller’s standing leg configuration. Complete contact predicates, terminations, and reward functions are defined by the controller packages. The listed terminations supplement time-out, base contact, and the inherited 1.0 rad tilt limit; runtime guards are in Appendix C-E.

• wall_stance

  • Motivating task: A02 (prerequisite).

  • Behavior: Rear against the wall: base pitched 0.68 rad nose-up (success 0.55–0.80 rad), shoulder $\ge0.67$ m (target 0.73 m), front feet on the wall at least 0.25 m up, hind feet on the floor.

  • Rewards (weights): Stance progress (pitch $\times$ shoulder height) 3.0; pitch 1.0; shoulder height 2.0; roll $-2.0$; front feet on wall 2.0; hind feet on floor 0.5; wall-foot slip $-0.2$; stance held 3.0; motion in the stance $-1.0$; wall standoff 0.5; sensor-clearance shortfall $-2.0$; arm home terms 3.0.

  • Curriculum: Pose assist on the base (initial stiffness 800 N/m $z$, 150 N/m $x$, 80 / 30 N m/rad pitch / roll), $\times0.8$ when success exceeds 0.6, down to zero.

  • Terminations: Contact of any body other than the feet and gripper fingers above 1 N; sensor clearance below 0.05 m; base below 0.10 m.

• wall_reach

  • Motivating task: A02 (closes the gap).

  • Behavior: Track commanded end-effector poses while holding the stance; fold the arm home when arm motion is off.

  • Rewards (weights): End-effector tracking 3.0; arm home joint $-0.01$; alive 0.05; front feet on wall 0.5; hind feet on floor 0.5; tilt above 0.74 rad $-5.0$.

  • Curriculum: Tracking widths 0.40 $\to$ 0.10 m and 2.0 $\to$ 0.50 rad.

  • Terminations: Base drift above 0.15 m or 0.35 rad; contact of any body other than the feet and gripper fingers above 1 N.

• wall_descent

  • Motivating task: A04 (closes the gap).

  • Behavior: Come down to standing: tilt at most 0.15 rad, base 0.22–0.34 m, four feet on the floor, base $\ge0.43$ m from the wall.

  • Rewards (weights): Standing progress (tilt $\times$ height $\times$ feet on floor) 3.0; upright 1.0; wall standoff 1.0; posture progress 2.0; feet on floor 2.0; feet on wall $-1.0$; standing held 3.0; motion while standing $-1.0$; standing posture 2.0; sensor-clearance shortfall $-2.0$; arm home terms 3.0.

  • Curriculum: None (the motion lowers the center of mass).

  • Terminations: Contact of any body other than the feet and gripper fingers above 1 N; sensor clearance below 0.05 m; base below 0.10 m.

Checkpoint Evaluation and Acceptance Criteria

Before training, the controller subagent declares a controller-level evaluation criterion and a development-sweep criterion. A prerequisite controller must demonstrate its intended capability; the controller that closes the gap must enable full task success. Promotion requires two confirmation sweeps over the same 15 development variants with one unchanged checkpoint, integration code, and confirmation program. These are repeated development checks, not independent held-out generalization tests. The list below reports the Claude Run 5 controller-level measurements and development confirmation outcomes; final task outcomes appear in Appendix B.

The agent performs configuration and simulation checks, a short PPO pilot, longer training, and checkpoint evaluation. Every tenth saved checkpoint and the final checkpoint receive evaluation with keyframes, and the agent may evaluate earlier checkpoints for diagnosis; numerical returns alone are insufficient for a verdict. The final controller evaluations reported below use 64 parallel environments and seed 42, stopping after at least 100 completed episodes. Because the evaluator counts all completions in each evaluated step, this threshold can be exceeded; each reported final evaluation contains 128 episodes. Assistance is disabled for these final evaluations; assisted diagnostic evaluations during training, such as the intermediate result in Appendix B-B, do not establish controller acceptance. Controller-level disturbances are distinct from the nominal-physics task evaluations described in Appendix D-A.

Each controller has a total budget of $1.5 \times10^{9}$ environment steps, summed across pilots, restarts, and training segments; evaluation does not count toward that training budget. A standard iteration uses 4,096 environments and 24 rollout steps per environment, or 98,304 environment steps. Training ran on one RTX 5090 with 32 GB memory, taking approximately 1.3–1.6 s per standard iteration across Runs 1–5. Jobs are otherwise exclusive, but one checkpoint evaluation may share the GPU with its active training run. In Runs 4 and 5, controller subagents also ran task replays, such as routing checks and certification replays, while their training runs were active. Actual acquisition effort is reported in Appendix E-D. The wall-supported elevation controller was confirmed on its prerequisite capability with the arm homed; supported manipulation and wall descent were confirmed by A02 and A04 task success, respectively.

• wall_stance

  • Declared evaluation criterion: At least 95% of episodes end only by time-out; instantaneous stance success at least 0.75 over all steps.

  • Measured evaluation: 128/128 time-outs; stance success 0.979; every episode reached the stance, after 0.26 s on average.

  • Required development confirmation: Stance within 3 s of the switch, held to the episode end; return to loco_manipulation rejected.

  • Observed development confirmation: 15/15 twice; stance within 0.7 s, held 11.6–13.6 s; return rejected.

• wall_reach

  • Declared evaluation criterion: At least 90% of episodes end only by time-out.

  • Measured evaluation: 128/128 time-outs; A02-like targets within tolerance on 93.8% of arm-motion steps, mean error 0.024 m and 0.086 rad.

  • Required development confirmation: A02 success after a guarded switch from wall_stance.

  • Observed development confirmation: 15/15 twice; goal completed at 8.2–10.9 s.

• wall_descent

  • Declared evaluation criterion: At least 95% of episodes end only by time-out; at least 95% reach standing; mean time to stand $\le2.0$ s.

  • Measured evaluation: 128/128 time-outs; every episode reached and ended standing; mean time to stand 0.23 s.

  • Required development confirmation: A04 success, with descent entry and hand-back accepted after only guard rejections.

  • Observed development confirmation: 15/15 twice; loco_manipulation selected 0.8–1.0 s after descent began.

For the elevation sweeps, the required stance had nose-up pitch in [0.55, 0.80] rad, absolute roll at most 0.20 rad, shoulder height at least 0.67 m, and front-sensor clearance at least 0.05 m.

Controller Switching

The robot can switch to another controller only after satisfying all of that controller’s switch conditions. The controller subagent defines and implements these conditions, which the runtime checks before allowing a switch. Exactly one controller produces joint actions at a time; rejected requests retain the active controller and are recorded in the trace.

For elevated reaching, wall_high_reach aligns the robot using loco_manipulation, establishes wall support using wall_stance, and switches to wall_reach for arm motion. For recovery, floor_recover homes the arm using wall_reach, switches to wall_descent to descend, and returns control to loco_manipulation for the final force-stand action.

The runtime enforces the following switch conditions and hold durations:

• loco_manipulation $\to$ wall_stance

  • Front-sensor distance 0.12–0.20 m.

  • Front-sensor |angle| $\le0.10$ rad.

  • Base stopped.

  • Arm homed.

  • Hold for 1.0 s.

• wall_stance $\to$ wall_reach

  • Joint speeds below 1.5 rad/s.

  • Hold for 0.5 s.

• wall_reach $\to$ wall_descent

  • Arm motion off.

  • Arm homed.

  • Stance held.

  • Joint speeds below 1.5 rad/s.

  • Hold for 0.5 s.

• wall_descent $\to$ loco_manipulation

  • Tilt $\le0.20$ rad.

  • Every joint speed below 1.0 rad/s.

  • Hold for 0.3 s.

Appendix D: Experimental Protocols

This section specifies the simulation tasks, evaluation procedures, and baseline results. Appendix E reports acquisition outcomes, artifact inventories, revisions, training effort, runtime, and model-usage estimates across five independent Claude runs. Claude Run 5 provides the detailed acquisition and reuse narrative in Appendix B; training specifications appear in Appendix C.

Task Definitions

All tasks share the same room and Go2–PiPER platform. The manipulation objects have body diameter 0.065 m and mass 0.5 kg; the bottle is 0.200 m tall and the cans 0.113–0.121 m tall. The B02/B03 rack has a $1 \times0.12$ m board with its top 1.05 m above the floor, mounted on a $1 \times1.5$ m panel flush with the wall. Table IX gives the task-instance distributions and success rules. For A01–A04, position and orientation tolerances are 0.05 m and 0.20 rad.

Task	Start	Varied per variant	Limit	Success; failure
A01	$x=-1$ m, facing $+x$	Target $x \in[0,2]$, $y \in[-1,1]$, $z \in[0.3,0.6]$ m; yaw $\in[0,2\pi]$ applied to the A02 orientation	20 s	End effector within 0.05 m and 0.20 rad of the target
A02	$x,y \in[-0.5,0.5]$ m, yaw $\in[-36^\circ,36^\circ]$	Start pose	20 s	Fixed goal 0.30 m from the wall and 1.25 m above the floor, level gripper pointing at the wall
A03	As A02	Start pose; waypoints 2 and 3 offset from the A02 goal by $\Delta x,\Delta y \in[-0.15,0.15]$ m and $\Delta z \in[-0.30,-0.15]$ m	20 s	Three waypoints in order, each within tolerance for 1 s
A04	As A02	Start pose	20 s	Waypoints at 1.25 m then 0.40 m above the floor, same wall column and orientation
B01	$x=0.5$ m, facing $+x$	Object position $\pm0.2$ m around (1.5, 0) m; object (bottle with probability 0.5, else one of three cans)	40 s	Held object’s lowest point at least 0.30 m above the floor; failure if the unheld object tips past $45^\circ$
B02	$x=1.6$ m, facing $+x$	Object position $\pm0.3$ m along the board; object type	60 s	Object held, base stopped and arm homed, four feet on the floor, base upright; failure if the unheld object tips past $45^\circ$ or falls below 1.0 m
B03	$x=1.35$ m, facing $+x$	Object position $\pm0.01$ m ($x$), $\pm0.2$ m ($y$) around (2.35, 0) m; object type	60 s	Released object upright within $10^\circ$ with its base within 2 cm of the board top; failure if the unheld object drops to the floor after the first pickup

For B03, the released-object height and uprightness conditions do not include a horizontal-position or board-footprint containment test. Evaluation ends when the 1 s success dwell completes; it does not establish longer-term placement stability or require the robot to return to standing.

Simulation assumptions. Physics randomization, push disturbances, curricula, and additive observation noise are disabled during task execution. Object masks are simulator ground-truth segmentation; B01–B03 do not expose ground-truth object or rack poses. Controller-training randomization, disturbances, and assistance are specified separately in Appendix C.

Evaluation and Baseline Protocols

A task name and seed determine the settled start state and task inputs. Seeds 51–65 define the 15 development variants; seeds 1–50 define the 50 held-out variants. Resets preserve a variant across retries.

Development and selection. Stage 0 captures a scene snapshot on variant 51, records an initial analysis, and executes an initial program on all development variants. Stage 1 allows at most three repair replays per failed variant. Exhausted failures receive a physical, perceptual, or algorithmic classification. One task program is selected by most development successes, then fewest crashes, then simplest observation-driven behavior. There is no separate confirmation sweep for task programs; the paired sweeps in Appendix C-D apply to controller acquisition.

Held-out evaluation. After development, the coordinator publishes reusable findings and runs the frozen program once per held-out variant. Each replay records its program and library snapshot; an immutable manifest identifies the held-out run by program, library, task, and seed-list hashes. Completion means that all 50 results exist, regardless of success count. A controller promotion leads to archived earlier evidence and a fresh task-development attempt. The reported final result is the last frozen program’s held-out run; earlier evaluations with the pre-acquisition controller library remain evidence of the preceding capability set. Neither those outcomes nor the final outcomes are used to select repairs or justify acquisition.

Baseline comparison. We implement ASPIRE and Code-as-Policies as controlled variants of ELEVATE within the same agent and evaluation framework. All three use Claude Opus 5.5 (Claude-opus-5-5) at reasoning effort xhigh through Claude Code, the same coordinator and fresh-task-agent structure, and common task-program instructions, except for the acquisition and repair permissions described below. Each starts with the frozen loco_manipulation controller, the supplied floor_pickup skill, and the perception and manipulation notes described in Appendix A-A. All follow A01 → A02 → A03 → A04 → B01 → B02 → B03 and retain reusable Python skills within a run; acquired artifacts are not shared between independent runs.

ASPIRE differs from ELEVATE only by disabling controller acquisition and the resulting controller-library expansion. It uses the same initial program synthesis, development-feedback repair, program selection, and reusable-skill accumulation. Stage 1 permits at most three repair replays per failed development variant, with no additional evolutionary-search stage. The initial low-level controller remains frozen throughout the task sequence. For ELEVATE, controller acquisition follows Appendix C-D, and successful acquisition permits a fresh task-development attempt with the expanded library.

Code-as-Policies uses the ASPIRE configuration with feedback-based program repair additionally disabled. It generates one initial program per task, rather than one per variant, and executes that program unchanged on all 15 development variants and all 50 held-out variants. It permits no repair replays, feedback-driven candidate selection, or revisions to the library code invoked by the current task. The program can still react to observations during execution, and reusable findings can be retained for later tasks under the same skill-accumulation procedure.

All three configurations share the public task API and observations (Appendix A-A), task definitions and success rules (Table IX), simulation assumptions, settled start states for each seed, development seeds 51–65, and held-out seeds 1–50. Episode limits are 20 s for A01–A04, 40 s for B01, and 60 s for B02–B03. ASPIRE and ELEVATE use the development-selection rule above; Code-as-Policies freezes its sole initial program. Each frozen program is evaluated once per held-out variant, without using held-out outcomes for repair, skill updates, or acquisition. These settings match task evaluation, while the repair allowance differs for Code-as-Policies and controller training and subsequent task development add computation for ELEVATE; total computation is not matched. The shared starting conditions across the five ELEVATE runs are detailed in Appendix E-A.

Baseline run results. Table X reports five completed independent runs for each baseline. Each entry gives the final frozen program’s held-out successes. Table III summarizes these counts and the five Claude ELEVATE runs as mean success rates and sample standard deviations across runs. Overall rates are computed per run from all 350 task trials before calculating the mean and standard deviation.

Appendix E: Independent Acquisition Runs

This section reports five independent controller-acquisition runs using Claude Opus 5.5 through Claude Code. All five runs completed A01–B03 and form the main-text aggregates. Claude Run 5 supplies the worked examples in Appendix B.

Study Design and Run Conditions

Independent acquisition runs. Each run starts from a fresh repository without controllers, reusable modules, or findings acquired by another run. Runs share task definitions, success evaluators, development variants 51–65, held-out variants 1–50, controller-training budgets, and promotion rules. A run includes the complete A01–B03 sequence and retains its own acquired library across tasks. Each task contributes 50 final held-out trials, giving 350 trials per run and 1,750 trials across the five runs. The acquisition run is the unit of replication; task variants and controller-confirmation sweeps do not increase the number of independent acquisitions. All controller-training launches, including pilots, and checkpoint evaluations use seed 42.

Claude run conditions. All five use claude-opus-5-5 at reasoning effort xhigh and share the same initial repository configuration, including the supplied training framework, initial datasets, frozen loco-manipulation controller checkpoint, pickup skill, and public task interfaces. The supplied pickup skill uses a minimum walking command of 0.08 m/s, and front-surface distance and heading are available to B-task programs in every run. Task success rules, held-out seeds, and training budgets are identical across runs.

Task Performance and Repeatability

tbl:11 preserves every run’s final frozen-program outcomes, including the pre-acquisition results for A02 and A04. Every completed run acquired wall-supported elevation, supported manipulation, and wall descent without exhausting a controller’s budget. None trained an additional controller for A03 or B01–B03. The remaining task failures occurred in completed executions.

Run	A01	A02	A03	A04	B01	B02	B03	Total	Rate (%)
1	50	0 → 50	47	0 → 50	46	49	50	342/350	97.71
2	49	0 → 50	50	0 → 50	50	50	49	348/350	99.43
3	50	0 → 50	49	0 → 50	50	50	49	348/350	99.43
4	50	0 → 50	50	0 → 50	48	50	49	347/350	99.14
5	49	0 → 50	50	0 → 50	50	50	49	348/350	99.43

Task	Success rate ($n = 5$)
A01	$99.2 \pm1.1$
A02	$100.0 \pm0.0$
A03	$98.4 \pm2.6$
A04	$100.0 \pm0.0$
B01	$97.6 \pm3.6$
B02	$99.6 \pm0.9$
B03	$98.4 \pm0.9$
Overall	$99.0 \pm0.7$

Task-level summaries use one success rate per acquisition run; overall summaries first divide each run’s final successes by 350. Sample standard deviations use the run-level denominator $n - 1$, with $n = 5$, and summarize variability across independent acquisition runs under the same starting configuration.

Acquired Controllers, Skills, and Helpers

tbl:13 maps exact controller identifiers to shared functional roles. All five runs acquired wall-supported elevation and supported manipulation during A02, then wall descent during A04. Each of their three controllers passed two confirmation sweeps over the same 15 development variants with one unchanged checkpoint, integration code, and confirmation program. Elevation sweeps confirm the prerequisite stance with the arm homed; supported manipulation and wall descent sweeps confirm composed A02 and A04 completion. These are development checks, separate from held-out task performance. All five runs reused acquired controllers on B02 without further controller training.

Run	Wall-supported elevation (A02)	Supported manipulation (A02)	Wall descent (A04)	Pitch (rad)
Claude 1	wall_rear_up	wall_rear_reach	wall_dismount	0.70
Claude 2	wall_rear_stance	wall_rear_reach	wall_rear_stand_down	0.85
Claude 3	wall_rear_stance	wall_rear_reach	wall_rear_dismount	0.85
Claude 4	wall_rear_up	wall_stance_reach	wall_step_down	0.70
Claude 5	wall_stance	wall_reach	wall_descent	0.68

Introduced skills and helpers. The following list describes the reusable skills and helpers introduced in the five runs. Skills package task-level robot behaviors; helpers provide supporting perception, geometric, navigation, or pose-control operations. Both can issue controller commands. Claude Run 5’s two acquired skills, wall_high_reach and floor_recover, are described in detail in Appendix B.

• Claude Run 1

  • reach_stance: Reach a target with 4 legs standing. A skill introduced in A01 and reused in A04.

  • level_grasp: Keeps the gripper level from a tilted stance and tracks the finger centre during object placement. A helper function introduced in B03.

  • upright_place: Places an object on the rack from a tilted stance, using stance measurements to determine the rack board height. A skill introduced in B03.

• Claude Run 2

  • base_motion: Provides wall-approach motion and base motion after returning to standing. A helper function used in A02–A04.

  • eef_pose: Provides end-effector pose-control routines and rotation calculations. A helper function whose rotation utilities are reused in A02–B03.

  • held_object: Records grasp geometry at gripper closure during floor pickup and uses it to plan placement from a tilted stance. A helper function introduced in B03.

• Claude Run 3

  • base_nav: Provides base navigation and arm holding while standing. A helper function used in A01 and A04 for tracking the target near the floor.

  • shelf_reach: Provides rack-grasp routines from a wall-supported stance, with the hind feet on the floor and front feet against the wall. A skill introduced in B02. B03 reuses its measurements during floor pickup and placement from a tilted stance.

  • wall_shelf_place: Composes floor pickup, elevation, reaching, and rack placement. A skill introduced in B03.

• Claude Run 4

  • base_stance: Provides base positioning before elevation. A helper function used in A02–A04, B02, B03.

  • eef_hold: Provides standing reach and end-effector holding. A helper function used in A01 and A04 for tracking low targets.

  • level_reach: Provides reaching for rack retrieval and placement from a tilted stance. A skill first introduced in B02 and B03 reuses it for placement from a tilted stance.

• Claude Run 5

  • base_nav: Navigates to a wall-facing stance and walks after returning to standing. A helper function used in wall_high_reach.

  • eef_reach: Provides end-effector pose-control routines for high goals from a wall-supported stance and low goals with all feet on the floor. A helper function used in wall_high_reach.

  • wall_high_reach: Composes wall alignment, supported elevation, and reaching to commanded targets. Developed in A02, it is reused for the elevated waypoints in A03 and A04, retrieval in B02, and placement in B03.

  • floor_recover: Homes the arm, descends from wall support, and restores a stable four-foot stance. Developed in A04 to enable the subsequent low waypoint, it is reused unchanged after B02’s elevated grasp while retaining the object.

The supplied floor_pickup skill was also revised in Claude Runs 2, 3, and 5.

Vector (PDF)

Training and Revision Effort

All five runs acquired wall-supported elevation, supported manipulation, and wall descent within a budget of $1.5 \times10^{9}$ environment steps per controller. B02 and B03 then reused acquired controllers without further training. Table 14 summarizes the resources used by each run, including unsuccessful pilots, restarts, and resumed segments. Training computation sums logged rollout-collection and learning times, excluding startup, evaluation, task execution, and agent work. It averages $5.5 \pm0.9$ h across the five runs.

Run	Training steps ($10^{9}$)	Training (h)	Controller-design revisions	Elapsed (h)	Model cost (USD)
Claude 1	1.30	5.2	3	21.9	$343
Claude 2	1.31	5.5	1	20.0	$258
Claude 3	1.54	6.2	5	21.3	$315
Claude 4	0.98	4.2	4	22.2	$268
Claude 5	1.55	6.3	4	20.7	$253

Across the five Claude runs, training takes 1.2–1.7 h for wall-supported elevation, 2.6–3.5 h for supported manipulation, and 0.4–2.0 h for wall descent. Supported manipulation accounts for the largest share of training time in every completed run. Controller acquisition involved iterative changes to the training formulation. The five runs required 1–5 controller-design revisions ($3.4 \pm1.5$ per run). These counts include changes to rewards, curricula, or termination conditions and exclude documentation changes and implementation or infrastructure repairs.

Runtime, Agent Usage, and Estimated Cost

The full A01–B03 sequence took 20.0–22.2 h across the five runs. Elapsed time includes controller acquisition, task-program development, and evaluation. Estimated model usage costs range from $253 to $343 per run, excluding GPU compute.

Failure Patterns and Interpretation

Task failures and integration. Claude Run 5’s A01 variant 38 timed out short of a low goal; its B03 variant 3 ended holding the object without entering elevation, with wall heading just outside the switch guard (Appendix B-D). Claude Run 3 required an A04 controller hand-back routing repair without additional training. Development repair successes may come from different program versions; the held-out counts evaluate each selected frozen program and library snapshot.

Scope of the evidence. The study tests acquisition within two supplied training templates and reuse on related tasks under a shared starting configuration. Independent repositories and empty acquired memories establish separation between runs. Development failures motivate capability hypotheses but do not establish that every possible program using the initial library would fail. Controller confirmation reuses development variants; held-out task evaluation measures unseen variants under nominal simulation physics.