Hiking in the Wild: A Scalable Perceptive Parkour Framework for Humanoids

In plain words

Teaching a robot to walk on a flat floor is common. Getting a humanoid to climb stairs, cross gaps and run over rough ground is harder, because it has to see the ground ahead and place its feet carefully. This paper trains a small humanoid with reinforcement learning, in simulation, to do this from one forward depth camera and its own joint and motion sensors. It uses no map and no external localization.

Two ideas keep training and the real robot safe. First, the simulator finds the sharp edges of the terrain and penalises feet that touch them, so the robot learns to step on the centre of a surface. Second, instead of random speed and turn commands, which can teach a robot to spin in place, training gives goals on flat spots the robot can actually reach. A style discriminator also pushes the gait toward natural motion.

The paper reports that the robot runs, climbs and steps over obstacles on real hardware this way. The tests cover one robot model and a limited set of terrains.

TL;DR

• One RL policy maps forward depth images and proprioception straight to joint position targets, with no map or external localization §3.1.
• A terrain edge detector and foot-attached volume points penalise foot contact near sharp edges §3.3.
• Flat-patch sampling gives goals on reachable flat ground, which become speed-controlled velocity commands §3.4.
• Author-reported: zero-shot transfer to the Unitree G1, running at up to 2.5 m/s §4.1.
• The official code is non-commercial (CC BY-NC 4.0). This card quotes none of it.

Problem

Blind locomotion is robust on irregular ground but cannot see deep gaps or high steps ahead §1. LiDAR elevation methods need precise localization and suffer motion distortion at speed §1§2. Depth methods that reconstruct heightmaps are limited to low speed and structured scenes §1. Foot placement on a terrain edge can cause slips and falls, a failure the authors say prior work handled only with terrain-specific constraints §1§2. Uniformly sampled random velocity commands can make the policy learn to spin in place instead of crossing obstacles §1§3.4.

Method

The pipeline has four parts: a POMDP policy trained with PPO and an asymmetric critic §3.1; an egocentric depth pipeline with simulated and real alignment §3.2; an edge-aware penalty for foot placement §3.3; and goal-based velocity commands with an AMP style reward §3.4§3.5. Figure 2 gives the system overview fig. 2.

3.1 Problem formulation and control

The task is a POMDP trained with PPO §3.1. The actor receives a history of proprioceptive states (angular velocity, projected gravity, velocity commands, joint positions and velocities, last action) and a strided depth history, with noise applied during training §3.1tab. 3tab. 4. The critic also sees noise-free states and base linear velocity §3.1tab. 3. The policy outputs 29 target joint positions, executed by PD control \boldsymbol{\tau}_t = k_p(\mathbf{a}_t - \mathbf{q}_t) - k_d\dot{\mathbf{q}}_t with gains taken from BeyondMimic; the paper gives no gain values §3.1 tab. 3.

Episodes end on time-out, leaving the terrain bounds, torso contact, excessive base tilt, or root height below 0.5 m app. A.2. The reward has task, regularisation, safety and AMP terms, with weights in tab. 5 §3.1.

At deployment, velocity commands come from a human operator through a remote controller. The position-based command generator is used during training only app. B.

3.2 Ego-centric depth perception

A GPU ray-caster built on NVIDIA Warp renders depth in simulation §3.2. The radial distance is the first intersection along each pixel ray, and the orthogonal depth is its projection on the camera axis app. A.4 eq. 4 eq. 5.

d_{i,j} = \min \{ \tau \mid \mathbf{p}_c + \tau \mathbf{v}_{i,j} \cap \mathcal{G} \neq \emptyset \} eq. 4

z_{i,j} = d_{i,j} \cdot (\mathbf{v}_{i,j} \cdot \mathbf{n}_c) eq. 5

Two pipelines map simulated and real depth into one perception space §3.2 fig. 3.

• Simulation pipeline F_sim app. A.4: crop and resize to the terrain region; add range-dependent Gaussian noise inside the valid range; mask contiguous pixels as invalid to imitate stereo matching failures; blur to imitate motion blur; clip and normalise to [0, 1]; with probability P_ood, replace the whole observation with Gaussian noise.
• Real pipeline F_real app. A.4: crop and resize to the simulation geometry; inpaint zero-valued pixels caused by occlusion or disparity shadows; blur to suppress sensor jitter.

The policy sees m frames sampled with temporal stride ℓ §3.2. The history is H_t = {I_{t−kℓ−1} | k = 0, …, m−1}, which covers (m−1)ℓ steps with m frames app. A.4 eq. 6.

\mathcal{H}_t = \{ I_{t - k \cdot \ell - 1} \mid k = 0, 1, \dots, m-1 \} eq. 6

