企业官网建设流程全解析

在机器人运动控制里，让一个足式机器人“保持跑步姿态”和让它在平地上保持站立完全是两个难度等级。站立控制只需把重心维持在支撑面内，而跑步要求机器人周期性离开地面、在前向速度较高的条件下调整躯干姿态，并在落地瞬间消化冲击。传统控制方法依赖精确的动力学模型和接触时序规划，一旦速度变快、地面情况变化，鲁棒性就明显下降。强化学习把这个问题重新定义为“在奖励函数引导下试错学习”，机器人不再需要人为写出每一步的落脚点，而是通过与仿真环境大量交互，学会一种稳定的跑步姿态。下面围绕“强化学习让机器人保持跑步姿态而非人形”这条主线展开，先说明跑步控制难在哪，再给出一个可复现的仿真训练思路，最后整理训练验证和真实迁移时的排查路径。

1. 先理解“跑步姿态”为什么不能靠固定输出给定

1.1 跑步姿态的核心特征：支撑相与腾空相交替

跑步姿态不是简单地把机器人当成“直立人偶”推着往前走。无论是双足人形机器还是四足机器人，跑步本质上是支撑相（stance）和腾空相（flight）以一定节奏交替。支撑相中，腿部负责蹬地；腾空相中，机器人整体离开地面，需要靠髋、膝、踝的姿态调整准备下一次落地。落地时，地面反作用力会带来明显冲击，腿部关节需要弯曲缓冲。

这意味着跑步姿态的判断不能只看“有没有向前移动”，还要看是否存在腾空相、躯干是否前倾、下肢是否弯曲。很多强化学习训练的机器人会学到“原地蹦跳”或者“快速甩腿”这类假动作，因为它在奖励数值上满足了某个指标，但并没有形成真正的跑步节奏。这也是反复强调“跑步姿态而非人形”的原因：外观是不是人形不重要，重要的是运动模态是否符合跑步的动力学特征。

1.2 传统控制方法在高速运动中的瓶颈

传统足式机器人控制里常出现几个概念：零力矩点（ZMP）、模型预测控制（MPC）、混合动力规划。ZMP 方法适用于脚底始终与地面接触的慢速行走，因为它假设机器人与地面存在连续支撑，重心投影保持在支撑多边形内。跑步过程中机器人会腾空，ZMP 的连续接触假设直接失效。MPC 通常需要已知的动力学模型和接触时序，虽然能在每个控制周期内求解最优关节力矩，但对模型误差和外部扰动敏感。为了让机器人在跑步时稳定，需要显式规划每一步的接触时间，而接触事件本身的离散特性让优化问题变得复杂。这样一来，传统方法在实验室里可以调出一次漂亮跑步，但一旦换地面、换负载或遇到随机扰动，很容易重新变成“只能走、不能跑”。

1.3 强化学习为什么适合这个场景

强化学习的优势不在“无需模型”这个表面说法，而在于它把策略表示成参数化网络，通过大量试错去拟合一个稳定映射：从当前状态到下一步动作。跑步过程中的接触事件不需要显式编码，网络可以从奖励信号里自动归纳出“什么时候蹬地、什么时候收腿、什么时候让躯干前倾”。从实现角度看，一个策略网络只需要一组参数，输入是关节角度、角速度、机身姿态、速度等信息，输出是目标关节角度，经过 PD 控制器产生力矩。这种结构天然适合连续控制问题，也适合在仿真环境里并行采集大量经验。

但强化学习不是免调参的。它把“如何调速”问题转移成“如何设计奖励函数”和“如何构建逼真的交互环境”。尤其是奖励函数，如果设计不当，很容易学到高奖励但低质量的跑步姿态。

2. 搭建一个能体现跑步姿态的仿真实验环境

2.1 先选一个适合足式运动仿真的平台

跑步的关键动作是脱离地面、落地、摆动，仿真平台必须具备准确的接触模型、刚体碰撞检测和关节执行器模型。常见的选择有 MuJoCo、Isaac Gym 和 PyBullet。

