天工Ultra跑赢人类？解析人形机器人高速奔跑背后的技术栈

38.15秒跑完400米，这不是人类运动员，而是人形机器人天工Ultra在首届世界人形机器人运动会上交出的成绩单。

看到这个数字，很多人的第一反应是：机器人已经跑得比人类还快了？是的，人类400米世界纪录是43.03秒（范尼凯克，2016年里约），而天工Ultra用38.15秒完成全程。但真正值得技术人关注的，不是“快过人类”这个新闻爆点，而是这背后的人形机器人技术积累：从走路都摔，到稳定高速奔跑，到底突破了什么？本文会从天工Ultra这次夺冠切入，拆解人形机器人高速奔跑背后涉及的硬件架构、运动控制算法、软件编排、仿真到现实的迁移流程，以及端侧算力这几条技术主线。

如果你正准备入行人形机器人、机器人操作系统或者具身智能方向，这篇文章帮你建立一张技术地图；如果你是做后端或嵌入式的，也会看到机器人工程与传统软件工程的本质差异在哪里。

1. 这篇文章真正要解决的问题

人形机器人“会跑步”和“会走路”是完全不同的两件事。跑步意味着每个步态周期里都有双脚腾空阶段，身体会周期性失去地面支撑，此时平衡主要靠前馈控制、动态稳定和高速关节响应来维持。稍有延迟，机器人就会摔倒。

天工Ultra能跑完400米，说明它至少解决了三个基础问题：

• 关节能输出足够功率，并且能持续工作不发热降额。
• 控制算法能在极短时间内计算出下一帧躯干姿态和落足点。
• 软件系统能在奔跑状态下稳定输出指令，中断延迟要足够低。

这三条分别对应硬件、算法和软件架构。很多人只盯着“它跑了多快”，却没意识到这是一次完整的工程系统验证。

结合当前人形机器人行业的搜索热词来看，天工Ultra、人形机器人芯片、人形机器人软件架构都是高频词。这说明行业关注点已经从“能不能造出来”转向“怎么让它稳定、高效、可量产地动起来”。这篇文章的目标读者是：想理解机器人运动能力技术栈的软件工程师、准备转入具身智能赛道的算法工程师，以及评估人形机器人产业成熟度的技术管理者。

读完你应该能回答：一个人形机器人要高速奔跑，硬件、软件、算法各自承担什么角色；仿真训练到底怎么迁移到现实；以及为什么芯片（比如全志科技等一批机器人芯片方案）会成为这条赛道的重要变量。

2. 从“会走路”到“能跑步”：人形机器人的运动能力阶梯

理解天工Ultra的突破，最好先把人形机器人运动能力拆成四个台阶。

2.1 第一步：静态稳定

这是最原始的阶段，机器人只有双脚站立，重心投影保持在支撑多边形内。此时移动很慢，每一步都要停下来重新找平衡。早期教育机器人、部分初代双足机器人，基本处于这个阶段。

2.2 第二步：准静态行走

机器人可以连续迈步，但重心控制很保守，步幅小、步频低。它的本质是“用速度换稳定”。很多商用双足机器人目前处于这个阶段，可以在平地上缓慢行走，遇到扰动会明显修正姿态，速度一般不高于0.5m/s。

2.3 第三步：动态行走

机器人开始利用惯性，让重心主动前倾，用落足点把重心“接住”。这个阶段机器人已经可以走出比较自然的步态，速度能到1.0～1.5m/s，能应对上下坡、门槛等复杂地形。它的控制核心是“重心动力学模型”和“落足点规划”。

2.4 第四步：奔跑

奔跑的本质是“周期性抛接身体”：机器人在腾空阶段没有地面反力，必须按照预定的身体弹道轨迹运动，并在着地瞬间用关节缓冲和主动发力接住身体，然后再次起跳。奔跑速度的提升，意味着腾空时间占比提高，对关节功率密度、传感器延迟和控制频率的要求呈指数级上升。

