Rapid Embodiment Adaptation: Go2 Walks With a Locked Leg

You spend thousands of hours training a quadruped robot to traverse rough terrain using Reinforcement Learning. The policy is perfect in the test environment. Then, six months into real-world deployment:

• The front-right hip joint starts to wear — range of motion drops to 60% of nominal.
• An engineer mounts a 4 kg 3D camera on the back for data collection.
• An unexpected terrain section causes a brief loss of balance.

A standard RL policy — trained under fixed hardware assumptions — fails immediately. This isn't a programming bug or poor design. It's a fundamental problem: the policy doesn't know what it's "carrying".

Researchers from UC San Diego, Technische Universität Darmstadt, and DFKI present Rapid Embodiment Adaptation for Quadrupedal Locomotion (arXiv 2608.01506, August 2026) — a framework that lets a robot identify its current hardware state in 0.5 seconds and adapt its gait accordingly, with no fine-tuning or manual recalibration required.

The Problem: Hardware Drift in Long-Term Deployment

Most locomotion RL papers tackle two main challenges: sim-to-real transfer and terrain generalization. But there's a third challenge that gets less attention: embodiment drift — the gradual or sudden change of the robot's own hardware.

Two of the most common embodiment changes in real deployment:

1. Joint-range constraints — reduced range of motion due to:

• Mechanical wear after thousands of operating hours
• Temperature-induced changes in actuator properties
• Partial failures: a joint no longer reaches full range
• Physical impact or damage

2. Trunk mass changes — altered payload due to:

• Mounting additional sensors, cameras, or tools
• Battery swaps or counterweight changes
• Object manipulation tasks where the robot carries items

With a standard RL policy, both cause the same outcome: instability, stumbling, or complete failure.

The key question: if a robot knew its current hardware state, could it adapt?

Core Intuition: Physical Self-Awareness

Before diving into the technical details, consider how humans adapt.

When you break your arm, your brain doesn't reset. It quickly recognizes the new constraints — can't fully extend, muscle strength reduced — and adjusts every movement within seconds. Similarly, when you put on a 10 kg backpack, your gait changes immediately: you lean forward, shorten your stride, slow your pace.

The core insight of Rapid Embodiment Adaptation: a robot can learn to "sense" its hardware state from a short interaction history, then condition its control policy accordingly.

Instead of one rigid policy, the framework proposes two coordinated modules:

• Cross-Embodiment Policy — a generalist policy trained to operate across a wide range of hardware configurations.
• Adaptation Module — a lightweight network that takes a short interaction history and estimates the current hardware state.

Architecture: Two Modules, One System

Cross-Embodiment Policy: URMA

The generalist policy uses URMA (Unified Robot Morphology Architecture) — designed to handle robots with varying morphologies and physical properties.

URMA has two components:

• Embodiment Encoder: encodes robot structure (topology, joint limits, mass distribution) into a latent vector.
• Action Decoder: takes the latent vector + current observations → produces joint targets.

The critical detail: during training, the policy receives ground-truth embodiment descriptor φ (a vector precisely describing hardware state). This teaches the policy to modulate its gait based on embodiment — but it cannot estimate φ from sensor data itself. That's the Adaptation Module's job.

Adaptation Module: LSTM + Transformer + MLP

This is the system's "proprioceptive sense". The architecture has three layers:

Layer 1 — LSTM Encoder:

• Input: history of 20 timesteps (≈0.4 seconds at 50 Hz)
• Each timestep: 8-dimensional feature vector per joint (position, velocity, torque, etc.)
• Embedding dimension F = 128

Layer 2 — Transformer Backbone:

• Self-attention across the joint dimension (joint-wise attention)
• Captures inter-joint relationships: when a hip joint is constrained, the knee must compensate

Layer 3 — Dual MLP Decoder:

• Per-joint head: estimates local parameters (joint-specific range limits)
• Global head: estimates body-level parameters (trunk mass offset)

Output: φ̂ — the estimated embodiment vector — fed into the Cross-Embodiment Policy in place of the ground-truth φ.

Why LSTM over a pure Transformer? The team benchmarked several encoder architectures (MLP, GRU, LSTM, Transformer). LSTM achieved the best validation RMSE at 2.02×10⁻² — its short-term temporal memory outperforms sequence-level attention for this task.

Training Pipeline: Two Separate Phases

The framework trains in two independent phases, which means each module can be swapped or improved without retraining the other from scratch.

Phase 1: Cross-Embodiment Policy with PPO

Environment: IsaacLab simulator, Unitree Go2.

Algorithm: PPO (Proximal Policy Optimization) with a performance-based curriculum.

Embodiment Randomization: at each episode reset, sample uniformly:

• joint_limit_scale ∈ [0.0, 0.5] — joint range is scaled down (0.0 = fully locked)
• trunk_mass_offset ∈ [-3.0, +7.0] kg — added or removed trunk mass

PD Controller: Kp = 20, Kd = 0.5 for joint tracking.

Reward function:

# Pseudo-code: embodiment randomization in IsaacLab
def reset_episode(env):
    joint_scale = np.random.uniform(0.0, 0.5)
    mass_offset = np.random.uniform(-3.0, 7.0)  # kg
    
    # Apply to simulation
    env.robot.joint_pos_limit_scale = joint_scale
    env.robot.trunk_mass += mass_offset
    
    # Return ground-truth embodiment descriptor
    phi = np.array([joint_scale, mass_offset])
    return phi

The curriculum starts with near-nominal embodiments and gradually exposes the policy to more extreme configurations. Without this, the policy tends to fail on extreme cases early and never recovers.