实际项目里没有“最好”的平台，只有更符合当前训练阶段的选择。建议先用 MuJoCo 或 PyBullet 调试奖励函数，等基本能跑但效果不稳定时，再迁移到 Isaac Gym 这类支持 GPU 并行的平台做大规模训练。这里的选型原则是先求可解释，再求训练效率。如果要复现下面的示例，建议准备 Python 3.9 以上的环境，并确认已经安装能正常加载的 MuJoCo 版本。不同版本之间 API 差异比较大，落地前先跑一下官方示例环境，确认渲染和 step 都正常。

2.2 依赖准备与项目目录

下面以 Python 环境为例，给出一个尽量小的依赖集合。实际版本以安装时 pypi 上的最新稳定版为准，不要盲目固定到某个具体版本号。

pip install gymnasium pip install mujoco pip install torch pip install stable-baselines3

stable-baselines3 是一个基于 PyTorch 的强化学习算法库，内部实现了 PPO、SAC 等常用算法，适合快速验证训练思路。如果项目对训练逻辑有特殊要求，可以只参考下面的奖励函数和训练流程，再改用自研训练脚本。

项目目录建议如下：

run_framing/ ├── envs/ │ └── runner_env.py ├── rewards/ │ └── runner_reward.py ├── train_ppo.py ├── eval_run.py └── configs/ └── ppo_config.yaml

这个目录结构把环境、奖励、训练、评估分开，奖励函数改动时不需要碰环境代码，训练配置也可以单独维护。需要强调的是，这里给出的都是示例结构，真实项目里要替换成自己的环境名和模型文件路径。

2.3 创建 Runner 环境，把“跑步姿态目标”翻译成观测和奖励

在 Gymnasium 风格的环境里，每次调用 step 时接收一个动作，返回下一时刻的观测、奖励、终止信号和额外信息。跑通强化学习的关键是让环境可以连续稳定地被重置和推进。

下面是一个最小环境封装的示例：

# envs/runner_env.py import numpy as np import gymnasium as gym from gymnasium import spaces class RunnerEnv(gym.Env): def __init__(self, render_mode=None, target_speed=1.5): super().__init__() self.robot = load_robot_model() # 具体模型按实际项目接入 self.observation_space = spaces.Box( low=-np.inf, high=np.inf, shape=(n_state,), dtype=np.float32 ) self.action_space = spaces.Box( low=-1.0, high=1.0, shape=(n_action,), dtype=np.float32 ) self.target_speed = target_speed def reset(self, seed=None, options=None): obs = self.robot.reset_to_random_pose() return obs, {} def step(self, action): action = self.unscale_action(action) # 把 [-1,1] 映射到关节角度范围 self.robot.apply_target_angles(action) self.robot.advance(dt=0.02) obs = self.robot.get_observation() reward = compute_runner_reward(obs, action) terminated = self.robot.is_fallen() or self.robot.is_out_of_range() truncated = self.robot.episode_timeout() info = { "forward_velocity": self.robot.get_forward_velocity(), "pitch": self.robot.get_pitch(), "feet_contact": self.robot.get_feet_contact_flags(), } return obs, reward, terminated, truncated, info

这个示例省略了机器人的具体加载代码，因为不同机器人模型的命名空间、关节名称和状态量都不一样。重点关注环境接口做了什么：动作先做范围映射，再转换为目标关节角度；状态量只暴露给策略训练；终止条件由机器人是否摔倒决定；info 里保存用于调试验证的关键指标。训练前可以先跑几十步，确认机器人能正常推进，不会在 step 里出现 NaN 或崩溃。

3. 用 PPO 训练策略，让机器人保持跑步姿态

3.1 动作空间选择：目标关节角加 PD 控制器