On hardware, depth acquisition and preprocessing run asynchronously at 60 Hz, and the policy runs at 50 Hz on the latest depth frame §3.2app. B. In training, a one-frame delay imitates sensor latency §3.2app. A.4.

3.3 Terrain edge contact penalisation

RL agents tend to step on the nearest terrain edge to save energy. In simulation this works because contact is simplified, but on hardware it causes slips §3.3. The paper adds a soft penalty in three steps §3.3.

1. Detect sharp edges. Compare the dihedral angle between adjacent faces with a threshold τ, then merge short fragments with a greedy concatenation that merges collinear segments §3.3.1alg. 2alg. 3. The threshold value is not stated in the paper.
2. Build edge volumes. Turn each edge into a cylinder of radius r and index the cylinders in a spatial grid alg. 2.
3. Place volume points on the feet. Distribute points inside each foot's collision geometry. Each point's penetration depth into the edge grid is found with parallel distance queries §3.3.2.

The penalty sums, over all volume points, the penetration depth times the point speed plus a small constant §3.3.2 eq. 1. The weight is −4.0 tab. 5.

r_{vol} = \sum_{i=1}^{|\mathcal{P}|} \|\mathbf{d}_i\| \cdot (\|\mathbf{v}_i\| + \epsilon) eq. 1

Here d_i is point i's penetration offset and v_i its world-frame velocity. Equation 1 states ε = 10⁻³ §3.3.2, but appendix A.5 lists ε = 10⁻⁶ among its parameters app. A.5. See Pitfalls.

3.4 Position-based velocity command generation

Commands come from reachable flat patches on the terrain §3.4. A patch is accepted as a goal only if the height variation inside radius r stays below a threshold δ §3.4 alg. 1 fig. 9.

# Flat patch sampling  [alg. 1] [app. A.5]
# Input: mesh, patch radius r, max height difference delta
# Output: list of valid targets

def sample_flat_patches(mesh, radius, max_height_diff, num_targets):
    # Keep drawing random positions until enough targets are found  [alg. 1]
    targets = []
    while len(targets) < num_targets:
        x, y = random_position_in_environment()
        # Heights of ray-cast hits within the radius  [alg. 1]
        heights = raycast_heights(mesh, x, y, radius)
        # Accept only flat patches  [alg. 1] [app. A.5]
        if max(heights) - min(heights) < max_height_diff:
            targets.append((x, y, mean(heights)))
    return targets

Every so often, one target is chosen as the goal §3.4. Let (x_g, y_g) be the goal in the base frame. The commands are §3.4 eq. 2 eq. 3:

v_x = \text{clip}(k_v \cdot x_g, 0, v_{max}), eq. 2

\omega_z = \text{clip}(k_{\omega} \cdot \text{atan2}(y_g, x_g), -\omega_{max}, \omega_{max}) eq. 3

where k_v and k_ω are stiffness gains and v_max and ω_max are limits adjusted per terrain category §3.4. The lateral command v_y is zero, since only the forward camera is used §3.4. A small subset of agents on flat terrain receive pure turning commands (v_x = 0 with random ω_z) so the policy learns to turn in place §3.4.

# Position-based velocity command  [§3.4] [eq. 2] [eq. 3]
# Input: goal (x_g, y_g) in the base frame

def velocity_command(goal_x, goal_y, gain_v, gain_w, v_max, w_max):
    # Forward speed grows with goal distance, clipped to [0, v_max]  [eq. 2]
    v_x = clip(gain_v * goal_x, 0.0, v_max)
    # Turn rate points the base at the goal, clipped to +/- w_max  [eq. 3]
    w_z = clip(gain_w * atan2(goal_y, goal_x), -w_max, w_max)
    # Lateral speed stays zero: only the forward camera is used  [§3.4]
    v_y = 0.0
    return v_x, v_y, w_z

3.5 Policy training with adversarial motion priors

The style reward comes from AMP §3.5. Walking and running use separate reference datasets: walking combines MPC-generated walking and retargeted human mocap of stair and platform traversal, and running uses LAFAN running clips §3.5app. A.9. The paper says joint training gave fast walking with long strides rather than natural running §3.5app. A.9. The running clip is one gait cycle (1.54 s) app. A.9.

The discriminator takes short state sequences rather than single transitions §3.5. It is trained with a least-squares loss app. A.9 eq. 7 and feeds back the style reward in eq. 8 app. A.9.

L_D = \mathbb{E}_{\mathcal{M}}[(D(\mathbf{S}) - 1)^2] + \mathbb{E}_{\mathcal{P}}[(D(\mathbf{S}) + 1)^2] eq. 7

r_t = \max\left[ 0, 1 - 0.25(D(\mathbf{S}_t) - 1)^2 \right] eq. 8

The gradient penalty and weight decay are described qualitatively app. A.9. The style term has weight 0.25 tab. 5.