从公开报道看，天工Ultra以38.15秒完成400米，平均速度约10.5m/s，最高瞬时速度可能更高。它不是简单把“走路步态”频率调快，而是在控制架构上切换到了“跑动步态”模式，并经过了大量的仿真训练和实机调优。

这张表格可以帮助你判断一款人形机器人处于哪个阶段：

3. 高速奔跑的硬件基础：关节、减速器与传感器

跑步时机器人承受的地面冲击大约是自身体重的3到5倍。如果机器人重30kg，每个支撑腿瞬间要扛住100kg以上的冲击力。这种条件下，关节结构、减速器精度、传感器响应都会成为瓶颈。

3.1 关节电机与减速器

人形机器人奔跑主要靠髋、膝、踝三个部位的大功率关节。跑步与走路的关键差异在于：跑步时每个步态周期都会出现“双腾空”，膝关节要在极短时间内完成大角度屈伸，对关节峰值扭矩和扭矩密度要求极高。

为了在有限体积内输出更大扭矩，机器人关节通常采用“无框力矩电机 + 谐波减速器”或“行星减速器”的组合方案。谐波减速器体积小、重量轻、传动比大，但刚度略低，适合执行精细动作；行星减速器刚度高，抗冲击能力强，更适合腿部这类冲击大的关节。

天工Ultra作为竞速定位的机器人，关节设计大概率会偏向高功率密度。但具体采用哪种减速器方案，目前公开材料并未给出细节，建议以官方技术文档为准。

3.2 传感器：跑步时的“本体感觉”

跑步场景下，传感器系统面临的最大挑战不是“测量不准”，而是“延迟”。人形机器人的运动控制频率通常在500Hz到1kHz，意味着每个控制周期只有1到2毫秒。如果IMU（惯性测量单元）数据经过滤波后延迟超过5毫秒，控制器看到的姿态就已经“过时”，很容易在着地瞬间判断错误。

高速奔跑时，关键传感信息来自：

• IMU：提供躯干角速度和线加速度，是平衡控制的基础。
• 关节编码器：提供每个关节的角度和角速度，用于局部反馈。
• 足端力传感器 / 关节力矩传感器：判断着地和离地时机，是跑步周期切换的关键。
• 视觉 / 激光雷达：提供环境信息，但竞速场景下权重相对低。

这里容易踩坑的地方是：很多初学者会花大量时间调视觉感知，却忽视了IMU的状态估计质量。实际上人形机器人的高速运动稳定性，首先依赖的是“本体感觉”而不是“外部感知”。

3.3 散热与结构

跑步功率大，关节电机发热剧烈。如果散热设计不合理，电机连续工作几十秒后就会因温度过高降低输出功率（热降额），速度随之掉下来。因此，长距离竞速机器人的结构设计必须同时考虑轻量化和热管理，两者往往互相矛盾。

从这个意义上说，38.15秒跑完400米，考的不仅是爆发力，还是持续输出能力。材料里许多环节需要兼顾：骨架够轻、关节够强、散热够快。这也是为什么跑动类人形机器人的研发周期比想象中更长。

4. 人形机器人软件架构：感知、决策、控制三层

跑得快的人形机器人，本质上是一个“实时控制系统”，而不是“带轮子的程序”。它的软件架构通常分为三层。

4.1 感知层

负责收集和处理传感器数据。跑步场景下，感知层主要做状态估计，也就是把自己当前的角度、角速度、质心位置算出来。常见方案有：

• 扩展卡尔曼滤波（EKF）
• 互补滤波 / 解耦姿态估计
• 基于关节编码器和IMU的融合状态估计

4.2 决策与规划层

负责决定机器人往哪跑、下一步迈多大、身体姿态目标是什么。竞速场景下，规划层会输出质心运动轨迹、落足点序列、躯干俯仰角期望值。

跑步时，规划层通常基于“质心动力学”模型，把人形机器人简化为一个质心加多连杆腿的模型。因为奔跑是周期性运动，规划层可以借鉴人类跑步的步态周期参数，包括步频、步幅、支撑相和腾空相比例。

4.3 控制层