强化学习策略的输出常见有两种选择：直接输出关节力矩，或输出目标关节角度。直接输出力矩让策略有更大的表达能力，但也更容易产生高频抖动和超限；输出目标角度则由底层 PD 控制器把当前关节角度平滑地拉向目标，动作更接近真实机器人执行器的行为。跑步这种高速运动，推荐使用“目标关节角度 + PD 控制器”的组合。

每个关节的力矩可以写成：

tau = Kp * (target_angle - q) - Kd * q_dot

其中q是当前关节角，q_dot是关节角速度，Kp和Kd是比例、微分增益。这个公式说明两件事：一是策略动作是“位置参考”而不是直接暴力输出力矩；二是底层控制器会自然产生与速度方向相反的阻尼，减少策略震荡。实际仿真里，动作频率通常控制在 30Hz 到 100Hz，过高会导致真实机器人难以复现。

3.2 奖励函数是训练目标，也是常见的失败来源

奖励函数决定强化学习会用什么样的步态获得高分。很多人一开始就把“速度、高度、接触、平滑”全部塞进奖励项，结果机器人学出一个综合收益高、但步态奇怪的动作。更稳妥的做法是先从最核心的目标开始：让机器人稳定获得前向速度。目标速度不需要一次到位，可以先设一个较低的慢跑速度，等策略能连续跑起来，再逐步提升。

下面给出一个用于说明的奖励函数示例：

# rewards/runner_reward.py import numpy as np def compute_runner_reward(obs, action, prev_action=None, target_speed=1.5, dt=0.02): lin_vel_x = obs["lin_vel_x"] pitch = obs["pitch"] knee_bend = obs["knee_bend"] feet_contact = obs["feet_contact"] # 1. 前向速度接近目标 r_speed = np.exp(-(lin_vel_x - target_speed) ** 2 / 0.5) # 2. 躯干保持轻微前倾，不要求完全直立 pitch_target = -0.2 # 负方向表示前倾 r_pitch = np.exp(-(pitch - pitch_target) ** 2 / 0.1) # 3. 膝盖保持可弯曲，避免锁直 r_bend = np.exp(-(knee_bend - 0.4) ** 2 / 0.05) # 4. 动作幅度惩罚，避免无意义的大幅甩腿 r_energy = -0.01 * float(np.sum(action ** 2)) # 5. 动作变化率惩罚，避免高频抖动 if prev_action is not None: r_smooth = -0.05 * float(np.sum((action - prev_action) ** 2)) else: r_smooth = 0.0 return r_speed + r_pitch + r_bend + r_energy + r_smooth

这里的关键是为“跑”而不是“站”设计姿态项。所谓“保持跑步姿态而非人形”，在奖励层面体现为两点：躯干可以有持续前倾，膝盖不必保持直立，机器人要追求高速前移而不是维持一个优雅的人形站姿。如果把奖励改成“俯仰角为 0、膝盖接近直立”，模型大概率会学成僵硬直立滑行，而不是跑步。另外，所有系数都是示例值，实际项目的奖励范围、状态量量纲都不一样，需要重新标定。

3.3 训练脚本和关键超参数

直接用 stable-baselines3 的 PPO 跑通一个训练流程，可以这样写：

# train_ppo.py from stable_baselines3 import PPO from stable_baselines3.common.vec_env import DummyVecEnv, VecNormalize from envs.runner_env import RunnerEnv def make_env(): env = RunnerEnv(render_mode=None, target_speed=1.5) return env vec_env = DummyVecEnv([make_env]) vec_env = VecNormalize(vec_env, norm_obs=True, norm_reward=True) model = PPO( "MlpPolicy", vec_env, learning_rate=3e-4, n_steps=2048, batch_size=128, n_epochs=10, gamma=0.99, clip_range=0.2, ent_coef=0.005, verbose=1, ) model.learn(total_timesteps=5_000_000) model.save("ppo_runner")

VecNormalize 会把观测和奖励标准化，这在状态量量纲差异很大时很有用。训练规模方面，本地单环境跑 500 万步可能需要一段时间，如果项目允许，应使用多个并行环境或者 GPU 仿真加速。