Phase 2: Adaptation Module (Offline Supervised Learning)

Once the generalist policy is ready, generate an offline dataset by rolling it out in simulation:

• 36 embodiment configurations (uniform grid across [joint_scale, mass_offset] space)
• 4,096 trajectories × 1,000 timesteps per configuration
• Train/validation split: 80%/20%

Objective: Supervised regression — minimize MSE between estimated φ̂ and ground-truth φ:

L = E_t[ ‖ f(h_t) − φ_t ‖² ]

The entire adaptation module training requires no real robot — only simulator trajectories. This means you can improve adaptation capability without spending any additional hardware time.

# Adaptation Module (PyTorch)
import torch.nn as nn

class AdaptationModule(nn.Module):
    def __init__(self, n_joints=12, feature_dim=8, embed_dim=128):
        super().__init__()
        self.lstm = nn.LSTM(
            input_size=n_joints * feature_dim,
            hidden_size=embed_dim,
            batch_first=True
        )
        self.transformer = nn.TransformerEncoderLayer(
            d_model=embed_dim, nhead=4, batch_first=True
        )
        self.per_joint_head = nn.Linear(embed_dim, n_joints)
        self.global_head = nn.Linear(embed_dim, 1)
    
    def forward(self, history):
        # history: (batch, 20 timesteps, n_joints * features)
        lstm_out, _ = self.lstm(history)        # (batch, 20, 128)
        attn_out = self.transformer(lstm_out)   # (batch, 20, 128)
        last = attn_out[:, -1, :]               # (batch, 128)
        return self.per_joint_head(last), self.global_head(last)

Real-Time Deployment

Deployment is straightforward — no fine-tuning, no calibration. The 50 Hz control loop:

1. Collect 20-timestep joint observation history → h_t
2. Adaptation Module: φ̂_t = f(h_t)          [<1ms, CPU inference]
3. Cross-Embodiment Policy: a_t = π(s_t, φ̂_t)
4. Send joint commands to PD controller

When hardware changes mid-run (a joint suddenly jams, a payload is added), the Adaptation Module detects the change and updates φ̂ within 0.4 seconds — no stops, no resets required.

Experimental Results

Simulation: Matching Oracle Performance

The team evaluated two scenarios on Unitree Go2 in IsaacLab:

Scenario 1 — Joint-range constraint:

• Sweep joint_limit_scale from 0.0 to 0.8
• Adaptive policy tracks oracle performance (knows exact φ)
• Non-adaptive baseline collapses at scale < 0.4

Scenario 2 — Trunk mass change:

• Mass offset swept from -3 kg to +7 kg
• Convergence in <0.5 seconds after abrupt mass change

Real-World: Unitree Go2

Hardware experiments under two extreme conditions:

The numbers are striking:

• With a nearly fully locked leg (only 30% of normal range): the adaptive policy achieves 100% success — 4× better than baseline.
• With a 5 kg payload: the baseline completely fails (0%), while the adaptive framework achieves 62.5%.

The 62.5% success rate for the payload scenario also reveals room for improvement — handling extreme dynamic changes remains an open challenge. But 62.5% versus 0% is an enormous practical gap.

Setting Up IsaacLab for This Experiment

You can reproduce the core framework using IsaacLab and a Unitree Go2 (or any compatible quadruped):

# 1. Install Isaac Sim + IsaacLab
git clone https://github.com/isaac-sim/IsaacLab.git
cd IsaacLab
./isaaclab.sh --install

# 2. Activate the conda environment
conda activate isaaclab_env

# 3. Install additional dependencies
pip install torch torchvision
pip install stable-baselines3  # or skrl for PPO

IsaacLab already includes Unitree Go2 assets and locomotion environments. You'll need to extend the locomotion environment to:

1. Add embodiment randomization to the episode reset function
2. Include the ground-truth embodiment descriptor in observations during training
3. Wrap the deployment loop with the Adaptation Module at inference time

One practical note: the large offline dataset (36 configs × 4096 trajectories × 1000 steps) requires significant disk space but the Adaptation Module itself can be trained on CPU in a few hours.

Why This Matters: The Deployment Gap

Most locomotion RL frameworks — including Walk These Ways, DribbleBot, and parkour policies — assume hardware stays constant. That assumption is fine for short demos but breaks down in any real long-term deployment.

Rapid Embodiment Adaptation addresses this "deployment gap" and points toward three important capabilities:

1. Long-term autonomous operation — robots that can run for months without periodic recalibration or policy retraining.

2. Graceful degradation — when hardware starts failing, performance degrades slowly and predictably rather than catastrophically.

3. Hardware-agnostic policies — a single trained policy that works across variant platforms: Go2, Go2-W, a Go2 with a custom payload arm, all without per-variant retraining.

Open directions: the current framework handles two embodiment change types. Future work could extend to motor failures, terrain-induced compliance, foot pad wear, or tool attachment — any physical change that alters robot dynamics.

If you're working on quadruped locomotion with RL or planning a sim-to-real deployment pipeline, this paper is required reading for anyone thinking beyond the lab demo and into sustained field deployment.

Paper: arXiv 2608.01506
Project page: embodiment-adaptation.github.io
Authors: Dichen Li, Bo Ai, Nico Bohlinger, Jan Peters, Hao Su, Henrik I. Christensen
Institutions: UC San Diego · TU Darmstadt · DFKI

Related Posts

• RL Locomotion Fundamentals: Reinforcement Learning for Quadruped Robots
• Sim2Real Transfer for Locomotion: From Simulator to Real World
• APT-RL: Multi-Skill Locomotion for Quadrupeds 2026