负责把规划层的期望轨迹转换成关节力矩指令。这一层是延迟敏感度最高的地方。控制层内部又分为：

• 上层：轨迹跟踪、力分配，比如基于MPC（模型预测控制）或WBC（全身控制）计算最优关节力矩。
• 下层：每个关节的位置、速度、力矩闭环控制，通常运行在MCU或实时核心上。

这三层之间通过共享内存、实时消息或低延迟通信中间件交换数据。相比通用操作系统，人形机器人更关注延迟的确定性，也就是“每个周期必须在规定时间内算完”，而不是“平均延迟足够低”。

5. 为什么传统控制不够用：MPC、全身控制与强化学习

5.1 传统PID控制的局限

PID（比例-积分-微分）控制适合调节单一变量。对人形机器人某个关节做位置跟踪时，PID可以工作得很好。但高速奔跑时，系统是多变量强耦合的：髋关节发力会改变质心位置，质心位置变化又会影响其他关节的受力。用一组独立PID控制所有关节，很难处理这种耦合。

5.2 模型预测控制（MPC）

MPC的思路是：在每个控制周期，先基于当前状态预测未来几十毫秒内系统会怎样演化，然后求解一个有限时域最优控制问题，得到最优的关节力矩指令，只执行第一步，下一周期重新求解。

在跑步控制中，MPC通常用来规划质心运动和落足点。它把机器人抽象成线性倒立摆或质心动力学模型，求解出身体在某一时刻该处于什么位置、速度是多少，再由下半层的全身控制器计算具体关节力矩。

下面是MPC落足点规划层的简化伪代码，展示核心思路：

# mpc_footstep_planner.py # 简化展示：基于线性倒立摆模型的MPC落足点规划 # 实际工程中使用更复杂的质心动力学模型和QPsolver import numpy as np from scipy.optimize import minimize class LIPMFootstepPlanner: def __init__(self, mass, g, height, horizon=10): self.mass = mass # 机器人质量 kg self.g = g # 重力加速度 self.height = height # 质心高度 self.horizon = horizon # 预测步数 def _predicted_com_state(self, x_pos, v_pos, footstep, dt): """按线性倒立摆模型预测质心状态""" omega = np.sqrt(self.g / self.height) # 落到目标落足点上时的质心位置 x_next = (x_pos - footstep) * np.cosh(omega * dt) \ + (v_pos / omega) * np.sinh(omega * dt) + footstep v_next = (x_pos - footstep) * omega * np.sinh(omega * dt) \ + v_pos * np.cosh(omega * dt) return x_next, v_next def solve(self, com_pos, com_vel, target_velocity, dt): """最小化质心与目标速度的偏差，求解最优落足点""" n = self.horizon steps = np.zeros(n) def cost(z): # z 是未来 n 步的落足点序列 cur_pos = com_pos cur_vel = com_vel total_cost = 0.0 for i in range(n): foot = z[i] cur_pos, cur_vel = self._predicted_com_state( cur_pos, cur_vel, foot, dt ) total_cost += ( (cur_vel - target_velocity) ** 2 + 0.01 * (foot - cur_pos) ** 2 ) return total_cost res = minimize(cost, steps, method='SLSQP') return res.x[0] # 只执行第一步落足点，下一周期重新求解 # 使用示例 planner = LIPMFootstepPlanner(mass=30, g=9.8, height=0.9) next_footstep = planner.solve(com_pos=0.0, com_vel=2.5, target_velocity=3.5, dt=0.02) print("下一落足点:", next_footstep)

这段代码的关键是：通过线性倒立摆模型预测未来质心运动，不断搜索最优落足点，使质心速度逼近目标速度。实际工程里不会用scipy的minimize在线求解，因为算力不够、延迟不允许，而是会用离散线性模型把问题转成二次规划（QP），用qpOASES或OSQP这类专用求解器在1ms内完成。

5.3 全身控制（Whole-Body Control）

MPC输出的是质心轨迹和落足点，但机器人有多个关节，怎么把质心运动转换为每个关节的实际力矩？这就需要全身控制层。