PPO 超参里，最需要关注的几个如下：

3.4 训练日志怎么读，奖励一直涨不代表学会了跑步

训练过程中最容易出现的误判，是只盯着 training reward 曲线。由于奖励函数里已经包含了姿态项和能耗惩罚，reward 上升只能说明策略在优化这些数值，不能证明它学会了真正的跑步。要判断策略质量，必须从训练日志和每 episode 的 info 中提取运动学指标。推荐的日志字段至少包括：

• 平均前向速度
• 躯干俯仰角均值和标准差
• 脚部接触标志的平均时间占比
• 单 episode 内机器人跌倒次数
• 动作平均幅值和相邻动作差分

如果 forward velocity 稳定在目标速度附近，且 pitch 在一个较小范围内波动，说明策略在控制上已经具备跑步的基础能力。此时再进入下一步，观察接触时序和关节轨迹，确认是否真的存在腾空相和周期性摆动。

4. 验证结果：怎么判断机器人是在“跑步”而不是“走路”或“蹦跳”

4.1 回放与记录：把状态轨迹保存下来

训练完成后，不能只看最终奖励。要把策略放到环境中回放，逐帧记录关键状态量。

# eval_run.py import numpy as np from stable_baselines3 import PPO from stable_baselines3.common.vec_env import DummyVecEnv, VecNormalize from envs.runner_env import RunnerEnv env = RunnerEnv(render_mode="human", target_speed=1.5) env = VecNormalize(env, norm_obs=True, norm_reward=False) model = PPO.load("ppo_runner.zip", env=env) obs, _ = env.reset() history = {"lin_vel_x": [], "pitch": [], "feet_contact": [], "episode_len": 0} for _ in range(200): action, _ = model.predict(obs, deterministic=True) obs, reward, terminated, truncated, info = env.step(action) history["lin_vel_x"].append(info["forward_velocity"]) history["pitch"].append(info["pitch"]) history["feet_contact"].append(info["feet_contact"]) history["episode_len"] += 1 if terminated or truncated: break

回放时建议同时打开渲染窗口，肉眼观察步态是否协调。跑步不是简单地把腿频率加快，而是要有腾空相：两脚同时离地的时段不能过长也不能没有。

4.2 定义一组可判读的跑步指标

为了不靠肉眼判断，可以定义一组计算方便的运动指标：

腾空相占比可以用下面这段代码快速计算：

contact = np.array(history["feet_contact"]) both_in_air = np.all(contact == 0, axis=1) flight_ratio = both_in_air.mean() print("flight ratio:", flight_ratio)

这里的取值范围只用于说明，不同机器人的尺寸、质量和关节配置会导致完全不同。关键是方法：用连续的物理量而不是单一奖励值判断步态质量。如果平均速度达标，但腾空相占比一直为 0，说明策略学到的是快速走路，不是跑步姿态。

4.3 用轨迹对比“跑步姿态”与“人形直立行走”

本文标题强调“跑步姿态而非人形”，在验证阶段尤其需要注意。一个策略可能在数学上获得了较高奖励，但最终动作是在原地不断屈膝、甩腿，或者看起来像直立滑冰。这种时候可以把同一策略在目标速度高、低两个设置下分别评估。如果高目标速度下机器人的躯干仍然保持直立，膝盖不打弯，大概率是奖励的姿态项没有起到引导作用。反过来，如果低目标速度下也出现明显腾空，说明接触奖励或速度奖励的权重失衡。跑步和走路的本质差异在腾空相，纯粹的视觉抖动并不代表跑步。

5. 常见训练问题与从仿真到真实机器人的排查清单

5.1 训练不稳定、动作抖动、原地蹦跳这些常见坑怎么修

实际训练里，问题往往不是“模型学不会”，而是“学出来的东西看着不像跑步”。常见的几类问题可以按下面的顺序排查：

| 问题现象 | 可能原因 | 检查方式 | 处理建议 | |