天工 Omni 在第二届世界人形机器人运动会 400 米小型组决赛中跑出 45.66 秒并夺冠。如果只看这条消息很容易把它归类为一条体育快讯哪家机器人赢了、用时多少、谁排第二。但把 45.66 秒放到人形机器人运动控制的坐标系里看这更像是一次技术极限测试机器人要在几十秒内不断重复“落地、冲击、起飞、腾空、再落地”的动态循环同时保持姿态稳定、轨迹可控、执行器不过热、算法不超时。这篇文章想做的不是复述比赛结果而是拆开这个成绩背后的工程技术问题。我们会讨论“跑”为什么比“走”难、400 米比赛对机器人的软硬件提出了什么要求、一套可用于人形机器人运动控制的软件架构长什么样以及芯片和计算平台在这个场景里到底承担什么职责。最后我会给出几个可以自己在本地跑通的最小技术示例帮助你把抽象的概念落到看得见的代码上。对于人形机器人方向的技术开发者、嵌入式工程师、算法工程师以及准备进入这个行业但不知道从哪开始的人这篇文章应该能帮你建立一张相对清晰的技术地图。1. 为什么 45.66 秒值得被当作技术事件看待先做一个最简单、也最直观的换算400 米赛程用时 45.66 秒平均配速大约是 8.76 米/秒也就是接近 31.5 公里/小时。注意这不代表天工 Omni 全程都在这个速度上匀速跑因为起跑加速、弯道调整、终点冲刺都会让瞬时速度波动。但它说明一个基本事实这台人形机器人在赛道的大部分时间里持续处在一个相当高的移动速度区间。作为对比普通双足行走一般在 1 到 1.5 米/秒慢跑在 2.5 到 4 米/秒。如果一台人形机器人的平均移动速度能做到 8.76 米/秒那它就不只是“走得稳”而是在真正高速动态奔跑。这背后对应的不是某一个算法的改进而是从执行器响应、结构刚度、状态估计、步态规划到实时计算平台的系统级能力。很多人会忽略“小型组”这三个字。从命名习惯来看小型组大概率是按机器人体积或重量划分的组别。这意味着机器人需要在更小的结构体积内实现和大尺寸机型接近甚至更高的爆发力。小型机器人的电机、减速器、电池、计算板都要同时塞进有限的体积里功率密度就成了决定性指标。所以 45.66 秒真正值得关注的不是“谁赢了”而是它证明了人形机器人的运动控制已经跨过一个临界点机器人可以在高速状态下维持动态稳定而不是靠慢速步行来“凑合着走完”。这个临界点一旦过去后续很多应用场景的想象空间会被打开包括复杂地形作业、应急搜救、高速巡检等对移动能力要求更高的任务。## 2. 人形机器人“会跑”和“会走”到底差在哪 要理解 45.66 秒的技术含量先要看懂一个基础问题跑和走对机器人来说不是同一个量级的难题。 行走时机器人绝大多数时间都至少有一只脚在地面重心投影基本可以维持在支撑脚形成的多边形内部。这个条件让控制算法有比较充分的调节空间即使出现扰动机器人也可以通过调整脚掌位置、髋关节力矩来恢复稳定。 奔跑则完全不同。奔跑的步态周期里会出现“腾空阶段”也就是双脚同时离开地面的瞬间。在腾空状态下机器人没有地面反作用力来修正姿态整个身体相当于一个自由飞行的多刚体系统。它只能依靠之前起跳时预留的角动量、躯干和四肢之间的相对运动来保证落地时姿态接近预期。一旦离开地面你就几乎没有机会弥补错误只能等下一次落地触地反馈再纠正。 从控制理论的角度看这个差异可以用 ZMP也就是零力矩点来描述。行走时ZMP 被要求始终落在支撑多边形内奔跑时ZMP 会逼近甚至超出支撑边界系统必须允许动态不稳定用下一步的落地点来“救”回来。换句话说奔跑控制本质上是在处理一个持续处于失稳边缘的平衡问题。 另一个关键差异是冲击力。奔跑时单腿触地瞬间地面反作用力会达到体重的数倍。这个冲击力一方面考验结构刚性另一方面会给关节电机和减速器带来瞬时大扭矩。机器人需要在极短时间内完成“接触检测—力缓冲—姿态修正”这一连串动作而控制回路的频率必须高到足够捕捉冲击峰值。 我们可以用一张表来对比走路和奔跑的核心差异 | 对比维度 | 行走 | 奔跑 | | --- | --- | --- | | 支撑方式 | 至少单脚着地存在双足支撑相 | 存在腾空相双脚同时离地 | | 稳定性判定 | ZMP 保持在支撑多边形内 | 允许 ZMP 接近或超出边界依赖动态步进 | | 冲击载荷 | 相对平缓 | 触地瞬间可达体重的数倍 | | 控制带宽 | 几十到几百赫兹可满足 | 通常需要数百赫兹以上 | | 对执行器要求 | 能提供基本关节力矩即可 | 需要高功率密度、快速响应的力矩输出 | | 系统误差容忍度 | 较低可以边调边走 | 极低单次错误可能直接摔倒 | 奔跑控制本质上是在解决一个“受限动力学优化问题”在有限的执行器力矩、关节速度、结构强度约束下找到一条能保持稳定且速度足够快的最优步态。这已经超出了传统位置控制的范畴必须依赖模型预测控制、强化学习或两者结合的方法。3. 把 400 米比赛拆解到系统层如果你只看冲刺阶段的十几秒会觉得机器人只是“跑得快”。但要把 400 米完整跑完并且保证不摔倒、不出界、不因过热而减速整体系统需要处理的任务要复杂得多。我们可以把 45.66 秒拆成几个阶段来看每个阶段对应的技术难点并不同。起跑加速阶段考验的是力矩控制和步态切换能力。机器人从一开始的站立状态进入奔跑步态需要在极短时间内把身体重心从支撑面后方推进到前方同时让步频迅速上升。如果加速曲率设计得太激进前向速度还没建立起来躯干就可能因为角动量过大而前倾摔倒。这个阶段非常依赖关节力矩前馈和状态估计的准确性。途中跑阶段更像是一个高频稳态控制问题。机器人会按照预规划的步态周期持续前进每次触地都产生近似周期性的冲击。控制算法需要不断修正质心轨迹、躯干姿态和落地位置抵抗外界微小的风阻、地面摩擦差异、传感器噪声等因素。这里真正困难的地方不是“跑一步”而是连续几百步不出现累积误差。弯道阶段则增加了侧向动力学问题。机器人进入弯道后质心必须向弯道内侧倾斜才能产生足够的向心力。这个倾斜角度如果不够机器人会冲向外侧如果过大则会向内侧摔倒。弯道还要求机器人的步宽和步频调整匹配转向半径对整个步态规划器提出了额外的约束。比赛场地里的弯道半径、表面材料都会直接影响最优策略选择。最后冲刺阶段考验的是能量管理和系统鲁棒性。电量、电机温度、关节磨损程度都会在这个阶段开始显现影响。如果电池放电能力不足或电机持续大扭矩导致温度过高机器人会在最后几十米明显减速甚至触发安全保护停机。很多实际比赛中前中段跑得最快的机器人反而在终点前掉链子往往就是这个原因。从系统架构来说400 米比赛对实时性要求极高。赛道环境相对固定感知模块不需要处理太复杂的动态障碍物但状态估计和运动控制必须跑在数百赫兹以上的控制周期里。机器人在奔跑过程中每毫秒的姿态误差都可能被放大成不可恢复的偏差因此系统需要有一个稳定、低延迟、高确定性的实时计算链路。## 4. 人形机器人运动控制的软件架构从感知到实时的闭环 回到工程实现层面。一台人形机器人要高速奔跑软件架构通常不是单一算法能解决的而是一条分层清晰的流水线。不同层级的任务响应时间不同对计算硬件的要求也不同。 最上层是感知和理解层。它负责处理摄像头、激光雷达、深度传感器数据完成环境建图、地形识别、路径规划。这类任务通常计算量大可能运行深度学习模型适合放在高性能 SoC 上执行。在比赛场景里这部分工作相对简单因为赛道是已知的可以提前规划路径感知更多是用于确认前方没有突发障碍物。 第二层是定位和状态估计。机器人要时刻知道自己当前的位置、姿态、速度、角速度以及各关节的关节角、角速度、力矩。这些数据来自 IMU、关节编码器、足底力传感器、视觉里程计。由于每个传感器都存在噪声和漂移工程上通常使用扩展卡尔曼滤波或因子图优化把多源数据融合成高频率、低延迟的状态估计结果。奔跑场景中足底接触检测尤其关键因为机器人需要准确判断“脚已经落地”这个事件的精确时刻。 第三层是决策和步态规划层。根据当前状态和目标速度规划器生成未来若干毫秒到若干秒的质心轨迹、落脚点序列、关节角度目标。这就是 MPC 或者强化学步态策略发挥作用的地方。它需要在执行器力矩约束、关节速度约束、地面摩擦约束下找出一条满足稳定条件的最优轨迹。这一层不需要在微秒级响应但必须足够快以便在每一步触地后根据实际状态重新规划下一步。 第四层是实时运动控制层。它接收规划器输出的目标轨迹通过逆动力学或关节空间控制器计算每个电机的期望力矩。典型的做法是 PD 控制加前馈力矩补偿。这一层必须在数百赫兹甚至上千赫兹的循环中稳定运行通常部署在实时核、MCU 或 FPGA 上避免被操作系统调度抖动影响。 第五层是执行器和安全保护层。电机驱动、电流环控制、编码器采集、温度监控都在这一层。执行器的电流环控制频率通常高达几十千赫兹保证力矩输出准确。安全保护则包括关节角度限位、力矩限幅、碰撞检测、紧急停机。比赛中的突然摔倒或异常大冲击必须能在这层被快速识别并触发保护。 可以把这几层的关系理解为感知负责看清世界状态估计负责知道自己在哪规划负责决定怎么跑实时控制负责把指令变成力矩执行器和安全层负责把力矩变成运动并把风险兜住。比赛成绩只体现最终结果但任何一个中间环节出现延迟或误差都会直接反映在步态质量上。5. 三个贴近实战的最小示例把运动控制逻辑跑起来如果你平时不直接接触大型人形机器人只读概念很难建立直觉。下面用三个最小示例演示运动控制中几个关键逻辑。这些示例不是天工 Omni 的复现而是帮助你理解背后的基本原理。所有代码都可以在本地用 Python 直接运行。5.1 环境准备建议使用 Python 3.9 或以上版本并用虚拟环境隔离依赖。python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate python -m pip install --upgrade pip先安装最基础的 numpy 和 matplotlib用于数值分析和绘图python -m pip install numpy matplotlib如果你想尝试更接近机器人工程的仿真环境后面可以用 PyBullet 或 MuJoCo这里先用无依赖的代码演示核心逻辑。5.2 示例一线性倒立摆步态轨迹人形机器人行走和奔跑规划中一个非常经典的模型是线性倒立摆模型。它把机器人简化成一个位于质心的质点腿部质量忽略不计质心高度固定。这样处理后步行规划问题就变成了一个一维动力学问题。# 文件路径examples/inverted_pendulum.py import numpy as np import matplotlib.pyplot as plt g 9.81 # 重力加速度 z_height 0.9 # 质心高度米教学示例用 dt 0.001 # 仿真步长 sim_time 1.0 # 仿真时长秒 omega np.sqrt(g / z_height) x 0.0 v 0.3 time_list [] x_list [] steps int(sim_time / dt) for i in range(steps): acceleration omega * omega * x v acceleration * dt x v * dt time_list.append(i * dt) x_list.append(x) plt.plot(time_list, x_list) plt.xlabel(time (s)) plt.ylabel(CoM horizontal position (m)) plt.title(Linear Inverted Pendulum Response) plt.grid(True) plt.savefig(inverted_pendulum.png) print(fFinal x {x:.4f} m, Final v {v:.4f} m/s)运行后你会看到质心位置呈现非线性的指数式增长趋势。这看起来和走路无关但它揭示了步行稳定性的本质在没有外力调整的情况下质心会不断偏离支撑点机器人天然是不稳定的。控制器要做的事情就是在质心偏离到一定程度之前提前迈出下一步找到新的支撑点。5.3 示例二单关节 PD 控制器步态规划模型输出的通常是角度轨迹。要让真实电机沿着轨迹运动关节控制器会使用 PD 控制也就是比例加微分控制。这个逻辑虽然简单却几乎存在于所有机器人关节控制中。# 文件路径examples/pd_control.py import numpy as np def pd_step(q, qd, q_des, qd_des, kp, kd, dt, tau_max): # 期望力矩 比例项 微分项 tau kp * (q_des - q) kd * (qd_des - qd) # 力矩限幅避免超过硬件能力 tau np.clip(tau, -tau_max, tau_max) # 简化模型假设单位惯量 qdd tau qd qd qdd * dt q q qd * dt return q, qd, tau # 目标轨迹从 0 到 1 弧度的平滑过渡 q 0.0 qd 0.0 kp 150.0 kd 20.0 dt 0.001 tau_max 50.0 for step in range(1000): q_des 1.0 qd_des 0.0 q, qd, tau pd_step(q, qd, q_des, qd_des, kp, kd, dt, tau_max) if step % 200 0: print(ft{step * dt:.3f}s, q{q:.4f} rad, tau{tau:.4f} Nm)这个例子展示了关节控制的完整链路计算期望力矩、限幅、积分得到速度、再积分得到位置。KD 项的作用是提供阻尼避免关节在目标位置附近震荡。实际机器人中还有前馈力矩、摩擦力补偿、重力补偿等环节但 PD 永远是基础。5.4 示例三ros2_control 控制器配置片段如果进入工程化阶段人形机器人经常会借助 ROS 2 的 ros2_control 组件来管理关节控制器。以下是最小化的控制器管理器配置片段具体字段名称可能随 ros2_control 版本变化实际使用时以你安装的版本为准。# 文件路径config/controllers.yaml controller_manager: ros__parameters: update_rate: 500 joint_state_broadcaster: ros__parameters: type: joint_state_broadcaster/JointStateBroadcaster joint_effort_controller: ros__parameters: type: effort_controllers/JointGroupEffortController joints: - left_hip_pitch - left_knee_pitch - left_ankle_pitch - right_hip_pitch - right_knee_pitch - right_ankle_pitch这个配置把控制周期设置为 500 赫兹并声明了一个关节力矩控制器。发布者把目标关节力矩发布到对应话题控制器就会把力矩指令下发到执行器。真实的人形机器人会有更多关节还会把 IMU 数据、足底力传感器数据接入控制器节点。5.5 运行与验证结果安装依赖后分别运行两个 Python 示例python examples/inverted_pendulum.py python examples/pd_control.py第一个示例会生成一张inverted_pendulum.png图片并打印质心位置和速度。第二个示例会输出各时间步的关节角度和力矩。如果代码正常你会看到关节角度逐步趋近 1.0 弧度同时力矩会被限制在一定范围内。这几个示例虽然简单但已经覆盖了运动控制中的核心思维链建立动力学模型、生成参考轨迹、使用反馈控制器跟踪轨迹、通过限幅和配置保证系统安全。真实比赛中那些漂亮的奔跑动作就是这些基础逻辑在高性能硬件上的极致放大。## 6. 芯片与计算平台跑得快不只是算法问题 算法再先进如果芯片算不过来机器人照样跑不起来。人形机器人高速奔跑时整套软件栈需要处理的数据量非常大但不同任务对计算硬件的要求差异巨大。 感知和规划层需要处理摄像头图像、激光点云可能还要运行深度学习模型进行地形识别和障碍物检测。这类任务适合放在高性能 SoC 上比如集成 GPU 或 NPU 的嵌入式平台。它不需要极低的调度延迟但需要足够高的算力以及良好的功耗控制。 实时运动控制层则完全不同。它要求极高的时间确定性控制器命令必须在固定周期内下发不能因为操作系统进程切换而出现明显抖动。这个任务通常不适合与 Linux 上层应用共享同一个 CPU 核更稳妥的做法是在多核异构平台上做资源隔离把实时控制任务绑定到独立核或者下放到 MCU、DSP、FPGA 上执行。 这里可以引入当前行业里大家关注的一个方向人形机器人芯片赛道。最近很多芯片设计公司开始把“人形机器人芯片”作为重点方向包括搜索热度很高的全志科技等。从产业逻辑看这类产品往往瞄准“边缘智能 实时控制”的复合需求也就是希望用一个平台同时承接感知、决策和关节控制任务。 不过要特别强调天工 Omni 具体使用了谁的芯片并没有在现有信息中明确本文不会做无依据的推断。但可以确定的是芯片和计算平台在人形机器人中确实处于核心位置。要支撑 45.66 秒这种成绩计算平台必须有足够强的实时响应能力同时功耗还不能太高否则电池热量和能耗会成为整机续航的瓶颈。 我们可以用一张表梳理典型任务对计算硬件的要求 | 任务层级 | 典型任务 | 计算特点 | 常用硬件 | | --- | --- | --- | --- | | 感知与决策 | 视觉识别、地形分类、路径规划 | 高算力、并行计算 | 高性能 SoC、GPU、NPU | | 状态估计 | 多传感器融合、接触检测 | 中算力、低延迟 | 通用处理器、MCU | | 实时控制 | 逆动力学、PD 控制、力矩分配 | 高实时性、周期确定 | 实时核、MCU、FPGA | | 电机驱动 | 电流环、编码器采样、安全保护 | 超高频、硬实时 | 专用电机驱动芯片、MCU | 在实际项目中我建议的架构原则是把“会思考的任务”和“会反应的任务”分开。需要大模型推理的放在独立 SoC 上需要毫秒级响应的放在实时硬件上两者之间用具有确定性的通信接口连接。如果一开始就把所有任务塞到同一颗芯片上一旦遇到复杂场景导致 CPU 过载机器人可能连最基本的站立稳定都保证不了。7. 对产业和开发者意味着什么影响分析一场 400 米比赛不会立刻让所有工厂都用上人形机器人但它对外传递了几个明确的产业信号。第一个信号是动态运动控制的工程化水平已经显著提升。过去很长一段时间人形机器人演示主要集中在行走、上下楼梯、搬运物体。这些能力固然重要但移动速度普遍偏慢距离实际作业场景仍有距离。400 米高速奔跑把它往前推了一大步如果连续 45 秒的高速动态运动都能保持稳定那么很多需要在开阔环境下快速移动的任务比如园区巡检、仓库盘点、应急响应就具备了初步的技术可行性。第二个信号是数据飞轮可能开始转动。高速奔跑的难点在于动态条件下的稳定控制而这类控制算法极度依赖真实运动数据。比赛本身就是一场高质量数据采集转弯、加速、冲刺、颠簸、异常扰动都会被传感器记录下来。这些数据可以用来打磨强化学习策略、验证仿真到真实迁移的可靠性也可以用来重新审视机械结构设计的不足。理论上每跑一次比赛研发团队就获得了一批比实验室里“慢速往返”珍贵得多的数据。第三个信号是软件和硬件架构会进一步分层。要控制成本、缩短开发周期厂商会越来越强调模块化架构。感知、规划、控制、执行器各自独立演进芯片厂商也有机会介入更细分的领域。对人形机器人软件架构感兴趣的人现在正是进入的好时机因为整个行业还远没有形成统一的技术标准各家的架构都在快速迭代中。但也要理性看待风险和边界。比赛成绩是在相对理想的环境中取得的赛道平坦、规则明确、没有复杂的动态障碍物也没有长时间连续作业的负载要求。这意味着它能证明机器人的极限运动能力但不能直接说明机器人在真实工业环境中就能稳定工作。真实场景下的地板摩擦系数变化、光照变化、突发人员走动、连续多小时作业都会带来新的挑战。对开发者来说这意味着两条建议第一关注动态运动控制算法尤其是强化学习和模型预测控制相结合的路线第二重视仿真到真实迁移的能力因为高速奔跑场景下纯靠真实机器人反复训练的成本极高仿真将成为算法迭代的主战场。## 8. 常见误区与排查思路 如果你正在做人形机器人运动控制相关开发或者打算复现类似的奔跑实验下面几个问题是高频出现的。它们虽然不是针对天工 Omni 本身但具有一般参考价值。 | 问题现象 | 可能原因 | 排查方式 | 解决方案 | | --- | --- | --- | --- | | 奔跑时质心明显侧偏 | 状态估计延迟过大或足底接触检测不准确 | 检查 IMU 和足底力传感器的时间戳对齐情况 | 引入接触置信度降低传感器融合延迟 | | 关节电机过流报警 | 瞬时力矩超出硬件能力冲击过大 | 录制关节力矩、速度和电流波形定位峰值 | 限制触地速度增加落地缓冲策略加入力矩限幅 | | 仿真中能跑真实机器人不稳定 | 仿真与真实环境差距过大延迟未建模 | 测量控制回路总延迟并记录真实摩擦参数 | 在仿真中加入延迟、摩擦、噪声随机化 | | 系统偶发掉线控制频率不稳定 | 感知任务和实时控制任务抢占 CPU | 检查核资源分配和实时线程优先级 | 将实时控制迁移到独立核或 MCU | | 电池续航太短 | 步态能耗过高电机频繁大扭矩输出 | 分析单位距离对应的能量消耗曲线 | 优化步态能量效率减少不必要的大幅制动 | | 弯道时容易摔倒 | 侧向力规划与转向半径不匹配 | 对比直线和弯道的质心轨迹数据 | 引入前馈侧向加速度调整步宽和躯干倾斜角 | 排查问题时我建议按照“数据、时间、频率”三个关键词来组织。先把所有关键信号录制下来包括关节角度、关节力矩、IMU 数据、触地状态再检查不同传感器数据之间是否存在明显的时间对齐误差最后看控制频率是否满足设计目标。很多时候高速奔跑中的稳定性问题最终都能追溯到某一个具体的时间延迟上而不是单一的算法逻辑问题。 在工程实践中还要特别重视安全设计。高速奔跑的机器人一旦失控冲击力可能损坏设备或伤及周围人员。建议在软件层面设置关节角速度限幅、力矩限幅、机体倾斜角保护在硬件层面预留急停开关和机械缓冲结构。任何新步态算法在真机运行前都先在仿真中做大量的随机扰动测试再慢慢增加真实速度。9. 总结与后续学习方向回到最开始的问题45.66 秒这个成绩到底意味着什么。它首先是一个标志人形机器人不再只是“能走路”的展示品而是可以在持续数十秒的高速动态运动中保持稳定控制的复杂系统。其次它是一面镜子照出了运动控制算法、软件架构、芯片算力、执行器性能之间深度耦合的关系。任何一环掉链子成绩都会立刻反映出来。如果你想在这个方向继续深入我建议按以下路径依次推进第一步先跑通运动控制的基础概念。理解 ZMP、线性倒立摆模型、PD 控制、状态估计这些核心概念并用仿真环境反复实验。不要一上来就追求复现“跑 45.66 秒”那不现实也不利于建立基本直觉。第二步选择一个可用的仿真环境把一条简单的步态控制链路完整跑起来。从单关节控制到双足站立再到慢速行走逐步增加对环境扰动和模型误差的处理。第三步研究模型预测控制和强化学习。奔跑步态的可选参数非常多传统规则性控制很难覆盖所有动态情况。未来更稳妥的路线大概率是模型预测控制提供理论约束强化学习在离线训练中探索最优策略两者结合后部署到实时控制平台上。第四步回到硬件和架构。了解实时操作系统、MCU 与 SoC 的分工、电机驱动与总线协议。运动控制不是纯算法问题一个软件上的实时任务调度错误就足以让一台成本昂贵的机器人在赛场上摔倒。人形机器人的高速运动能力会继续进化。45.66 秒不会是终点它更像是行业给所有开发者发出的一份技术邀请函动态运动控制这扇门已经被推开接下来比赛的是每一个能把算法、架构和硬件真正融合在一起的团队。建议先把这篇文章里提到的最小示例跑一遍再从你手头的实际问题往回推你会发现那些看起来遥不可及的高速跑动技术其实离你并不远。