WBC的核心思想是：把任务分成不同优先级，比如“保持脚不滑动”优先级最高，“躯干保持水平”次之，“末端摆动跟轨迹”再次之。然后在一个优化问题里同时求解所有关节力矩，保证高优先级任务尽量满足，低优先级任务在不影响高优先级的前提下尽量完成。

人形机器人跑步时，WBC还需要处理足底触地状态的切换。在支撑相，脚是固定的，重心由反作用力支撑；在腾空相，脚是自由的，关节运动需要按腿部摆动轨迹来驱动。因此WBC控制器内部实际上是一个“混合控制”模式，状态切换信号通常来自足底传感器或关节力矩阈值。

5.4 强化学习凭什么后来居上

传统MPC+WBC的好处是可解释、可调试，但坏处是模型精度要求高。实际机器人的质心高度、转动惯量、关节阻尼并不精确，建模误差会导致控制器在高速运动时“失真”。

近几年的做法是把控制策略交给强化学习（RL）。RL不需要精确的动力学模型，而是通过大量与仿真环境的交互，让策略网络学会“看到什么状态，输出什么关节动作”。DeepMind等机构已经展示过用RL让机器人跑出稳定步态，并且具备很强的抗扰动能力。

人形机器人的RL训练通常采用“动作状态观测+奖励函数”的范式，下面是跑步训练奖励函数的简化示例：

# running_reward.py # 强化学习跑步训练奖励函数（示例），基于Isaac Lab / MuJoCo 环境封装 import math class RunningReward: def __init__(self): self.target_speed = 3.5 # 目标速度 m/s self.penalty_energy = 0.1 # 能耗惩罚系数 def reward(self, obs, action): """ obs 包含：躯干线速度 vx, vy, vz，躯干姿态角，关节角度，关节角速度，着地标志 """ vx = obs["lin_vel_x"] vy = obs["lin_vel_y"] # 1. 速度跟踪奖励：速度越接近目标越高 speed_reward = math.exp(-2.0 * (vx - self.target_speed) ** 2) # 2. 方向惩罚：横向速度越小越好 lateral_penalty = 0.5 * (vy ** 2) # 3. 姿态稳定奖励：躯干尽量保持竖直 pitch = obs["orientation_pitch"] roll = obs["orientation_roll"] posture_reward = math.exp(-5.0 * (pitch ** 2 + roll ** 2)) # 4. 能耗惩罚：动作幅度和频率越大，惩罚越高 energy_penalty = self.penalty_energy * sum(a * a for a in action) # 5. 高度稳定奖励：防止机器人压低重心或跳太高 height = obs["body_height"] height_reward = math.exp(-2.0 * (height - 0.9) ** 2) total_reward = ( speed_reward + 0.8 * posture_reward + 0.5 * height_reward - lateral_penalty - energy_penalty - 1.0 if not obs["contact"] else 0.0 ) return total_reward

实际训练中，奖励项比这复杂得多，还需要加入接触力约束、关节范围限制、翻身恢复机制等。强化学习的难点在于：仿真里表现得再好的策略，搬到真实机器上可能立刻失效。这就是接下来要说的Sim-to-Real问题。

6. 从仿真到现实：Sim-to-Real训练方法与代码示例

天工Ultra这种竞速机器人不可能在真机上从头一步步试错，因为摔一次可能就是几十万的关节维修成本。主流的做法是在仿真环境里先训练，再迁移到真实机器人。

6.1 为什么仿真训练这么重要

仿真训练的优点是速度快、成本低、可并行。真实机器人跑一次400米需要40秒，加上调试和休息，一天最多跑几百次。但仿真环境可以同时开几百个并行实例，几分钟就能跑完数万次训练数据。

仿真训练的缺点是“仿真与现实之间的差距”（sim-to-real gap）。真实世界有摩擦系数变化、电机电气延迟、关节间隙、散热降额等因素，这些在仿真里很难精确建模。

6.2 域随机化

