第二届世界人形机器人运动会 400 米小型组决赛天工 Omni 以 45.66 秒完赛夺冠。换算一下平均速度大约是 8.76 米/秒接近 31.5 公里/小时。对一台双足人形机器人来说这个速度的意义不亚于一个软件项目从“能跑”变成“能稳定扛住生产流量”。小型组本身意味着机器人的腿长、步幅和关节功率密度都受限能在这个尺寸级别跑出 45.66 秒说明控制链路、执行器响应、能量管理和落地的稳定性已经相当成熟。这篇文章不打算只停留在“夺冠恭喜”的层面而是把“人形机器人跑 400 米”这件事拆成工程问题。我们会聊双足高速奔跑为什么难一套能比赛的机器人系统至少包含哪些模块运动控制策略怎么从仿真训练跑到实机批量训练和实验记录怎么组织以及最容易踩的坑和对应的排查思路。无论你是在做人形机器人、四足机器人还是强化学习运动控制这篇都可以直接收藏。1. 核心信息速览信息项内容赛事第二届世界人形机器人运动会项目400 米小型组决赛参赛机器人天工 Omni最终成绩45.66 秒平均速度约 8.76 m/s折合约 31.5 km/h比赛核心考核点双足高速奔跑稳定性、长期连续运动、场地适应、实时控制可靠性涉及技术栈结构设计、高功率密度关节、状态估计、运动控制、强化学习、仿真到实机迁移可复现的工作仿真环境搭建、跑步策略训练、批量实验管理、实机部署验证适合读者机器人算法工程师、嵌入式工程师、仿真与控制方向学生需要强调一点本文不会编造天工 Omni 的身高、重量、关节电机型号、控制器具体算法。这些细节以官方技术发布为准。我们只基于“45.66 秒完成 400 米小型组决赛”这个结果做工程层面的拆解和复现思路梳理。2. 为什么 45.66 秒值得关注双足奔跑和轮式移动或者四足奔跑有一个本质区别双足在地面上是近似不稳定系统。每一步落地身体质心都在快速前移如果下一次落脚的落点、关节扭矩输出时机稍有偏差机器人就会失去平衡。跑步时还会出现双支撑时间接近为零的阶段机器人大部分时间其实是在“飞行”和“单腿落地冲击”之间切换控制周期必须足够短决策必须足够快。从 45.66 秒这个成绩反推天工 Omni 的平均速度做到了 8.76 m/s。但在实际比赛中机器人不会从起点到终点一直匀速往往需要起跑加速、途中稳定、过弯调整、终点前保持节奏。也就是说瞬时速度峰值可能比平均值更高而速度越高步态频率越快关节电机换向越频繁机身振动越大足端触地冲击越猛。能在这个状态下维持几十秒不摔倒说明运动控制策略已经不只是“会走”而是“会跑”。400 米小型组比赛还有一个特点赛道距离长对能量管理的要求比 10 米短跑高得多。机器人的电池容量和功率密度有限如果关节电机长时间处于大功率输出状态温升会很快。电机过热之后输出扭矩会下降控制效果会变差最后可能表现为步态变形、速度衰减甚至摔倒。所以 45.66 秒不是单点爆发能力的证明而是“速度、散热、电源、控制稳定性”多目标平衡的结果。从工程角度看这类赛事成绩背后有很强的验证价值仿真训练出来的策略能不能适应真实场地高速步态下的状态估计是否仍然准确关节执行器能否扛住连续大负载控制系统在电磁干扰和通信延迟下是否稳定。这些点恰恰是很多实验室团队真正想知道的东西。3. 机器人系统模块拆解一台能跑 400 米的人形机器人不是只有“两条腿加一个控制算法”那么简单。从系统实现角度看通常需要以下几个模块协同工作。3.1 本体结构与关节执行器双足高速奔跑对机械结构提出了很高的要求。机器人腿部质量越小转动惯量越小高速摆动时需要的关节扭矩就越低控制带宽也更好。跑步时足端落地瞬间会产生很大的冲击力如果结构刚度不够机身会产生明显的弹性形变IMU 和关节编码器读到的状态就会包含额外噪声直接影响控制效果。关节执行器是核心。跑步需要电机在极短时间内完成正反转、大扭矩输出和高速摆动这对电机功率密度、减速器传动效率、驱动器响应速度都有要求。很多足式机器人方案采用“电机加行星减速器”或“电机加谐波减速器”的组合再配合关节力矩传感器形成闭环。具体用哪种方案要看机器人的体积、重量和成本约束。小型组机器人因为整体尺寸小留给关节的空间更少执行器的小型化与功率密度往往比大型机器人更难。3.2 感知与状态估计跑步控制不能只靠“开环扔一条腿”。控制器需要实时知道机身姿态、角速度、位置、线速度、足端是否触地、每条腿的关节角度和角速度。IMU 提供姿态和角速度关节编码器提供关节位置足底压力传感器或关节力矩传感器提供触地信息这些数据经过滤波和融合形成完整的机器人状态估计。高速运动时IMU 会受到较大的振动干扰特别是每一脚落地瞬间的冲击。如果状态估计的延迟过大控制器拿到的就是“过期状态”高速跑步时很容易失稳。这也是为什么很多团队会在仿真里加入传感器噪声和延迟并在真实机器人上反复调整滤波参数。视觉或激光雷达在跑步比赛中不一定负责每一步的稳定但可以用于赛道识别、车道保持和终点判断。尤其是场地上有线标、弯道、其他机器人等元素时光靠里程计定位会累积漂移需要视觉信息做全局或局部修正。3.3 步态生成与运动控制步态生成的任务是回答“每个时刻两条腿应该摆到哪里”。传统方法依赖模型预测控制或全身动力学控制在线求解最优腿部足端轨迹和关节力矩近年来更多团队转向基于强化学习的策略把“观察量映射到关节目标”这个映射关系直接用一个神经网络策略表示。对于跑步这类高动态运动强化学习策略的优势在于仿真环境里可以同时并行跑成千上万条随机地形、随机参数的机器人让策略学会在各种干扰下保持稳定。策略网络输出的可以是关节位置增量也可以是关节力矩实机部署时需要把网络推理结果平滑地送到关节控制器。运动控制还包含另一个层面机身姿态和质心高度的稳定。跑步时不应该出现躯干过度前倾、后仰或左右摇摆。很多策略会把机身高度、俯仰角、横滚角作为约束条件写进奖励函数让机器人学到的步态既快又不失姿态稳定。3.4 路径规划与赛事决策400 米比赛路线不是一条严格直线通常包含弯道和直线段落。机器人需要知道自己在哪里、目标方向在哪、当前该加速还是减速。这个模块在赛事场景里不复杂但也很关键。如果机器人在弯道仍按直线步态高速跑很容易因为离心力失衡。赛事决策还包括起跑时机、终点刹车策略。机器人不能一直全速冲到终点后急停那样会导致冲锋后摔倒。通常需要根据剩余距离提前切换减速步态让机器人过线后仍然保持稳定站姿。3.5 赛事系统与安全保护比赛现场一般会有无线遥控急停、安全绳或保护装置。机器人跑步测试容易发生意外保护系统必须可靠。通信链路要低延迟不能出现遥控指令延迟导致的危险情况。赛场也会有限制区域和裁判系统机器人启动前要经过安全检查。4. 运动控制栈从仿真训练到实机部署如果把“天工 Omni 夺冠”看成一次系统级验证那前面真正公开的部分是“训练和部署流程”。下面给出一套常见的人形机器人跑步策略训练和部署链路。这里不绑定任何具体真实项目只说明工程上通常怎么做。第一步搭建仿真环境。常见选择包括 Isaac Gym、Isaac Sim、MuJoCo、PyBullet 等。机器人模型需要描述连杆质量、转动惯量、关节限位、电机最大扭矩、摩擦系数等参数。仿真环境越贴近真实机器人后面迁移到实机的概率越高。第二步定义观测空间、动作空间和奖励函数。跑步策略的观测量通常包括机身姿态、机身角速度、机身线速度、关节位置、关节角速度、足底接触状态、目标速度指令。动作量可以是目标关节位置增量也可以是关节力矩。为了稳定训练动作通常需要做平滑处理避免相邻控制步之间动作跳变过大。第三步设计奖励函数。奖励函数是运动控制策略的灵魂。跑步场景里常用的奖励包括速度跟踪奖励、姿态稳定奖励、能量效率惩罚、关节加速度惩罚、触地冲击惩罚等。# 简化奖励函数示意实际策略训练需要根据仿真环境和机器人模型调整 import math def compute_reward(obs, action, target_velocity): base_linear_velocity obs[base_linear_velocity] base_height obs[base_height] contact_forces obs[contact_forces] # 速度跟踪奖励速度越接近目标奖励越高 velocity_error abs(base_linear_velocity[0] - target_velocity) r_velocity math.exp(-2.0 * velocity_error) # 机身高度奖励防止机器人下蹲或跳跃 desired_height 0.55 height_error abs(base_height - desired_height) r_height math.exp(-10.0 * height_error) # 触地冲击惩罚 r_penalty 0.0 force_limit 200.0 if max(contact_forces) force_limit: r_penalty - 0.5 # 摔倒终止 if base_height 0.3: return -10.0, True reward 2.0 * r_velocity 1.0 * r_height r_penalty return reward, False第四步领域随机化和 sim-to-real。仿真和真实世界永远存在差距摩擦系数、关节延迟、质量分布、传感器噪声、电机响应带宽。常见做法是在训练时随机化这些参数让策略在“宽范围环境”里找到鲁棒解。比如把地面摩擦系数从 0.4 到 1.2 随机采样把关节控制延迟从 0 到 10 毫秒随机采样把机身质量在 ±20% 范围内随机变化。策略如果在这些扰动下都能跑出较高平均速度实机部署成功的概率就更高。第五步导出策略并部署到实机。仿真训练得到的神经网络权重通常需要导出为推理格式。实机控制循环里实时订阅机器人状态送入策略网络推理输出关节目标位置或力矩再通过底层关节控制器执行。推理延迟越稳定越好避免出现偶尔几十毫秒的卡顿。从训练到实机经验法则是“仿真里能稳定跑出 40 秒以上 400 米再考虑上真机”如果仿真里都只能跑 15 秒就摔直接上实机基本是炸机。更稳妥的方式是先让策略在一个较低的目标速度下跑通完整赛道再逐步提高目标速度。这个流程不是天工 Omni 官方流程但它是目前足式机器人领域比较通用的工程节奏。5. 环境准备与工程依赖如果你想在本地复现一个“人形机器人跑步策略训练”的最小实验需要准备环境变量和依赖。以下内容是基于通用强化学习运动控制项目的经验清单具体版本以你选择的仿真框架官方文档为准。5.1 软件环境软件项建议操作系统Ubuntu 20.04 或更高版本实机部署常用 LinuxGPU 驱动NVIDIA 驱动CUDA 可用仿真框架Isaac Gym / Isaac Sim / MuJoCo / PyBullet按项目选择深度学习框架PyTorch版本与仿真框架和 GPU 驱动匹配Python 环境conda 或 venv推荐独立环境实验记录TensorBoard、WandB 等# 创建独立 Python 环境 conda create -n humanoid_running python3.10 -y conda activate humanoid_running # 安装深度学习框架具体版本按 GPU 驱动和仿真框架要求调整 pip install torch torchvision # 仿真框架安装方式差异很大必须按官方文档确认版本和授权 # pip install isaacgym # pip install mujoco # 实验记录工具 pip install tensorboard wandb5.2 训练命令模板# 通用训练启动示例实际任务名、参数名需要按项目代码调整 python train_running_policy.py \ --task HumanoidRunning \ --headless \ --max_iterations 2000 \ --num_envs 4096这里num_envs是并行环境数。并行环境越多训练数据收集越快但对 GPU 显存和 CPU 核心数的要求也越高。第一次实验建议先用 512 或 1024 个环境跑通流程再逐步提高。5.3 实机部署环境实机部署比仿真训练更复杂。机载计算单元负责运行策略推理需要确定控制周期和任务优先级。关节驱动通常通过 CAN、EtherCAT 等现场总线连接底层关节伺服频率更高例如 1kHz而策略推理频率可能设置在 50Hz 到 200Hz 之间。实际频率取决于机器人和控制器的设计。还要准备急停按钮、安全绳、保护垫和测试场地尽量远离人员。6. 功能测试与效果验证在复现人形机器人跑步策略时不能只盯着“最终成绩能不能跑进 46 秒”而是要分层验证。每一层有各自的功能测试项目和判断标准。6.1 仿真环境测试测试项操作通过标准基础站立策略初始化后保持站立无摔落持续站立 30 秒以上速度跟踪给定目标速度 1 m/s观察实际速度实际速度误差低于 0.3 m/s高速跑步给定目标速度 8 m/s观察是否保持稳定能在该速度下持续跑 30 秒以上扰动恢复在机器人质心施加随机推力推力结束后能恢复稳定参数随机化随机摩擦、质量、延迟策略在不同参数下均不失败仿真测试里最容易出现的问题是高速度跟踪成功、但低速站立失败。这是因为训练时奖励函数可能过度偏向“跑得快”忽略了低速稳定性。遇到这种情况可以在奖励里加入目标速度范围让策略同时学会低速平衡和高速奔跑。6.2 实机验证实机验证要遵循“从低速到高速从简单到复杂”的原则。第一步带保护装置原地踏步。让机器人先执行低幅度的原地踏步动作观察关节响应是否正常IMU 读数是否稳定。这个阶段主要验证通信链路和底层驱动。第二步低速行走。速度设定在 0.5 m/s 到 1 m/s在平整地面上走一个 10 米往返。观察步态是否自然是否出现反复修正。如果发现关节位置抖动大可以先降低策略输出频率或者对动作做低通滤波。第三步中速跑步。逐步提高目标速度到 3 m/s 到 5 m/s。这个阶段最容易暴露电机响应不足、结构共振、状态估计延迟等问题。如果速度一高就摔优先检查控制频率和关节延迟而不是盲目加大奖励系数。第四步高速跑步。当 5 m/s 稳定后再尝试接近比赛速度。高速段要特别关注电机温度、电池压降和摩擦力变化。6.3 数据指标除了“有没有摔倒”这个结果指标还需要记录过程指标。包括目标速度与实际速度的跟踪误差、步频、步幅、机身俯仰角波动范围、足端触地时间、关节温度、电池电压、单圈能耗。如果训练策略之后想继续提升速度这些指标能告诉你瓶颈在哪步频上不去可能是电机转速限制步幅不够大可能是结构限位或扭矩不足。7. 批量训练、实验管理与状态服务跑步策略训练不是一次就能成功的。不同的随机种子、地形参数、奖励权重会产生完全不同的策略效果。实际工程里需要批量跑很多组实验然后统一比较结果。import subprocess import itertools seeds [0, 1, 2] terrains [flat, rough, slope] learning_rates [5e-5, 1e-4] for seed, terrain, lr in itertools.product(seeds, terrains, learning_rates): log_dir f./runs/seed{seed}_{terrain}_lr{lr} cmd [ python, train_running_policy.py, --seed, str(seed), --terrain, terrain, --learning_rate, str(lr), --log_dir, log_dir, ] print(running:, .join(cmd)) subprocess.run(cmd, checkFalse)批量训练时要在每个实验目录里保存完整配置、随机种子、训练日志、模型权重、评估结果。这样后续回看实验结果时可以精确知道“这个策略是在什么环境下用哪组超参训练出来的”。模型文件命名建议带上速度目标、地形、日期等信息例如policy_8ms_rough_20250601.pt避免时间一长完全对不上。实验记录可以使用 TensorBoard 或 WandB。训练过程里损失、奖励、平均速度、步态周期等指标全部记录方便判断训练是否发散。如果奖励一直上升但实机效果不好很可能是奖励函数里有“作弊”行为比如通过高频率抖动保持平衡而不是真实跑步。在实机系统里机器人控制程序通常需要对外暴露状态接口。这里给一个通用 WebSocket 状态订阅示例注意这不是赛事官方接口只是工程实践中常用的方式。import asyncio import json import websockets # 通用机器人状态服务示例用于对外输出当前状态 async def robot_state_handler(websocket): async for message in websocket: # message 可以是查询指令也可以下发速度目标 req json.loads(message) if req.get(action) get_state: state { mode: running, target_speed: req.get(target_speed, 8.0), current_speed: 7.8, step_frequency: 3.5, ts: 1234.56, } await websocket.send(json.dumps(state)) async def main(): async with websockets.serve(robot_state_handler, 127.0.0.1, 8765): await asyncio.Future() if __name__ __main__: asyncio.run(main())真实系统里状态服务一般跑在机载电脑或上位机上内容包含机身姿态、关节反馈、控制模式、故障码等。接口设计要考虑传输延迟和脏数据过滤不能把高频控制总线上的原始数据全部往网络里丢。8. 资源占用与性能观察训练跑步策略对资源的要求主要在 GPU 和 CPU。Isaac Gym 这类 GPU 并行物理仿真框架会把大量环境并行放在 GPU 上模拟环境越多显存占用越高。如果你在训练时遇到显存不足可以按这个顺序排查先降低num_envs再降低物理仿真线程数最后考虑扩大显存或使用混合精度。实际显存占用与机器人模型复杂度、物理引擎版本、可视化开关都有关系需要以本机测试为准。观察资源占用比较简单# 查看 GPU 实时使用率和显存 nvidia-smi -l 1 # 查看 CPU 和内存占用 htop训练时注意 GPU 利用率是否被打满。如果 GPU 利用率只有 20%但 CPU 已经满载说明 CPU 成了瓶颈可能是物理引擎的碰撞检测在 CPU 上执行或者数据采集处理速度跟不上。如果 GPU 利用率接近 100% 且显存占用也在高位说明仿真环境数量已经接近上限不要再盲目增加。实机运行时的资源占用和仿真训练完全不同。机载计算单元更关心控制循环的最大延迟而不是平均延迟。可以用taskset绑定控制线程到固定 CPU 核心降低调度抖动。同时监控电机驱动器电流、MOS 管温度、电池电压任何一个指标异常都可能导致跑步中途动力衰减。9. 常见问题与排查方法问题现象可能原因排查方式解决方案仿真里能跑实机上摔sim-to-real 差距较大对比仿真和实机传感器读数、动作响应差异增加领域随机化范围降低实机目标速度训练奖励上升但速度不提高奖励函数没有充分鼓励速度或步态陷入局部解查看速度曲线和步态频率曲线加大速度跟踪奖励权重调整动作平滑参数跑步时机身前后倾斜明显状态估计滞后或质心建模不准查看 IMU 俯仰角数据和策略输入是否一致优化滤波参数校正质心位置关节电机过热长时间高速跑步导致功率超限监控关节温度曲线限制持续最大扭矩加入温度保护逻辑实机定位漂移里程计累积误差对比启动点和终点位置引入视觉/激光定位增加起终点标记控制循环出现偶发卡顿CPU 调度抖动或进程占用查看控制线程最大延迟日志使用实时优先级绑定 CPU 核心批量训练时显存不够并行环境数过多查看 nvidia-smi 显存占用降低 num_envs 或使用混合精度训练策略反复摔倒后直接退出奖励函数在摔倒分支设置过强训练频繁终止查看终止条件统计提高摔倒惩罚的同时增加周数避免训练早期全部终止最容易被忽略的是“传感器延迟”。仿真里传感器数据是零延迟的实机从 IMU 采样到推理结果送到关节伺服中间往往有几毫秒甚至十几毫秒的时间差。高速跑步时这一小段延迟足以让策略每一步都慢半拍。排查时可以在日志里加上时间戳记录“传感器时间戳、推理输入时刻、输出时刻、关节指令时刻”逐段查看延迟来源。10. 使用边界与合规提醒人形机器人高速奔跑属于高风险测试。一台几公斤甚至几十公斤的机器人如果以 8 m/s 以上的速度失控冲向人群冲击力非常危险。实机测试必须在封闭场地进行周围安装防护网或围栏所有靠近调试的人员佩戴防护装备。如果机器人搭载摄像头要注意采集范围不能超出测试场景避免记录无关人员的面部和隐私信息。后续如果要把跑步策略、代码或数据开源还要检查训练数据来源是否合法、是否涉及第三方版权软件。仿真框架和 SDK 的授权条款也要提前确认不能直接认为所有工具都可以随意商用。参赛和复现过程中要尊重赛事规则。如果借鉴了其他团队的机器人结构或控制方案需要明确来源和许可协议。机器人技术发展很快一些团队会开放部分代码或硬件设计但“开源”不意味着可以无限制使用尤其涉及商业目标时必须逐条核对许可证。11. 最佳实践与后续方向做一个人形机器人跑步系统最忌讳一开始就追求最高速度。建议建立一套最小闭环在仿真里跑通一个 2 m/s 的跑步策略部署到实机确认关节响应和状态估计没有大问题再逐步提高速度目标。这个过程中把每一步的配置、代码、日志和失败案例都记录下来避免重复踩同样的坑。版本管理要覆盖到模型权重。单纯保存代码还不够训练时的随机种子、仿真参数、奖励权重、领域随机化范围都必须一并记录。否则复现结果时你怎么都想不起来当时那个“跑得很稳的策略”是怎么训出来的。实机测试一定要有“保姆模式”。第一次上速度时用机器人保护绳或吊架拉住机身即使策略完全失效也不会摔坏本体。等策略稳定后再逐步降低保护程度。高速跑步对机械结构的冲击很大保护设备准备的再多都不为过。回到天工 Omni 的 45.66 秒。它真正的价值不是一块奖牌而是验证了从仿真训练到实机部署、从单步稳定到长时间高速奔跑的整个链路可以压缩到非常紧凑。接下来更值得关注的方向是小型机器人的关节功率密度能不能再提升跑步策略能不能在更复杂场地比如草地、沙地、斜坡上保持速度以及多机同场竞技时机器人之间的相对感知和避让会不会成为新的技术分水岭。如果你手里有一套人形机器人仿真环境建议先复现一个跑步策略把每一步跑稳再谈成绩。