3.6 Network architecture

The visual encoder is a CNN over the strided depth history, followed by an MLP, producing a 128-dim embedding that is concatenated with proprioception [app. A.7] tab. 6. The actor is a 4-expert mixture of experts with a gating network app. A.7 tab. 6. The AMP discriminator has hidden sizes [1024, 512] with ReLU tab. 6.

# Policy step at 50 Hz  [§3.1] [app. A.7] [app. B]
# Input: proprio_history (B, 8, n), depth_history (B, m, 18, 32)
# Output: joint_targets (B, 29)

def policy_step(proprio_history, depth_history, command):
    # Encode the strided depth history  [app. A.7] [tab. 6]
    depth_embedding = depth_encoder(depth_history)    # (B, 128)
    # Gate and weight the experts from the observation  [app. A.7]
    gate_weights = gating_network(proprio_history, command, depth_embedding)
    joint_targets = mixture_of_experts(
        gate_weights,
        concat(proprio_history, command, depth_embedding),
    )
    # Targets go to PD control  [§3.1]
    return joint_targets

3.7 Training schedule and post-training

Training runs in Isaac Sim and Isaac Lab on one RTX 4090 with 4096 parallel agents app. B. Terrains come from a curriculum-based generator with 10 × 20 sub-terrains of 8 × 8 m app. A.6. The paper does not describe the curriculum rule. Walls are placed around terrains with probability 0.3 app. A.6.

After general walking training, three specialised policies (stair walking, platform walking, running) are fine-tuned for 40,000 iterations each from the walking checkpoint, with narrower velocity ranges: walking v_x in [0.45, 0.55] m/s and running v_x in [1.95, 3.05] m/s app. A.8. On the robot, a policy switch is a stop, a stand, then the new locomotion policy §4.1.

Hyperparameters

Values in the paper are cited to their source. "not stated" means the paper gives no value. Code values come from the official repository at the recorded commit and are cited to it. The code column is not in the paper.

Reward weights and formulas in tab. 5 match the code for every term checked, except the stand-still condition (see Paper vs code). Code: parkour_env_cfg.py.

Results

Author-reported. Hardware uses the Unitree G1 with a 29-DoF body app. B. The headline results are a 2.5 m/s maximum running speed, platforms up to 32 cm, gaps of 50 cm, and a 4-minute walk over stairs and flat ground without falls §4.1. Each terrain–gait pair was tried in 10 trials, and a trial counts as a success only if the robot reaches the end and stops stably §4.1 fig. 6.

Edge penalty, simulation and hardware tab. 1 §4.2. Simulation uses 1000 robots over 10,000 steps §4.2.

Source: tab. 1. The landing-area fraction is the share of the foot area on the surface, computed only when the base is within interaction range of the obstacle §4.2. The paper states that "No Edge" is the variant without edge penalisation §4.2; its exact construction is not stated.

Comparison and ablation, simulation tab. 2 §4.3. Each method uses one generalist walking policy across terrains. Success rates (%):

Mean reaching time (s), successful trials only; "--" means no trial succeeded within 15 s app. C tab. 2:

The paper claims the highest success rates, not the fastest times. Ours is not the fastest on Ramp (w/o AMP is faster) or Stair Down (10 Hz height map is faster), and ties the 10 Hz height map on Platform down tab. 2.

Other results. Figure 6 shows real-world success rates for each terrain–gait pair that was tested fig. 6. Figure 5 shows the zero-shot traversals fig. 5. Figure 7 shows the edge detector on new terrain types: stones, stakes and noisy scans §4.2 fig. 7. The authors report that the detector needed no per-terrain tuning there §4.2.

Paper vs code

Checked at commit de6b92f01eb155d51f30e8ed1ea7aecd2eb1f057 of project-instinct/InstinctLab, which the project page linked from the abstract links. The repository is CC BY-NC 4.0 LICENSE.

Matches the paper. Reward weights in tab. 5 (for the terms checked), termination thresholds app. A.2, the feet-distance shape of the feet-spacing reward, the velocity gains k_v = k_ω = 2.0 app. A.5, policy sizes tab. 6, the discriminator sizes, the 50 Hz policy and 4096 environments app. B. Code: parkour_env_cfg.py rewards.py.

Differs from the paper.