域随机化是缩小sim-to-real gap的有效手段。做法很简单：在训练过程中，随机改变机器人的质量、摩擦系数、电机推力、传感器噪声等参数。让策略不要“过度依赖”某一组精确参数，而是学会在各种物理参数下都能稳定行动。

一个典型的仿真环境参数配置看起来像这样：

# sim_config.yaml # 简化版人形机器人跑步仿真配置，实际以你的仿真引擎为准 environment: physics_engine: "muJoCo" timestep: 0.002 # 2ms 控制步长 num_envs: 2048 # 并行环境数 robot: urdf: "models/tian_geng_ultra.urdf" initial_state: pos: [0.0, 0.0, 0.9] # x, y, z orientation_pitch: 0.0 orientation_roll: 0.0 control_type: "torque" joint_effort_limit: 300.0 randomization: mass_scale: [0.85, 1.15] friction_coef: [0.4, 1.2] motor_torque_scale: [0.9, 1.1] sensor_noise: imu_gyro_noise: 0.05 joint_encoder_noise: 0.01 task: command: "forward_speed" target_speed_range: [2.0, 4.5] episode_length: 2000

这段配置的核心是randomization部分。训练时，每个并行环境都会从随机范围内采样一组物理参数，相当于让策略“见过”很多种可能的机器人，而不是只适应一个“完美仿真模型”。跑通训练后，把同样的策略直接部署到真机上，成功率会大幅提升。

6.3 训练流程

一个典型的训练流程是：

• 在仿真中搭建机器人模型和环境。
• 定义方向、速度指令，初始化观测空间和动作空间。
• 设置奖励函数和域随机化参数。
• 用PPO（近端策略优化）或SAC（软演员-评论家）算法训练策略。
• 在仿真中保存最佳checkpoint。
• 将策略导出为ONNX格式，部署到机器人端侧设备。
• 在真机上用小步幅、小速度进行验证，逐步提高目标速度。

如果迁移后真机效果不佳，通常不是策略本身不行，而是“观测噪声建模不够”或“执行延迟没建模”。一个常见优化是在仿真里加入动作延迟，让策略学会适应“指令发出后一个周期才真正生效”的现实情况。

7. 芯片与边缘计算：机器人跑得快，算力在哪里

人形机器人要实时处理海量传感器数据，执行复杂的控制器和神经网络推理，算力的关键程度不亚于电机。观察人形机器人赛道的热门关键词可以发现，除了天工Ultra这样的本体厂商，全志科技等芯片厂商也开始将人形机器人芯片作为重点方向。

7.1 人形机器人需要几种算力

人形机器人的计算需求可以分成三个层面：

• 小脑级控制：负责关节伺服、底层运动控制，延迟要求通常在1ms以内，运行在MCU或带实时功能的处理器上。
• 大脑级决策：负责任务规划、导航、视觉识别，可以跑在英伟达Jetson Orin、地平线征程、全志科技机器人芯片等端侧AI算力平台上，延迟容忍度相对高一些，通常在10～100ms。
• 云端：负责复杂大模型推理或长时间训练，不参与实时控制。

跑400米这个场景里，最关键的是“小脑”层面的算力，也就是控制策略推理必须在几毫秒内完成。如果策略是一个神经网络，它要么被部署在带有GPU/NPU的端侧芯片上，要么被精简成轻量级网络后部署在ARM核上。

7.2 为什么芯片是隐形变量

一个高性能机器人本体，如果没有合适的端侧芯片，仍然跑不起来。原因很直接：

• 控制频率足够高，CPU才能及时完成MPC求解。
• NPU算力足够强，强化学习策略推理延迟才可控。
• 传感器接口丰富，IMU和编码器数据才能低延迟接入。
• 功耗合适，电池续航才不会因为计算发热被拖着走。

从材料看，全志科技等芯片厂商切入人形机器人芯片，意味着这类芯片不只是“通用处理器”，而是开始针对机器人场景做专用优化，比如集成更灵活的电机控制接口、更强的NPU算力，以及针对Sim-to-Real部署的模型转换工具链。

