在机器人运动控制里让一个足式机器人“保持跑步姿态”和让它在平地上保持站立完全是两个难度等级。站立控制只需把重心维持在支撑面内而跑步要求机器人周期性离开地面、在前向速度较高的条件下调整躯干姿态并在落地瞬间消化冲击。传统控制方法依赖精确的动力学模型和接触时序规划一旦速度变快、地面情况变化鲁棒性就明显下降。强化学习把这个问题重新定义为“在奖励函数引导下试错学习”机器人不再需要人为写出每一步的落脚点而是通过与仿真环境大量交互学会一种稳定的跑步姿态。下面围绕“强化学习让机器人保持跑步姿态而非人形”这条主线展开先说明跑步控制难在哪再给出一个可复现的仿真训练思路最后整理训练验证和真实迁移时的排查路径。1. 先理解“跑步姿态”为什么不能靠固定输出给定1.1 跑步姿态的核心特征支撑相与腾空相交替跑步姿态不是简单地把机器人当成“直立人偶”推着往前走。无论是双足人形机器还是四足机器人跑步本质上是支撑相stance和腾空相flight以一定节奏交替。支撑相中腿部负责蹬地腾空相中机器人整体离开地面需要靠髋、膝、踝的姿态调整准备下一次落地。落地时地面反作用力会带来明显冲击腿部关节需要弯曲缓冲。这意味着跑步姿态的判断不能只看“有没有向前移动”还要看是否存在腾空相、躯干是否前倾、下肢是否弯曲。很多强化学习训练的机器人会学到“原地蹦跳”或者“快速甩腿”这类假动作因为它在奖励数值上满足了某个指标但并没有形成真正的跑步节奏。这也是反复强调“跑步姿态而非人形”的原因外观是不是人形不重要重要的是运动模态是否符合跑步的动力学特征。1.2 传统控制方法在高速运动中的瓶颈传统足式机器人控制里常出现几个概念零力矩点ZMP、模型预测控制MPC、混合动力规划。ZMP 方法适用于脚底始终与地面接触的慢速行走因为它假设机器人与地面存在连续支撑重心投影保持在支撑多边形内。跑步过程中机器人会腾空ZMP 的连续接触假设直接失效。MPC 通常需要已知的动力学模型和接触时序虽然能在每个控制周期内求解最优关节力矩但对模型误差和外部扰动敏感。为了让机器人在跑步时稳定需要显式规划每一步的接触时间而接触事件本身的离散特性让优化问题变得复杂。这样一来传统方法在实验室里可以调出一次漂亮跑步但一旦换地面、换负载或遇到随机扰动很容易重新变成“只能走、不能跑”。方法对模型依赖对接触处理高速鲁棒性工程投入ZMP 行走控制高假设连续接触低中MPC 步态规划高需要显式接触时序中高强化学习低通过奖励隐式学习中到高高但可扩展1.3 强化学习为什么适合这个场景强化学习的优势不在“无需模型”这个表面说法而在于它把策略表示成参数化网络通过大量试错去拟合一个稳定映射从当前状态到下一步动作。跑步过程中的接触事件不需要显式编码网络可以从奖励信号里自动归纳出“什么时候蹬地、什么时候收腿、什么时候让躯干前倾”。从实现角度看一个策略网络只需要一组参数输入是关节角度、角速度、机身姿态、速度等信息输出是目标关节角度经过 PD 控制器产生力矩。这种结构天然适合连续控制问题也适合在仿真环境里并行采集大量经验。但强化学习不是免调参的。它把“如何调速”问题转移成“如何设计奖励函数”和“如何构建逼真的交互环境”。尤其是奖励函数如果设计不当很容易学到高奖励但低质量的跑步姿态。2. 搭建一个能体现跑步姿态的仿真实验环境2.1 先选一个适合足式运动仿真的平台跑步的关键动作是脱离地面、落地、摆动仿真平台必须具备准确的接触模型、刚体碰撞检测和关节执行器模型。常见的选择有 MuJoCo、Isaac Gym 和 PyBullet。仿真平台适合场景主要特点入门成本MuJoCoCPU/GPU 设备上做小规模实验接触求解稳定仿真速度快与 Gymnasium 集成好较低Isaac Gym大规模并行训练直接在 GPU 上并行上千个环境训练吞吐高较高需要 CUDA 环境PyBullet调试与教学、快速验证API 直观可视化方便低实际项目里没有“最好”的平台只有更符合当前训练阶段的选择。建议先用 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-baselines3stable-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_modeNone, target_speed1.5): super().__init__() self.robot load_robot_model() # 具体模型按实际项目接入 self.observation_space spaces.Box( low-np.inf, highnp.inf, shape(n_state,), dtypenp.float32 ) self.action_space spaces.Box( low-1.0, high1.0, shape(n_action,), dtypenp.float32 ) self.target_speed target_speed def reset(self, seedNone, optionsNone): 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(dt0.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_actionNone, target_speed1.5, dt0.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_modeNone, target_speed1.5) return env vec_env DummyVecEnv([make_env]) vec_env VecNormalize(vec_env, norm_obsTrue, norm_rewardTrue) model PPO( MlpPolicy, vec_env, learning_rate3e-4, n_steps2048, batch_size128, n_epochs10, gamma0.99, clip_range0.2, ent_coef0.005, verbose1, ) model.learn(total_timesteps5_000_000) model.save(ppo_runner)VecNormalize 会把观测和奖励标准化这在状态量量纲差异很大时很有用。训练规模方面本地单环境跑 500 万步可能需要一段时间如果项目允许应使用多个并行环境或者 GPU 仿真加速。PPO 超参里最需要关注的几个如下超参典型起步值作用调大/调小的表现learning_rate3e-4决定策略更新的步长太大不稳定太小收敛慢n_steps2048每次更新前采集的经验数量太小容易偏差太大更新频率低batch_size128每个 mini-batch 的样本数影响更新的方差gamma0.99未来奖励的折扣因子越小越短视越大越关注长期回报ent_coef0.005策略熵的奖励系数太大会一直随机太小会过早收敛到局部解clip_range0.2PPO 裁剪范围太大更新激进太小保守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_modehuman, target_speed1.5) env VecNormalize(env, norm_obsTrue, norm_rewardFalse) model PPO.load(ppo_runner.zip, envenv) obs, _ env.reset() history {lin_vel_x: [], pitch: [], feet_contact: [], episode_len: 0} for _ in range(200): action, _ model.predict(obs, deterministicTrue) 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 定义一组可判读的跑步指标为了不靠肉眼判断可以定义一组计算方便的运动指标指标计算方式跑步姿态的期望范围说明平均前向速度一段时间内 x 方向速度均值接近训练目标速度太低说明没跑起来腾空相占比双脚同时离地的时间 / 总时间跑步中通常大于 0若接近 0更像走路躯干俯仰角躯干与水平面夹角均值轻微前倾绝对值较小如果完全直立或后仰步态可疑步频脚接触标志的周期性峰值在合理步频范围内过高可能是快速摇摆膝关节角度范围关节轨迹的峰谷差存在明显弯曲和伸展锁直说明没有缓冲腾空相占比可以用下面这段代码快速计算contact np.array(history[feet_contact]) both_in_air np.all(contact 0, axis1) flight_ratio both_in_air.mean() print(flight ratio:, flight_ratio)这里的取值范围只用于说明不同机器人的尺寸、质量和关节配置会导致完全不同。关键是方法用连续的物理量而不是单一奖励值判断步态质量。如果平均速度达标但腾空相占比一直为 0说明策略学到的是快速走路不是跑步姿态。4.3 用轨迹对比“跑步姿态”与“人形直立行走”本文标题强调“跑步姿态而非人形”在验证阶段尤其需要注意。一个策略可能在数学上获得了较高奖励但最终动作是在原地不断屈膝、甩腿或者看起来像直立滑冰。这种时候可以把同一策略在目标速度高、低两个设置下分别评估。如果高目标速度下机器人的躯干仍然保持直立膝盖不打弯大概率是奖励的姿态项没有起到引导作用。反过来如果低目标速度下也出现明显腾空说明接触奖励或速度奖励的权重失衡。跑步和走路的本质差异在腾空相纯粹的视觉抖动并不代表跑步。5. 常见训练问题与从仿真到真实机器人的排查清单5.1 训练不稳定、动作抖动、原地蹦跳这些常见坑怎么修实际训练里问题往往不是“模型学不会”而是“学出来的东西看着不像跑步”。常见的几类问题可以按下面的顺序排查| 问题现象 | 可能原因 | 检查方式 | 处理建议 | |