• Depth noise. The paper's F_sim has range-dependent noise, disparity artifacts and OOD replacement app. A.4. The parkour training config applies only crop, Gaussian blur and normalisation parkour_env_cfg.py. The noise classes are imported there but not used parkour_env_cfg.py.
• F_real. No inpainting code was found anywhere in the repository. Deployment code is not in this repository; only ONNX export is onnxer.py.
• Edge ε. Eq. 1 uses 10⁻³ §3.3.2; the code uses 10⁻⁶ volume_points.py.
• Edge region. The paper gives no size. The code treats each sharp edge as a cylinder of radius 0.05 m parkour_env_cfg.py cylinder.py.
• Greedy tolerance. The paper's ε is unstated. The greedy merge uses a fixed 0.05 m tolerance edge_cylinder.py. The configured point_distance_threshold of 0.06 m is not used by this detector edge_cylinder_cfg.py.
• Volume points. The paper places points inside each foot's collision geometry §3.3.2. The code uses a regular grid on the ankle link parkour_env_cfg.py.
• Yaw clamp. The paper says ω_max adapts per terrain §3.4. The code clamps ω to the fixed range ±1.0 rad/s pose_velocity_command.py. The per-terrain turn limit is computed but never applied pose_velocity_command.py.
• Flat patches. The paper uses one radius, r = 0.2 app. A.5. The config uses four radii parkour_env_cfg.py. The sampler is FlatPatchSamplingCfg from IsaacLab, which is not in this repository parkour_env_cfg.py.
• In-place turning. The paper gives pure turns to a small subset of agents on flat terrain §3.4. The code applies random turns to the whole perlin_rough_stand sub-terrain, which is 5% of terrain parkour_env_cfg.py. Random turns with |ω| ≤ 0.5 are set to zero pose_velocity_command.py.
• Stand-still penalty. Table 5 conditions on both the linear and the angular command tab. 5. The code checks only the linear command rewards.py.
• Camera rate. The paper gives 60 Hz depth on hardware §3.2. The simulated camera updates every 0.02 s parkour_env_cfg.py.
• Depth delay. The paper says one frame §3.2. The config samples the delay from (0, 1) parkour_env_cfg.py exteroception.py.
• Actuators. The paper mentions BeyondMimic gains only §3.1. The code uses a delayed PD actuator for the legs unitree_g1.py.
• Extra termination. The code adds a dataset-exhausted termination that the paper does not mention parkour_env_cfg.py.
• Post-training. The 40,000-iteration fine-tuning and the narrower speed ranges app. A.8 were not found in the parkour task code (searched for those values).
• Training schedule. PPO clip, learning rate, epochs and iteration count are not stated in the paper §3.1. Code values are in the Hyperparameters table.

Pitfalls

• Edge penalty constant. Eq. 1 says ε = 10⁻³, while appendix A.5 lists 10⁻⁶ among its parameters §3.3.2 app. A.5. The code uses 10⁻⁶ volume_points.py. The penalty is linear in depth and speed, so the constant changes its size mostly for near-zero speeds.
• Edge detection. The paper gives no threshold for sharp edges. The code uses 70° on the mesh's face-adjacency angles, which are angles between face normals edge_cylinder.py edge_cylinder_cfg.py. Other meshes need their own threshold.
• Edge region size. Penetration is measured against 5 cm cylinders around the detected edges, not against the surface parkour_env_cfg.py. A volume point within 5 cm of a detected edge is penalised, whether or not it touches the surface.
• Volume points. Points are a fixed grid on the ankle link. Their z-range depends on the shoe model g1_parkour_target_amp_cfg.py.
• Velocity command. With only_positive_lin_vel_x on, forward speed is clipped to [0, max] and lateral speed is zero parkour_env_cfg.py. Once the goal is within 0.4 m, the whole command is set to zero parkour_env_cfg.py pose_velocity_command.py.
• Reward hacking. The paper's stand-still term and the code's differ, so spinning in place is penalised differently tab. 5 rewards.py.
• Sim vs hardware terrain. Simulated gaps are 0.60 m tab. 8; the hardware gap is 50 cm §4.1. Simulated and hardware results are not on the same terrain.
• Small trial counts. Real-world results are 10 trials per combination §4.1. The paper's limitations section says the results do not establish generalisation across robots or dynamic environments §5.
• Speed headline. The 2.5 m/s figure is a maximum on the test terrain §4.1. The running policy was trained on a single gait cycle of reference motion app. A.9.
• Hardware safety. The paper says testing needs continuous human supervision, an emergency stop and an exclusion zone, and that the results do not establish safety for unsupervised operation near people app. B.
• Licence. The repository is CC BY-NC 4.0, so it may not be used commercially LICENSE. This card cites its code paths and paraphrases behaviour, and quotes no code.

Lineage

• Builds on: BeyondMimic for PD gains §3.1 (arXiv:2508.08241); AMP for the style reward §3.5; Robot Parkour Learning for the volume-point penalty, which it follows §3.3.2; Extreme Parkour for edge penalisation §2.
• Compared against: Humanoid Parkour Learning (HPL), reimplemented for the G1 §4.3; a 10 Hz height-map baseline following BeamDojo §4.3.
• Superseded by: not known from content already in this wiki.