对研发团队的建议是：选芯片时不能只看TOPS算力，还要看“控制实时性”“外设接口”“工具链成熟度”和“功耗”。跑步场景里，算力再强，如果它的推理延迟抖动超过5ms，就不能用在控制回路上。

8. 38.15秒的意义：比速度更重要的是工程化验证

回到比赛本身。天工Ultra以38.15秒完成400米，夺得人形机器人运动会首金。抛开“破人类纪录”这个传播点，从工程技术角度看，这件事的价值在于：

8.1 长期工作的稳定性

高速奔跑不是一秒钟的爆发，而是几十秒内持续保持高功率输出。这说明关节散热、电池放电、控制稳定性和结构机械强度都经受住了考验。对于一个要在真实场景里干活的人形机器人来说，这个价值高于单次跑得更快。

8.2 控制算法在极限状态下的可信度

38.15秒跑完400米，意味着机器人频繁经历“腾空—着地”切换，躯干姿态和落地冲击都处在极限边缘。这个状态下没有摔倒，说明它的控制算法对状态估计误差、地面冲击和关节延迟具备足够的鲁棒性。

8.3 仿真到现实迁移的可行性验证

能在比赛舞台上稳定跑完全程，大概率经历了大量仿真训练和真机验证。这本身证明了当前人形机器人研发流程已经从“手搓控制”转向“软件定义运动”的方法论。

但同时也要冷静看待：跑步比赛是环境最可控的场景之一。地面平整、没有障碍、赛道固定，和人形机器人真正要落地的仓储、制造、家庭场景相比，复杂度和不确定性还差很远。38.15秒的首金，验证的是“运动基座”，不是“通用智能”。

9. 常见误区与研发体检清单

在这一节，我整理给人形机器人研发新手看的常见误区和自查清单。

9.1 常见误区

误区一：速度上不去就加大电机功率。

加大电机功率会带来重量增加、散热变差、结构载荷变高，往往得不偿失。更高明的做法是优化步态、降低无效能耗、提高能量回收效率。

误区二：策略在仿真里跑得动，真机一定行。

这是最典型的坑。仿真和现实之间永远存在物理参数差异。上线前必须做域随机化，并且在真机上从小步幅、低速开始验证。

误区三：控制频率越高越好。

控制频率受传感器、执行器、通信带宽共同限制。盲目提高到2kHz以上，可能带来电磁干扰、发热和执行延迟，而不是更好效果。应该以系统瓶颈为准。

误区四：视觉越重越好。

高速运动控制依赖本体感觉，视觉数据经过深度神经网络推理后延迟通常在几十毫秒，不适合作为运动控制主反馈。视觉更适合做路径规划和避障。

9.2 研发体检清单

10. 总结与后续学习方向

人形机器人天工Ultra跑出38.15秒，确实值得技术人关注。它告诉我们：人形机器人运动能力已经跨过了“会跑”的门槛，并且“跑得快”已经不是纯粹的机械问题，而是机械、控制算法、软件架构、仿真训练和端侧算力协同优化的结果。

如果你想深入这个领域，建议按以下顺序学习：

• 先学机器人运动学与动力学基础，理解齐次变换、雅可比矩阵、拉格朗日方程。
• 再学线性倒立摆模型和ZMP（零力矩点）概念，这是步行与奔跑控制的地基。
• 然后学MPC和WBC，理解多任务优先级控制的思想。
• 再接触Isaac Lab、MuJoCo这类仿真环境，跑通一个简单的双足平衡任务。
• 最后尝试用强化学习让仿真模型走起来，再做Sim-to-Real迁移。

这条学习路线不短，但每一步都有清晰的验证目标。如果你目前的主力语言是Python或C++，并不需要重新学一套语言体系；机器人控制真正难的不是语法，而是把物理规律、实时系统和概率估计组合在一起的那个“工程直觉”。

下一篇文章我可以继续拆解人形机器人的全身控制里的“任务优先级”具体怎么排，以及强化学习训练里最容易让机器人变“瘸子”的奖励设置陷阱。建议收藏本文，后续实践时对照排查。