北京人形机器人天工 Ultra 在 400 米比赛中以 39.70 秒的成绩跑完全程拿到第一同时按赛事口径打破了人类在该项目上的最快纪录。这个新闻刚出来的时候很多人把它当成一条猎奇体育新闻转发但对做机器人和自动化的工程师来说这个数字背后藏着一个更重要的问题一台双足人形机器人凭什么能跑得比人还快我先说一个可能让非专业人士意外的点。人形机器人“走路”和“跑步”完全是两套技术方案。走路的时候机器人大部分时间至少有脚接触地面重心控制可以用一套相对成熟的理论模型来解决但跑步的时候每一步都存在腾空期整个机器人处于无支撑的自由飞行状态落地瞬间还要承受数倍于体重的冲击。换句话说比赛里看到的每一次抬腿和落地都是运动规划、驱动器响应、结构刚度和传感器融合同时配合的结果任何一环慢了或者乱了结果都不是“成绩差”而是“当场摔倒”。所以这篇内容我不想做成赛事回顾而是从技术视角拆解三件事人形机器人跑步为什么这么难天工 Ultra 这类平台背后需要哪些软件与硬件基础以及国内人形机器人的芯片和软件架构目前正处在什么阶段。文章里会给出一些通用的控制算法思路、仿真训练方法和工程排查建议这些内容不一定只适用于天工而是所有想做双足高速运动控制的人都会遇到的问题。1. 39.70 秒意味着什么人形机器人跑步的门槛在哪先把这个成绩放回真实语境里。人类男子 400 米的世界纪录是 43.03 秒天工 Ultra 的 39.70 秒确实更快。但如果只比“绝对速度”会发现这个成绩似乎没那么夸张换算下来平均速度大约是 10.08 米/秒这比人类百米冲刺的峰值速度低不少。那为什么这件事在机器人领域会引起关注关键在于“稳定地跑完”这四个字。很早以前本田 ASIMO 就实现过双足奔跑但它跑步时步态比较僵硬速度也有限而且对地面条件要求很高。后来波士顿动力 Atlas 在跑酷、后空翻这些动作上展示了极强的动态运动能力但 Atlas 的整机成本和维护难度也很高。天工 Ultra 的价值不在于某一步技术独步全球而在于它把“高速双足跑步”这件事从实验室表演变成了可以在比赛环境中连续完成的系统能力。这里真正值得注意的技术门槛有三个腾空与落地的稳定性。跑步和走路最大的区别是存在腾空相机器人离开地面后不再有固定支撑姿态完全依赖关节力矩规划来维持。落地瞬间地面反作用力很大如果控制频率不够高或者执行器响应不够快姿态立刻发散。双足跑步的动力学模型比走路复杂。走路可以用 ZMP 这类静态判据来规划跑步则更依赖倒立摆模型、捕获点和 MPC 这类动态稳定方法。模型的简化程度直接决定真机表现。机器人需要在无外部支撑的情况下自己“不倒”。这对关节的扭矩密度、控制器的实时性、以及传感器数据的低延迟都有苛刻要求。所以 39.70 秒不只是跑步成绩它更像一张体检报告说明整套系统的动态运动能力已经达到可比赛、可复现的水平。这也是为什么做机器人的人看到这个新闻会比普通人更激动。2. 人形机器人运动控制的核心概念从 ZMP 到 MPC 与 WBC要把天工 Ultra 的技术逻辑讲清楚得先快速过一遍双足运动控制里最常见的几个基础概念。如果已经熟悉这些内容可以直接跳到第 3 节。2.1 步态周期与跑步相双足运动的最小单位是步态周期。行走时每个周期可以分为单脚支撑相和双脚支撑相跑步时则不同存在一个“腾空相”也就是双脚都离地的阶段。这个差异看起来只是时间分配变了但它让控制策略发生了本质变化走路时机器人可以随时通过调整双脚的位置来“寻找”稳定。跑步时腾空阶段的运动完全由惯性决定只能靠落地前的预调整和落地后的主动缓冲来恢复稳定。所以跑步控制系统的状态估计必须更准确尤其是躯干姿态角速度、质心位置和落地点的预测值。2.2 ZMP 与零力矩点ZMPZero Moment Point零力矩点是走路控制的经典概念。它表示地面反作用力的合力作用点只要 ZMP 落在支撑多边形内部机器人就不会翻倒。走路时ZMP 可以比较可靠地作为稳定性判据但跑步时由于存在腾空相地面反作用力无法一直存在ZMP 理论就不足以覆盖整个运动过程。这是新手理解跑步控制时最容易犯的误区——以为跑步只是“走路更快”。2.3 倒立摆模型与捕获点为了处理动态稳定工程师通常会把机器人简化成一个倒立摆质心由一条虚拟的腿支撑。跑步时机器人可以看作是“从一个支撑点跳到另一个支撑点”需要利用线性倒立摆模型预测质心轨迹。捕获点Capture Point在这个模型里非常关键它是机器人能通过迈出一步实现静止平衡的地面位置。跑步的本质可以理解成不断在地面上“追赶捕获点”让每一步都处在动态稳定边界内。2.4 MPC 与 WBC 的配合仅靠倒立摆模型不够因为真实机器人有很多条腿、有躯干、有手臂关节之间存在动力学耦合。所以当前主流方案是两层控制架构上层用模型预测控制MPC规划质心和落脚点轨迹频率通常在 30 到 100 赫兹。下层用全身控制WBC把质心轨迹分配到各个关节力矩频率通常在 500 到 1000 赫兹。MPC 负责“怎么走”WBC 负责“怎么用力”。跑步时两个控制器必须紧密配合任何一个的时序延迟超过几毫秒都可能造成落地姿态偏差。下面用一张对比表把这几个概念放在一起看概念解决什么问题适用场景典型使用方式ZMP判断是否翻倒静态/低速行走作为约束条件倒立摆模型预测质心运动动态步行、跑步生成落脚点捕获点确定稳定落脚位置抗扰动、跑步落地作为 MPC 目标MPC滚动优化质心与步态轨迹动态运动规划上层优化器WBC把轨迹映射为关节力矩整身协调控制下层执行器3. 从“能走”到“能跑”天工 Ultra 的平台化迭代思路天工系列机器人来自北京人形机器人创新中心。从公开信息看天工系列主打通用人形机器人母平台而天工 Ultra 是针对高速奔跑和专项运动优化过的型号。从“通用平台”这个角度切入才能真正理解为什么一个比赛成绩值得关注。人形机器人行业高度依赖平台复用。如果每个项目都从零开始设计机器人本体、运动控制算法和仿真环境研发成本会一直停留在几十人团队做原型机的阶段很难走向产品化。天工这类母平台的价值在于底层硬件接口、通信协议、控制系统框架和仿真工具链可以复用后续不同的应用场景只需要在“上层”更换感知模块、切换任务策略或者调整步态参数。天工 Ultra 能跑出这个成绩说明它的基础平台至少解决了几个工程问题执行器有足够的峰值扭矩和响应带宽。高速跑步时关节角速度很高驱动系统如果出现力矩饱和控制器无论怎么优化都补偿不回来。结构件的刚度与重量平衡。人形跑步会带来较大的冲击载荷结构过软会让控制模型与实际动力学偏差变大结构过重又会增加惯性导致响应速度下降。实时通信链路足够稳定。运动控制频率往往在千赫兹级别关节状态反馈、力矩指令和传感器数据必须都在同一个低延迟网络中闭环。如果只把天工 Ultra 当作一台“会跑步的机器人”很容易忽略它背后的平台化意义。真正的看点不只是这一场比赛而是这套平台能支撑多少种不同的运动能力扩展。4. 400 米跑步任务拆解为什么不是“跑得快”就够400 米不是简单的直道冲刺它比很多人想象的更复杂。把它拆开看至少包含四个阶段每个阶段对控制系统的要求都不一样。4.1 起跑加速从静止到高速奔跑是扰动最大的阶段。地面反作用力要突然变大机器人质心要从前倾状态快速转化为前进方向上的加速度。如果加速策略过于激进很可能起跑两步就摔倒如果太保守战术上又已经落后。这一阶段考验的是状态估计的快速准确性和驱动器的力矩输出能力。4.2 弯道弯道和直道最大的区别在于离心力。机器人需要向内倾斜身体来获得向心力同时步频和步幅也要微调。倾斜角度、支撑脚着地位置和上身姿态必须协同变化控制策略比直道复杂不少。弯道阶段最容易出现的问题是转向偏差和身体侧倾过大一旦侧倾超过捕获点的补偿范围机器人就会向外侧摔倒。4.3 直道维持进入稳定段后看起来是在匀速跑实际上控制任务仍在不断滚动更新。地面材质、微小坡度和自身结构振动都会让状态偏离预测值MPC 需要实时调整落脚点。这里还会遇到一个隐藏问题电机持续高功率输出时会出现温升如果温升超过阈值驱动器会自动降额结果就是后半段“跑不动”。所以长距离高速跑步的功率管理同样属于控制问题。4.4 终点冲刺与减速冲刺阶段可以短暂提高步频但终点之后必须规划一条减速路径否则机器人会由于惯性冲出赛道甚至撞到周边设施。看似简单的比赛实际包含了完整的“加速—匀速—减速”闭环。从比赛角度说39.70 秒说明天工 Ultra 在这些阶段都保持了可接受的稳定性这比单点速度指标更有价值。5. 运动控制软件栈与最小示例理解了任务难度之后接下来看软件侧的实现思路。双足机器人的运动控制软件通常分为感知层、状态估计层、运动规划层和关节执行层。以跑步场景为例一个简化的工作流程是通过 IMU、关节编码器和足底力传感器估计当前躯干姿态与质心状态。把预计跑道信息直道、弯道输入给运动规划模块。规划模块以 MPC 为核心按周期的生成质心轨迹和落脚点序列。全身控制模块把目标轨迹转换成关节力矩指令发送给关节执行器。执行器在本地闭环控制电流和速度并把实际状态返回估计层。下面给出一个非常简化的运动控制主循环代码用来说明控制频率问题的处理方式。这里的控制周期是 2 毫秒也就是 500 赫兹这也是很多双足机器人系统常用的控制频率区间。# 文件路径control_loop.py import time TASK_PERIOD 0.002 # 2ms对应 500Hz 控制频率 class SpotRunner: def __init__(self): self.mpc_solution None self.mpc_period_count 0 self.MPC_INTERVAL 20 # 每 20 个控制周期运行一次 MPC def update_state_estimate(self): # 从 IMU、编码器、力传感器融合得到当前状态 pass def run_mpc(self): # 基于当前状态和赛道信息滚动优化未来质心轨迹和落脚点 self.mpc_solution self.solve_mpc() def solve_mpc(self): # 实际项目中会调用 OSQP 等优化求解器 return {com_trajectory: [], footstep_sequence: []} def compute_wbc(self): # 将 MPC 生成的质心轨迹和落脚点映射到全身关节力矩 pass def send_commands(self): # 通过 EtherCAT/CAN 等总线发送关节力矩指令 pass def step(self): t_start time.perf_counter() self.update_state_estimate() if self.mpc_period_count % self.MPC_INTERVAL 0: self.run_mpc() self.compute_wbc() self.send_commands() self.mpc_period_count 1 elapsed time.perf_counter() - t_start time.sleep(max(0.0, TASK_PERIOD - elapsed))这段代码的重点不在于能否直接运行而在于体现一个关键点MPC 不需要每个控制周期都跑但 WBC 和状态估计必须跑在更高频率。真正工程化的代码还要处理总线超时、传感器丢帧、控制器异常跌落等情况。5.1 MPC 配置示例MPC 的性能很依赖配置参数。下面是一个简化版 YAML 配置展示了常见参数的组织方式。注意这里的数值只适合演示实际工程需要根据机器人动力学模型做整定。# 文件路径mpc_config.yaml mpc: horizon_steps: 20 # MPC 规划窗口步数 dt: 0.02 # 单步时间间隔50Hz MPC weight: { com_position: 10.0, com_velocity: 1.0, footstep_position: 2.0, torso_orientation: 5.0 } gait: type: run step_duration: 0.28 # 单个步态周期时长 air_time: 0.12 # 腾空时间 support_time: 0.16 # 触地支撑时间 swing_foot: clearance_height: 0.05 # 摆腿离地高度注意为什么是“50Hz MPC”规划窗口 20 步每一步 0.02 秒总规划时长是 0.4 秒这大约能覆盖未来 1 到 2 个步态周期。频率太高会增加计算负担太低则无法应对扰动。实际项目中这个频率往往根据优化问题规模和 CPU 资源权衡调整。5.2 仿真训练命令示例现阶段的机器人高速跑步已经很少纯粹靠人工设计运动轨迹更多是用强化学习在仿真中训练策略再迁移到真机。以目前常用的 Isaac Gym 或者 MuJoCo 为例训练命令通常长这样# 使用 Isaac Gym 训练双足跑步策略示例 python train.py \ --taskBipedalRun \ --headless \ --max_iterations5000 \ --num_envs4096 \ --save_interval200 # 训练完成后导出模型 python export_policy.py \ --taskBipedalRun \ --checkpointoutputs/BipedalRun/checkpoints/model_5000.pt \ --outputrun_policy.pt训练命令不是重点重点是仿真训练背后需要解决的三类问题奖励函数设计。通常要对“前进速度”给奖励同时惩罚过大姿态角速度、异常关节力矩和不合理的躯干摆动。域随机化。仿真参数和真机参数永远有差距常见做法是对质量、摩擦系数、关节延迟、电机力矩系数做随机扰动让策略学会适应不确定性。训练到真机的落差处理。如果仿真里跑得很好、真机却总摔倒大概率是仿真模型不准确或者控制频率、执行器延迟差异太大。6. 人形机器人的芯片算力与软件架构不止是“腿”天工 Ultra 能跑起来背后还有一条容易被大众忽视的产业链芯片和软件架构。热搜词里提到的“人形机器人芯片”和“人形机器人软件架构”正是当前行业的两个关键变量。6.1 芯片人形机器人的三级算力结构一款双足人形机器人通常包含三种层次的芯片端侧计算单元。负责感知融合、运动规划、状态估计往往是一颗高算力的 SoC 或嵌入式 GPU 模组能运行轻量级神经网络模型。关节控制单元。每个关节或者腿部的控制器通常是 MCU 或 FPGA负责电流环、速度环和位置环的实时闭环。云端训练平台。用于训练强化学习策略和仿真模型通常是 GPU 服务器集群。这里要特别说明很多人以为“机器人芯片”是某一家公司的单一处理器但实际是“异构算力”的协同方案。比如国产 SoC 厂商全志科技也在布局机器人芯片方向这类芯片更侧重端侧智能和低功耗实时控制和云端训练用的 GPU 不是同一个任务。它们的出现说明人形机器人已经开始形成独立的硬件生态而不再是“手机芯片改一改”。6.2 软件架构分层设计是落地的关键人形机器人软件架构可以大致分为四层层级职责常见技术载体应用层比赛任务、导航、决策Python/C 任务脚本运动管理层步态切换、行为调度状态机、行为树实时控制层MPC、WBC、状态估计C 实时进程驱动与通信层关节总线、传感器采集EtherCAT、CAN、ROS 2 驱动以 ROS 2 为例不同模块之间可以通过 Topic 和 Service 通信。比如实时控制层发布关节命令应用层订阅机器人的状态但要注意真正的关节通信协议通常走 EtherCAT 等实时总线ROS 2 更多承担感知、调度和调试的角色。下面是一个简化的示例演示实时控制节点发布状态信息# 查看机器人实时状态话题示例 ros2 topic echo /robot/status # 预期输出 # timestamp: 1693200000 # torso_pitch: 0.02 # torso_roll: -0.01 # gait_state: running # current_speed: 10.1这种分层架构的优势是便于团队协作一个团队优化算法另一个团队调驱动器参数还有一个团队处理感知和任务逻辑。如果所有逻辑都写在同一个进程里后期调试成本会迅速失控。7. 仿真训练与 Sim2Real 迁移的工程实践高速跑步策略的研发目前公认效率最高的路线是“仿真训练 真机微调”。但这里有一个普遍存在的坑仿真成绩很好真机成绩很差。解决这个问题需要一套系统化的迁移工程流程。7.1 仿真环境建模第一步是构建动力学一致的仿真模型包括机器人本体的质量分布、关节力矩限制、通信延时和摩擦力。这里最容易忽略的就是“延时”。如果仿真里控制的信号没有任何延迟真实机器人一定做不到同样性能。7.2 域随机化域随机化是缩小仿真与真实差距的有效手段。可以在每次训练开始时随机化以下参数地面摩擦系数从 0.4 到 1.2 随机采样关节电机力矩常数乘以一个 0.9 到 1.1 的随机系数传感器噪声在姿态读数上叠加高斯噪声控制指令延迟随机增加 1 到 5 毫秒这样训练出来的策略不会过度依赖某些“理想参数”更有可能在真机上保持鲁棒。7.3 真机验证路径从仿真到真机最稳妥的做法是分成多步先在仿真中完成整段跑步路线连续通过 100 次统计成功率。真机低速小步幅测试确认状态估计和关节响应是否符合预期。逐步提高速度每次只修改一个参数比如步幅或者步频。进行抗扰动测试比如在侧面轻推、走过轻微斜坡观察策略能否自恢复。每一步如果失败都要回退到仿真环境去复现问题而不是硬调真机参数。这是人形机器人工程里最容易被忽视的时间黑洞。8. 常见问题与排查思路下面整理几个双足高速跑步控制中常见的问题以及大致的排查方向。每个机器人的具体表现不同但排查思路是通用的。问题现象可能原因排查方式解决方案机器人高频抖动控制频率不足或关节响应延迟过大查看关节速度/电流波形分析控制周期实际耗时提高控制频率增大阻尼降低 MPC 规划频率仿真能跑真机总摔动力学模型不准、延时未建模对比仿真与实际关节力矩轨迹增加域随机化校准质量/摩擦系数直道跑偏IMU 零偏未校准或地面不平检查 IMU 静态偏差、真机直线动作重新校准 IMU加入视觉/里程计融合后半程明显掉速电机温升导致驱动器降额读取驱动器温度日志降低持续功率增加散热调整步态能耗弯道侧向摔倒离心力补偿不足或倾斜角错误查看弯道段躯干横滚角曲线增大弯道向心加速度补偿延长弯道规划时间多数情况下“看日志”比“猜原因”更有效。人形机器人跑步的问题往往不是单一变量导致而是多个因素叠加比如通信延时变大、关节温度升高、地面摩擦力下降单独看每个参数都正常但加在一起就会摔倒。9. 最佳实践与工程建议如果团队正准备研发或者复现类似的高速双足机器人下面几条建议值得认真对待。9.1 安全机制优先高速运动必然伴随高风险。完善的急停按钮、机械限位、功率限制和场地围栏都是必备条件。任何时候都不能把算法验证和人身安全混在一起尤其是机器人的关节功率密度不断提高时。建议在控制代码里加入三重保护软件层面限制关节速度和力矩硬件层面通过驱动器电流限幅还有紧急制动逻辑。9.2 数据是最高优先级资产每一次跑步测试都应该被完整记录包括关节状态、控制指令、IMU 数据和最终结果。这样当一个问题重现时才能快速回放和分析。rosbag、时序数据库或者简单的 CSV 日志都可以关键是要形成习惯。9.3 软硬件版本统一管理人形机器人的工程迭代很快最佳实践是把机器人硬件版本BOM、控制软件版本、模型权重版本、仿真配置版本一起打标签管理。否则“昨天还能跑今天就不行”的问题会反复出现。可以建立类似下面的发布标签release/ultra_400m_v1.0 ├── bom/ultra_v2.1.xlsx ├── control/bin/control_v2.3.1 ├── model/run_policy_5000.pt ├── sim/config_20240801.yaml └── logs/test_20240801_1600.bag9.4 用成功率而非单次速度做指标单次成绩有偶然性。对工程团队来说真正可靠的验收指标是“100 次测试中成功完成 90 次以上”。速度只是结果成功率才代表系统真实能力。10. 结语人形机器人跑完 400 米39.70 秒这个成绩放在机器人发展的时间轴上是一个值得标记的点。但比起冠军和纪录我更在意的是这套系统背后的控制架构、仿真训练方法、芯片算力分配和工程迭代流程——它们决定了天工 Ultra 之后能不能跑 800 米、1500 米能不能在更多复杂地形上保持稳定能不能从赛场走进工厂、仓库和家庭。对正准备进入这个领域的开发者和团队来说真正的门槛不是某一次比赛的名次而是能否建立一套“数据回灌—仿真复现—真机验证”的闭环。双足跑步看起来是一个体力问题实际上是一个系统级的软件和工程问题。下一台能稳定跑完更长距离的人形机器人一定不是在某一次比赛中突然冒出来的而是把每一次摔倒都变成一条训练样本的那个团队做出来的。