天工 Omni 用 45.66 秒跑完 400 米的小型组决赛这个成绩在普通人眼里可能只是“一台机器人跑得挺快”但在做机器人的工程师眼里这背后牵扯的是运动控制、足底力感知、实时算力分配、芯片选型、仿真迁移这一整套系统工程。最近“人形机器人”“天工 Omni”的关注度一直很高再加上“人形机器人芯片”“人形机器人软件架构”这些热词被反复讨论我想趁着这次赛事结果把一条完整的技术链路拆开来讲。这篇文章不是新闻复述而是一篇偏向工程视角的技术拆解。我会从比赛成绩换算出发依次聊到人形机器人的运动控制原理、硬件执行器、端侧算力与芯片、软件分层架构、仿真训练和 Sim2Real 迁移最后整理一份常见的调试验证思路。适合机器人方向的研究生、嵌入式工程师、算法工程师以及正在做人形机器人产品落地的团队阅读。1. 一场 400 米比赛背后的技术信号1.1 世界人形机器人运动会是什么人形机器人运动会本质上不是把机器人拉出来“比娱乐”而是把机器人领域最难的几个技术方向设计成可以量化打分、比较、复现的竞技场景。跑步、跳高、抓取、越障这些项目每一类都在考机器人不同维度的能力。短跑和长跑考验步态频率、动态平衡、关节峰值功率。跳跃和越障考验腿部爆发力、落地的柔顺控制、冲击吸收。抓取和操作考验机械臂精度、视觉伺服、力控。“第二届世界人形机器人运动会”这样的赛事意味着人形机器人已经不只是停留在实验室演示阶段而是有一套相对标准的评测体系。对于行业来说这类赛事的价值不只是选出谁快谁慢更重要的是把不同团队的技术路线放到同一个跑道上比较让大家看到哪些方案能真正跑出速度、稳住姿态。1.2 45.66 秒意味着什么先做一个简单的数学换算。400 米用时 45.66 秒平均速度约等于[ v \frac{400}{45.66} \approx 8.76 \text{ m/s} ]这个数字如果换成人类运动员已经是相当快的水平。但对于机器人来说赛道长度、转弯半径、起跑方式、机器人本体尺寸都会影响最终成绩所以不能直接拿这个平均速度去和人类短跑成绩做粗暴对比。更值得关注的是另一个角度一台双足机器人能持续输出 8.76 m/s 的平均速度说明它的电机驱动、电池放电、关节散热、控制算法都已经能在数十秒量级内稳定工作。从工程角度看这个成绩至少传递出三个信号运动控制算法已经能够处理“高速奔跑”状态下的动态平衡而不是只停留在慢走。执行器和驱动器的扭矩密度、响应带宽有了明显提升。整机系统的实时性、通信总线带宽、状态估计延迟已经达到了高速运动的基本要求。也就是说45.66 秒不只是数字它背后是机械、电子、算法、软件四个层面同时达到一个可用的均衡点。单一模块强很难夺冠木桶效应在这个领域表现得非常明显。2. 人形机器人的核心系统构成2.1 从“能走”到“快跑”的跨越很多人对人形机器人的印象还停留在“能稳稳走路、能上下楼梯”。但从“能走”到“快跑”难度是跳跃式上升的。走路时机器人大部分时间都处于准静态或准动态状态质心的投影只要落在脚掌支撑多边形内就不会摔倒。跑步则完全不同。跑步过程中会出现双腿同时离地的“腾空相”此时机器人没有地面支撑相当于一个自由的抛体必须依靠提前规划好的质心轨迹和着地瞬间的足端阻抗才能在落地后继续保持稳定。这里有一个关键概念ZMPZero Moment Point零力矩点。走路时ZMP 必须始终落在支撑脚脚掌范围内。跑步时ZMP 在腾空相不存在机器人需要在地面反作用力、惯性力、重力之间做精确的协调。这也是为什么高速跑步比慢速行走对控制频率、状态估计精度、执行器响应速度的要求高出一个量级。天工 Omni 能在 400 米赛道上保持高速奔跑说明它的控制方案已经不只是传统的 ZMP 步态规划而是大概率采用了更现代的控制框架例如模型预测控制加全身动力学控制或者基于强化学习的运动策略。2.2 系统模块拆解一台完整的人形机器人可以拆成下面几个主要部分子系统主要部件作用感知系统IMU、关节编码器、足底力传感器、RGB-D 相机、激光雷达估计本体状态和外部环境决策系统运动规划、导航、任务规划决定下一步做什么、走哪里运动控制系统MPC、WBC、步态生成器、强化学习策略把目标速度转换为关节指令执行系统伺服电机、减速器、驱动器输出关节力矩实现物理运动芯片与算力平台运动控制芯片、AI 推理芯片、MCU运行算法并保证实时性能源系统电池、电源管理模块提供瞬时大功率输出任何一个子系统变成短板机器人就跑不快。比如电池放电倍率不够电机就无法获得足够的瞬态功率关节减速器背隙太大高速奔跑时就会产生抖动IMU 噪声过高状态估计就会漂移最终导致摔倒。3. 运动控制跑得快还稳的底层原理3.1 步态规划基础人形机器人的步态规划核心是设计质心和足端的运动轨迹。一个完整的跑步周期可以分为支撑相和腾空相。支撑相里脚与地面接触产生推进力腾空相里机器人离开地面质心沿抛物线运动。为了简化分析工程师通常先把机器人简化为“线性倒立摆模型”。在倒立摆模型下质心高度近似恒定可以推导出质心运动与 ZMP 的关系[ \ddot{x} \frac{g}{h} (x - p_x) ]其中 (x) 是质心水平位置(p_x) 是 ZMP 位置(h) 是质心高度。跑步时这个模型需要扩展成“三维线性倒立摆”或“弹簧负载倒立摆”。腾空相加入弹道模型支撑相加入地面反作用力的约束。虽然实际系统比这个复杂得多但这些简化模型是理解控制框架的基础。3.2 模型预测控制与全身动力学控制当前人形机器人高速运动的主流控制方案基本是“分层控制”的组合。上层模型预测控制。MPC 会根据当前的机器人状态质心位置、速度、朝向预测未来 1 到 3 秒内的最优运动轨迹并计算出每一步的足端落点、质心加速度、ZMP 参考值。下层全身动力学控制。WBC 接收 MPC 输出的参考轨迹再结合机器人的完整动力学模型把任务优先级分成多个层次比如“保持平衡”优先级最高“跟踪质心速度”其次“保持身体姿态”再次最后计算出每个关节需要输出的力矩。这种分层的好处是MPC 负责“看得远”WBC 负责“此刻怎么发力”。两者配合才能在高速奔跑中同时兼顾稳定性和速度。3.3 强化学习策略传统控制方法在建模准确、环境可预测的场景下表现很好但真实赛道上的地面摩擦力、轻微坡度、光照变化都会让模型失准。近年来基于强化学习的运动策略越来越受到关注。在强化学习方案里不需要手工设计每一步的落点规则。先建立机器人的仿真模型然后在仿真环境中让机器人不断试错通过奖励函数引导它学习高速奔跑的行为。比如给“前进速度”正向奖励给“摔倒”较大惩罚给“能耗过大”轻微惩罚经过大量训练后策略网络就能输出合理的关节目标位置或力矩。天工 Omni 这类跑出高速成绩的机器人通常会采用“RL 生成步态 传统控制兜底”或者“RL 策略 低层 PID 跟踪”的混合方案兼顾鲁棒性和安全性。下面是一个高度简化的人形机器人运动控制主循环用于展示整体流程。注意这只是演示结构不能直接用于真实机器人。# 简化的人形机器人运动控制主循环仅演示流程 import time CONTROL_HZ 1000 DT 1.0 / CONTROL_HZ def read_sensors(): # 读取 IMU、关节编码器、足底力传感器数据 # 实际项目中会通过 EtherCAT/CAN 等总线获取 return { imu: [0.0, 0.0, 9.8], joint_pos: [0.0] * 12, joint_vel: [0.0] * 12, foot_force: [0.0] * 2, } def estimate_state(sensor_data): 状态估计根据传感器数据估算质心位置、速度、朝向和步态相位。 真实系统中通常使用扩展卡尔曼滤波或因子图优化。 return { pos: (0.0, 0.0), vel: (0.0, 0.0), phase: 0.0, } def optimize_trajectory(goal_speed, current_state): 轨迹优化使用 MPC 或强化学习策略求解未来运动轨迹。 输入目标速度输出质心加速度和足端落点参考。 return { target_vx: goal_speed, zmp_ref: (0.0, 0.0), } def compute_joint_torques(ref_trajectory, current_state): 关节力求解通过 WBC 或策略网络将参考轨迹转换为关节力矩。 return [0.0] * 12 def send_torques(joint_torques): # 下发关节力矩到各关节驱动器 pass def should_stop(): # 根据急停开关、控制器状态判断是否需要停止 return False if __name__ __main__: goal_speed 4.0 # 目标速度单位 m/s while not should_stop(): sensor read_sensors() state estimate_state(sensor) ref optimize_trajectory(goal_speed, state) torques compute_joint_torques(ref, state) send_torques(torques) time.sleep(DT)控制频率永远是这里的关键指标。如果控制频率只有 100Hz机器人很难完成稳定的高速跑步一般来说关节伺服频率要做到 1kHz 以上上层运动规划至少也要 100Hz 到 500Hz才能保证快速响应。4. 硬件与芯片算力上的账4.1 执行器与传感器跑步成绩离不开硬件支撑。人形机器人的腿部关节尤其是髋关节、膝关节和踝关节需要同时满足高扭矩、高转速、小体积三个条件。电机目前主流方案是无框力矩电机或盘式电机配合高精度减速器。减速器谐波减速器常用于关节扭矩放大但背隙和柔性问题需要通过算法补偿行星减速器刚度更好适合大扭矩输出。驱动器负责电流环控制需要支持高带宽的力矩指令。传感器方面除了关节编码器和电机编码器足底六维力/力矩传感器是高速跑步中必不可少的。机器人落地瞬间的地面反作用力直接决定了下一步的落脚策略。如果足底力传感器延迟太高控制算法就很难在落地瞬间做出正确的阻抗调节。4.2 人形机器人芯片与计算平台人形机器人“跑得聪明”还要“跑得快”芯片和算力平台非常关键。当前人形机器人计算平台通常不是单一大芯片而是分成多个层级。感知芯片处理 RGB-D 相机、激光雷达数据运行目标检测、分割、导航算法。这类任务对并行算力和 AI 加速能力要求较高常见选择是带 NPU 的 SoC。运动控制芯片运行状态估计、MPC、WBC 等实时控制算法。这类算法对实时性要求极高但对通用 AI 算力要求不高通常使用 MCU 或实时处理器。通信与 IO 芯片负责与关节驱动器、传感器之间的总线通信例如 CAN、EtherCAT、SPI。随着“人形机器人芯片”成为行业热词越来越多的芯片厂商开始针对机器人场景做定制化设计。比如全志科技等国产芯片厂商也在布局人形机器人相关计算平台核心思路是把 CPU、NPU、实时控制、外设接口集成在一起减少板卡数量降低功耗和布线复杂度。具体型号和算力参数需要以官方发布的信息为准但从趋势上看端侧芯片正在从“通用开发板”走向“机器人专用 SoC”。4.3 功耗与散热高速奔跑时电机峰值功率可能达到数百瓦甚至上千瓦电池需要具备足够的放电倍率。这里有一个容易被忽视的问题散热。跑 400 米用时 45 秒对关节电机来说意味着持续高功率输出。如果电机和驱动器没有良好的散热措施长时间运行后会出现扭矩下降、控制性能衰减严重时甚至烧毁线圈。因此真实比赛中的散热策略通常是“硬件散热 软件限流”双管齐下。软件上可以通过控制算法限制关节温升比如当某个关节温度过高时自动降低它的输出功率上限硬件上则要做好导热路径、散热鳍片甚至设计液冷回路。对于追求速度的竞速机器人这些设计缺一不可。5. 软件架构从感知到执行的链路5.1 分层软件架构“人形机器人软件架构”是这次热词中出现频率很高的一个方向。一套完整的人形机器人软件架构通常可以按“感知、决策、控制、执行”四层来拆解。层级职责典型组件频率感知层环境理解、本体状态估计视觉 SLAM、IMU 融合、足底力处理30Hz - 200Hz决策层任务规划、路径规划、步态选择导航栈、行为树、大模型任务编排10Hz - 50Hz控制层轨迹生成、力控制、平衡控制MPC、WBC、强化学习策略100Hz - 1000Hz执行层关节电流环控制、总线通信伺服驱动器、电机编码器1kHz - 10kHz每一层之间通过明确定义的接口通信。比如感知层输出“前方 2 米有障碍物”决策层输出“切换为绕障步态”控制层输出“每个关节的目标力矩”执行层完成最后的物理控制。5.2 一个简化的控制循环示例前面已经给出了一个控制主循环的示意代码。实际项目中控制循环所在的进程必须严格保证实时性不能因为日志打印、网络阻塞而出现时序抖动。常见做法是把实时控制代码放在独立的实时线程中并使用锁内存、无锁队列与上层通信。下面是一个典型的分层节点配置片段以 YAML 格式展示实际项目中会放在 ROS 2 的参数文件或自研框架的配置中心中。# 示例运动控制节点参数配置片段 motion_controller: ros__parameters: control_frequency: 1000 max_forward_velocity: 5.0 foot_clearance: 0.08 zmp_height: 0.85 use_mpc: true use_wbc: true foot_force_estimator: ros__parameters: sensor_frequency: 500 filter_cutoff_hz: 30 state_estimator: ros__parameters: imu_topic: /sensor/imu joint_state_topic: /sensor/joint_states publish_frequency: 200这套配置表达的核心思想是不同模块运行在不同频率控制层必须最高频实时运行感知层可以适当降低频率层与层之间通过主题或共享内存解耦。5.3 通信与中间件的选择人形机器人内部的通信架构直接决定了数据通路是否畅通。常见方案有两类第一类是基于 ROS 2 的方案利用 DDS 的发布/订阅机制方便上下层解耦也容易复用开源生态里的导航、感知模块。但 ROS 2 在实时性上仍有抖动通常不能直接用于关节伺服回路。第二类是在关键关节控制链路使用 EtherCAT、CANopen、共享内存等硬实时通道把传感器数据直接送到控制线程避免经过通用网络协议栈。一个成熟的人形机器人工程往往是两种方案并存。对外部环境感知、上层任务规划用 ROS 2对关节伺服、足底力采集、状态估计用硬实时通道中间通过共享内存接口桥接。这样才能既保证开发效率又保证高速奔跑时的控制稳定性。6. 仿真训练与 Sim2Real 迁移6.1 为什么离不开仿真如果你真实操作过双足机器人就会知道真机调试非常昂贵且耗时。机器人的每一次摔倒都可能损坏关节、电机、外壳。如果靠真机训练强化学习策略一次训练可能需要数百万次交互这在现实中完全不可行。所以当前业界普遍采用“仿真大规模训练 真机小规模微调”的路线。先在 MuJoCo、Isaac Gym、Isaac Lab 等仿真环境中让机器人进行千万次以上的运动尝试学习出基本的高速奔跑步态然后再迁移到真机上。当“天工 Omni 以 45.66 秒夺冠”这类成绩出现时背后大概率不是团队在赛前临时调参数调出来的而是基于仿真环境里训练好的策略再结合真机数据反复迭代出来的结果。6.2 仿真训练代码示例下面给出一段强化学习训练的结构示意代码。请注意这段代码不能直接运行它只是用于展示训练流程中环境、策略、数据回放之间的协作关系。实际项目中需要对接完整的仿真环境、奖励函数设计和策略网络实现。# 强化学习训练人形机器人跑步策略结构示意代码 import torch import torch.nn as nn class PolicyNet(nn.Module): 策略网络输入机器人状态观测输出动作指令。 真实项目中通常包含 MLP、LayerNorm 等结构。 def __init__(self, obs_dim: int, action_dim: int): super().__init__() self.net nn.Sequential( nn.Linear(obs_dim, 256), nn.ReLU(), nn.Linear(256, 256), nn.ReLU(), nn.Linear(256, action_dim), ) def forward(self, obs): return self.net(obs) def compute_reward(obs, action, next_obs, terminated): 奖励函数设计 - 前进速度越大奖励越高 - 倒下或关节超限给予大惩罚 - 能耗太高给予小惩罚 forward_vel next_obs[(base, lin_vel_x)] reward 2.0 * forward_vel if terminated: reward - 20.0 return reward def train_loop(env, policy, optimizer, replay_buffer, total_steps): obs, _ env.reset() for step in range(total_steps): action policy(obs).detach().numpy() next_obs, reward, terminated, truncated, info env.step(action) replay_buffer.push(obs, action, reward, next_obs, terminated) if terminated or truncated: obs, _ env.reset() else: obs next_obs # 每隔一定步数从经验池采样并更新策略 if step % 512 0: batch replay_buffer.sample(256) loss compute_policy_loss(policy, batch, optimizer) optimizer.zero_grad() loss.backward() optimizer.step()这里最需要关注的是奖励函数设计。对于跑步任务奖励函数不能只鼓励“往前走”还要约束姿态不要过度前倾、不要做出夸张的摆臂动作、关节不要超出限位。奖励函数写得好不好直接决定了训练出来的步态是否自然、是否抗干扰。6.3 领域随机化思路仿真训练出来的策略直接部署到真机上往往会出现“仿真里很稳真机上一跑就倒”的问题这就是 Sim2Real gap。解决这个问题最常用的手段是“领域随机化”。具体来说在训练过程中随机化机器人的动力学参数、传感器噪声、地面摩擦力、电机延迟等。让策略在成千上万种不同的“环境变体”中学习最终得到的策略就不会过度依赖某一组精确的参数而是具有更强的泛化能力。比如可以将电机扭矩系数在前 0.9 倍到 1.1 倍之间随机变化将地面摩擦系数在 0.6 到 1.4 之间随机变化。这样训练出来的策略到了真实赛道上即使遇到摩擦力变化也能比较稳定地继续奔跑。不过需要注意的是领域随机化并不是万能的。随机化范围太大会导致策略过于保守速度上不去随机化范围太小又无法覆盖真实的建模误差。找到合适的随机化区间本身就需要大量真机数据做标定。7. 这场赛事中容易被忽略的工程细节7.1 稳定性优先还是速度优先在 400 米竞速中很多团队会思考一个问题到底让机器人以极限速度跑还是保留一些余量稳着跑答案是在决赛前往往已经通过仿真和控制算法确定了安全的速度上限。赛场上不会临时把速度调到极限因为一旦摔倒成绩归零损失远大于保守策略下的时间损失。真正成熟的控制策略应该能根据地面反馈动态调节速度。比如脚底打滑时MPC 会降低期望速度抓地力充分时再适当提速。这种“能力边界内的自适应调速”比单纯追求最高速度更能反映一个团队的控制水平。天工 Omni 能以 45.66 秒完成比赛说明它的控制策略在整场中没有出现明显失误稳定性是夺冠的基础。7.2 常见问题与排查思路人形机器人高速奔跑调试中常见的问题和排查方向可以整理成一张表问题现象常见原因解决思路跑步时频繁摔倒状态估计不准或 MPC 参数不合理检查 IMU 数据是否漂移检查足底力传感器标定膝关节大量发热关节输出功率过高、散热不足降低限幅、优化步态、增加散热结构高速跑动时抖动控制频率不足、关节背隙过大、通讯延迟高提高控制频率检查总线带宽和时钟同步跑偏到赛道外视觉导航失效或步态左右不对称检查相机标定检查腿部关节零位校准起跑响应慢MPC 预测时域过短或策略网络推理延迟高优化推理框架缩短计算链路电池电压骤降放电倍率不足或电池老化使用高倍率电芯调整功率管理7.3 数据采集与回放高速奔跑过程中控制算法的调试离不开高质量的数据回放。比赛现场通常不允许接一堆线缆所以机器人本体需要内置数据记录模块把每个关节的指令、力矩、实际位置、IMU 信息、足底力数据同步记录下来。一个推荐的记录方案是使用高精度时钟同步所有传感器数据。按固定时间间隔写入环形缓冲区。遇到摔倒或异常时自动保存前后 10 秒的完整数据。赛后通过离线脚本回放逐帧分析是哪个环节先失稳。这套数据闭环能力是很多团队拉开差距的地方。谁的调试数据更完整、回放工具更顺手谁就能在比赛间隔时间内更快修正问题。8. 最佳实践与未来方向8.1 工程建议看完天工 Omni 的赛事成绩再结合人形机器人的开发经验这里整理几条我认为值得重视的工程建议。第一控制频率和通信时延必须提前验证。不要等到整机联调时才发现总线带宽不足。有一个简单的方法在搭建硬件系统时先用一台工控机模拟全部关节节点测量最坏情况下的通信时延确认小于控制周期的十分之一。第二仿真和真机的边界要画清楚。仿真能解决 80% 的步态学习问题但真机上的关节零位、机械摩擦、温度变化很难完全建模。建议在真机上做小范围运动测试用数据校准仿真参数形成“仿真训练—真机验证—反馈校准”的闭环。第三安全机制永远不能省。高速奔跑的机器人如果突然失去控制非常危险需要设计多级急停软件限位、控制层急停、硬件层断电。比赛前一定要做完整的急停演练。第四关注“人形机器人芯片”和“人形机器人软件架构”的趋势。端侧芯片正在往高集成度、低功耗、强实时性方向发展软件架构也正在从“贴片式集成”走向“平台化分层设计”。团队的软件架构如果一开始就有清晰的分层边界后续适配新硬件、新算法都会容易很多。8.2 下一步可以关注什么从这次赛事的成绩出发我觉得人形机器人领域有四个方向值得持续关注。第一个方向是端到端运动策略。传统“感知 MPC WBC”的管线模块多、调参难。未来如果把视觉信息、本体状态直接输入一个大模型由模型直接输出关节动作可能会大大简化系统复杂度。第二个方向是更高级的跑跳结合。400 米只是平跑如果加入障碍跳跃、转弯变向对控制算法的挑战会更大。第三个方向是腿臂协同。人形机器人的优势在于上半身和下半身同时工作跑步时也要考虑手臂摆动对平衡的影响。将来竞速项目可能不只是比腿部还要比全身协调能力。第四个方向是工程可量产性。比赛成绩可以通过昂贵的硬件堆出来但产品化需要把成本、功耗、可靠性控制到合理范围。芯片厂、电池厂、电机厂、整机厂的协同会决定人形机器人能不能从小批量走向消费级或工业级市场。如果你对人形机器人的运动控制、软件架构、芯片选型感兴趣除了关注比赛结果不妨自己动手跑一个开源仿真环境从控制一个简化双足模型开始逐步理解 ZMP、MPC、强化学习这些概念。只有亲手调过参数看到机器人从摔倒到站稳再从慢走到快跑才能真正理解 45.66 秒这个成绩背后工程师们到底解决了多少问题。