“38.15s 跑完 400 米再破人类纪录”当这个成绩出现在一场人形机器人运动会上的时候你会发现判断机器人实力的标准已经彻底变了。过去我们谈人形机器人谈的是“能走”“能爬楼梯”“能握手”现在天工 Ultra 直接把这个行业的评价坐标拉到了“能不能跑进 40 秒”。很多开发者看到这条新闻第一反应是“电机好猛”。但如果只停留在硬件层面很容易错过真正重要的事情人形机器人从“走”到“跑”跨越的不只是速度而是一整套运动控制算法、软件架构和芯片算力方案的升级。这篇文章不打算复述赛事过程而是以天工 Ultra 的 400 米夺冠成绩作为切入口拆解三个问题人形机器人跑步为什么这么难难在哪一层天工 Ultra 这类机器人的软件与硬件架构是怎么支撑高速奔跑的如果团队想在仿真环境里复现“质心轨迹规划 落地稳定控制”的最小闭环到底应该怎么做如果你是做机器人算法、嵌入式开发、具身智能应用或者单纯想看明白这条新闻背后的技术逻辑这篇文章应该能给你一个比“跑得快”更完整的答案。1. 这篇文章真正要解决的问题先给一个判断38.15 秒的 400 米成绩是人形机器人运动控制系统工程化的胜利而不是某个单点硬件的胜利。为什么这么说看两个细节。跑步和走路最大的区别在于跑步存在“飞行相”——腾空状态。当机器人的双脚全部离开地面时它没有任何可靠的物理支撑点整个身体处于“自由落体 姿态旋转”的状态。此时控制系统必须在几十毫秒内依据惯性测量单元IMU的角速度、加速度数据以及规划好的质心轨迹推算出下一脚落地的位置、关节角度和期望力矩。也就是说跑得越快留给算法的“反应时间”越短对状态估计的延迟要求越高对关节电机的扭矩密度和带宽要求也越苛刻。任何一个环节出现几十毫秒的延迟机器人就会在触地瞬间失去平衡直接摔倒。所以这篇文章适合这几类读者正在做双腿机器人步态规划的算法工程师想理解走路算法和跑步算法在建模层面的差异做机器人电控底座的嵌入式工程师想搞明白上层运动控制和关节伺服之间到底需要什么样的通信带宽和实时性关注人形机器人行业趋势的开发者想透过赛事新闻看到“大小脑架构”“人形机器人芯片”“运动控制软件栈”这些概念的真实落点。读完这篇文章你会得到一个完整的判断框架以后看到任何一台人形机器人跑得快你都知道要去检查它的状态估计、步态规划、全身控制、执行器四个层面而不是只盯着电机参数。2. 人形机器人跑步为什么这么难从静态稳定到动态稳定2.1 走路可以“一步一步稳”跑步没有“稳”的瞬间传统双足机器人走路主流做法是参考“零力矩点”理论。简单说机器人只要保证地面反作用力的等效作用点始终落在脚底支撑多边形内部就不会翻倒。这是一种准静态稳定思路每一步都尽量把重心控制在双脚构成的范围内所以看起来慢而谨慎。跑步则完全不同。跑步过程中机器人会进入腾空相双脚离地零力矩点理论失效。此时系统必须依赖“动态稳定”也就是在飞行过程中提前规划好质心的运动轨迹和落足点让触地瞬间产生的冲击恰好被关节力矩吸收并转化为下一步的推进动力。用一个类比走钢丝的人手里拿着长杆讲究“随时平衡”但跑酷运动员跳过楼间距讲究“在失控中重新夺回控制权”。跑步机器人本质上是在做后一件事。2.2 四个让跑步变难的现实约束维度行走阶段跑步阶段影响支撑状态至少有一只脚着地存在双脚离地的飞行相稳定判据改变ZMP 理论不够用触地冲击冲击小可近似准静态触地瞬间冲击力可达体重的数倍足部、膝关节结构强度要求高执行器负载关节速度/力矩需求较低需要同时满足高速度、高力矩电机容易进入饱和区控制频率常见 100Hz1kHz 可支撑需要更高带宽时延要求更严对芯片实时性和通信总线提出更高要求2.3 为什么“飞行相”是控制算法的分水岭在走路算法中控制周期内系统状态至少有一个固定的约束脚在地面上。但跑步的飞行相里机体质心只受重力作用运动近似抛体运动。这意味着控制器必须把“预测能力”放在核心位置而不是只做“反馈纠错”。你可以理解为走路时算法像开车看后视镜不断修正方向跑步时算法像赛车手过弯必须在入弯前就规划好线路和刹车点弯中只能靠经验和微调。所以跑步机器人的软件架构一定是一个“预测 反馈 重规划”的闭环系统。小结论人形机器人跑步难不是难在“跑”这个动作本身而是难在“如何在失去稳定支撑的状态下持续重构稳定性”。3. 天工 Ultra 夺冠背后硬件、算法与软件架构的三层配合从公开新闻来看天工 Ultra 在赛事中以 38.15 秒完赛并夺得首金同时刷新了纪录。要支撑这种速度机器人一般需要在三个层面同时做到位。3.1 硬件层高功率密度关节与高速通信跑步对关节电机的要求是“既要力量大又要转速快”也就是高功率密度。传统工业机器人关节电机偏重、偏慢不适合动态奔跑。而人形跑步机器人通常采用定制化的高扭矩密度电机配合轻量化的连杆结构。同时整个机身的传感器布局也很关键足底需要六维力传感器或压力阵列来感知地面反作用力躯干需要高精度 IMU 来测量姿态关节需要编码器来反馈角度和角速度。高速奔跑时这些传感器数据需要以至少 1kHz 的频率汇总到主控芯片延迟越低控制效果越好。3.2 算法层从倒立摆到全身动力学大部分双足机器人的步态规划都离不开“线性倒立摆模型”。走路时机器人被简化为一个质心加一条无质量腿用于计算落脚点。但跑步时线性倒立摆模型无法描述飞行相很多团队会转向“弹簧负载倒立摆”模型或直接使用“全身动力学轨迹优化”。全身动力学控制的核心是同时考虑所有关节的位置、速度、力矩约束以及地面接触约束通过最优化方法求解当前时刻每个关节的目标力矩。工程上这个过程通常表现为一个二次规划问题由运动控制芯片实时求解。3.3 软件架构层大小脑协同这就要说到最近技术圈讨论很多的人形机器人软件架构。过去机器人主控往往是一块高性能工控机所有任务挤在一起。但跑步这类动态任务对实时性要求极高任务拆分势在必行。一个常见的软件架构是大脑层承担感知、导航、任务决策通常运行在带 GPU 的高算力平台上处理视觉、语音、大模型推理等非实时任务小脑层承担状态估计、步态规划、全身控制要求在 1kHz 或更高频率下执行运行在实时控制器上关节伺服层运行在关节电机驱动器内执行位置环、速度环、力矩环通信周期通常以毫秒甚至微秒计。这个分层思想正好对应了“人形机器人芯片”热潮背后的真实需求不是所有算力都要堆在一块芯片上而是要把低延迟的实时控制算力和高吞吐的 AI 推理算力合理分开。对开发者来说这意味着软件工程能力而不是单纯硬件堆料决定了一台机器人的运动上限。小结论天工 Ultra 能跑进 38.15 秒背后一定是一套已经跑通的“高带宽硬件 动力学算法 分层软件架构”组合而不是某一个组件单点突破的结果。4. 奔跑控制的核心算法原理解析4.1 为什么“线性倒立摆”不够用线性倒立摆模型把机器人简化为质心和落脚点它在走路场景下表现良好因为支撑脚始终存在。但跑步的飞行相里质心运动与支撑脚无关必须单独建模。工程上处理跑步模型有两条主流路径弹簧负载倒立摆模型认为腿在着地时可以等效为弹簧通过“压缩-反弹”过程实现弹性储能和释放。这个模型对跑步的触地冲击、腾空高度有较好的解释力。直接轨迹优化用全身动力学模型描述所有关节把步态规划变成一个最优化问题目标函数通常是能耗最小、冲击最小约束条件是关节角度限制、力矩限制、摩擦锥限制。4.2 状态估计机器人怎么知道自己在哪无论采用哪种模型控制器都要知道当前机体的位置、速度和姿态。双足机器人的状态估计通常融合 IMU加速度、角速度、关节编码器正运动学推算足端位置、足底力传感器判断支撑状态和视觉可选。在跑步过程中IMU 的加速度积分会快速漂移所以纯粹积分不可靠。常见做法是用扩展卡尔曼滤波或互补滤波把加速度计和陀螺仪的数据融合起来并利用“触地瞬间速度为零”这个运动学约束来修正漂移。4.3 全身控制把“想跑”变成“关节力矩”规划层输出的是质心轨迹、落脚点位置和躯干姿态轨迹。但这些轨迹必须被转化为每个关节的目标角度、目标角速度和目标力矩。这个过程就是全身控制。常见方案是建立机器人动力学方程采用分层控制上层任务空间控制定义质心加速度、躯干姿态角加速度作为任务下层关节空间求解求解满足所有任务和约束的关节加速度力矩计算利用逆动力学计算关节力矩。在实际代码中最常用的工具是“基于二次规划的全身控制器”。它会告诉每个关节“在满足物理约束的前提下输出多少力矩才能让质心按照规划轨迹运动。”5. 从“走路 Demo”到“跑步 Demo”软件栈怎么改如果团队已经有一个能稳定行走的机器人想向跑步过渡软件栈一般怎么迁移这里给出一个通用的改造思路不绑定具体机器人品牌重点讲清楚每一层需要做什么。5.1 软件栈分层设计层级主要模块典型工具/框架感知与决策层视觉、定位、任务规划ROS 2、PyTorch、大模型接口状态估计层IMU 融合、触地检测EKF、互补滤波步态规划层质心轨迹、落足点规划LIPM/SLIP、轨迹优化库全身控制层力矩求解、接触约束QP 求解器、动力学库关节伺服层位置环/速度环/力矩环MCU、实时总线5.2 仿真环境的必要性做跑步算法强烈建议先在仿真环境里验证再上真机。否则一次摔倒可能就让价值几十万的硬件受损。常用的仿真工具有 MuJoCo、PyBullet、Isaac Gym 等它们都支持刚体动力学和接触仿真能够模拟机器人落地、冲击、翻转。在仿真里你可以先让机器人做“大步快走”逐步增加速度直到出现腾空相然后优化飞行相的轨迹规划。这个过程比直接上真机安全得多。6. 运动控制最小闭环代码实现接下来我们用一个最小示例演示“传感器读取 → 状态估计 → 步态规划 → 关节控制”的闭环结构。代码使用 Python NumPy 编写仿真部分以 MuJoCo 为例。请根据你的实际环境和模型文件调整路径。6.1 示例 1读取仿真传感器数据# 文件路径sensor_read.py # 功能加载 MuJoCo 模型读取机身 IMU 与关节角度数据 import mujoco import mujoco.viewer import numpy as np # 请替换为你的机器人模型文件 model_path your_robot.xml model mujoco.MjModel.from_xml_path(model_path) data mujoco.MjData(model) # 模拟 1000 步每步读取一次传感器 for step in range(1000): mujoco.mj_step(model, data) # 读取躯干 IMU 角速度单位rad/s gyro data.sensordata[0:3] # 读取躯干 IMU 加速度单位m/s^2 accel data.sensordata[3:6] # 读取第 i 个关节的角度单位rad joint_angle data.qpos[7] # 示例索引以实际模型为准 if step % 100 0: print(fstep{step}, gyro{gyro}, accel{accel})这段代码的核心作用是建立“控制循环”的感觉每一次mj_step代表仿真推进一个控制周期控制器必须在这个周期内完成状态读取、计算、输出。6.2 示例 2IMU 互补滤波姿态估计真实机器人中传感器原始数据噪声大且存在漂移不能直接用加速度计反正切求角度也不能直接用陀螺仪积分求角度。互补滤波是工程上常见的轻量方案低频信任加速度计高频信任陀螺仪。# 文件路径complementary_filter.py # 功能一阶互补滤波估计俯仰角Pitch import numpy as np class ComplementaryFilter: def __init__(self, dt0.001, alpha0.98): self.dt dt self.alpha alpha self.pitch 0.0 def update(self, gyro_pitch_rate, accel_pitch): # accel_pitch 由加速度计计算得到atan2(ax, az) # gyro_pitch_rate 是陀螺仪的俯仰角速度 pitch_gyro self.pitch gyro_pitch_rate * self.dt self.pitch self.alpha * pitch_gyro (1 - self.alpha) * accel_pitch return self.pitch # 示例控制周期 1ms, 100Hz 调用 filt ComplementaryFilter(dt0.001, alpha0.98) for step in range(1000): # 这里的数据应来自传感器读取 gyro_pitch_rate 0.01 accel_pitch 0.02 pitch filt.update(gyro_pitch_rate, accel_pitch)这个滤波器虽然简单但在高速奔跑中如果 IMU 数据延迟过大互补滤波的效果会明显下降。这也是为什么很多高端机器人会使用扩展卡尔曼滤波加入足底力触地约束来修正姿态。6.3 示例 3基于 LIPM 的质心轨迹规划线性倒立摆模型可以生成质心运动轨迹用于步态规划。下面这段代码展示如何用数值积分计算期望质心位置和速度。# 文件路径lipm_trajectory.py # 功能使用线性倒立摆模型生成单步质心轨迹 import numpy as np def generate_lipm_trajectory(zc, x_start, x_goal, step_duration, dt0.001): 参数: zc: 质心高度常数 x_start: 起始质心位置 x_goal: 目标质心位置 step_duration: 单步时长 dt: 控制周期 返回: x_traj: 质心位置序列 v_traj: 质心速度序列 g 9.81 w np.sqrt(g / zc) # 倒立摆固有频率 # 计算边界条件对应的倒立摆常数 # 在 LIPM 中质心轨迹是双曲函数组合 # x(t) A * exp(w*t) B * exp(-w*t) A (x_goal - x_start * np.cosh(w * step_duration)) / (np.sinh(w * step_duration)) B x_start - A t np.arange(0, step_duration, dt) x_traj A * np.exp(w * t) B * np.exp(-w * t) v_traj A * w * np.exp(w * t) - B * w * np.exp(-w * t) return x_traj, v_traj # 示例质心高度 0.8m单步跨越 0.3m x, v generate_lipm_trajectory(zc0.8, x_start0.0, x_goal0.3, step_duration0.5) print(第一步质心位置, x[:5]) print(第一步质心速度, v[:5])这里的 LIPM 轨迹只是走路级别的步态。跑步时质心高度会在腾空相产生周期性波动需要在模型中加入竖直方向动力学或者在轨迹生成后增加“质心上升-下降”的修改。6.4 示例 4PD 控制器输出关节力矩规划层给出期望关节角度和角速度后真正的执行层通常使用 PD 控制器计算关节力矩。下面是一个单关节 PD 控制的示例。# 文件路径pd_controller.py # 功能单关节 PD 控制器 class PDController: def __init__(self, kp, kd, torque_limit): self.kp kp self.kd kd self.torque_limit torque_limit def compute(self, q_des, qd_des, q, qd): # q_des: 目标角度, qd_des: 目标角速度 # q: 当前角度, qd: 当前角速度 torque self.kp * (q_des - q) self.kd * (qd_des - qd) # 力矩限幅 torque max(min(torque, self.torque_limit), -self.torque_limit) return torque # 示例膝关节 PD 控制 knee_pd PDController(kp100.0, kd5.0, torque_limit80.0) q_des 0.5 # 期望膝关节角度 qd_des 0.0 # 期望膝关节角速度 q 0.3 # 当前膝关节角度 qd 0.2 # 当前膝关节角速度 tau knee_pd.compute(q_des, qd_des, q, qd) print(膝关节力矩输出, tau)在全身控制中每个关节的 PD 增益不会随意设置而是要根据动力学模型、机器人质量分布和电机特性来整定。跑步过程中落地瞬间的冲击会让 PD 控制器产生很大的力矩尖峰因此力矩限幅是保护执行器的关键。7. 运行结果与效果验证7.1 仿真验证指标跑步算法在仿真中跑通后不能只看“没摔倒”还要对比以下关键指标指标说明合理范围经验值质心高度波动跑步时质心应跟随规划轨迹波动幅度在规划值的 ±5% 以内腾空相时长飞行相在步态周期中的占比随速度提高飞行相占比约 10%~30%落地冲击力矩触地瞬间关节力矩尖峰不应长时间触发力矩限幅能耗单位距离的能量消耗越高说明步态越不经济姿态角误差躯干俯仰/横滚角稳态误差尽量小于 2°7.2 真机验证步骤真机验证不能一上来就跑 400 米。稳妥的顺序是在跑步机上低速快走观察支撑相与飞行相是否出现逐步提高速度让算法自然进入腾空相注意是否出现节奏不稳在平地上进行短距离冲刺测试确认落地阶段的稳定性和姿态恢复能力连续多圈测试检查电机温度、电池电压、结构件是否有疲劳损伤。如果失败第一步应该查看日志中触地瞬间的关节力矩是否饱和以及状态估计是否发散。力矩饱和说明规划轨迹超出了执行器能力需要降低期望速度或优化步态状态估计发散则需要检查 IMU 原始数据和滤波参数。8. 常见问题与排查思路问题现象可能原因排查方式解决方案单腿原地抖振PD 增益过高或控制频率不足查看关节力矩曲线是否高频振荡降低增益提高控制频率腾空时间过长落地冲击大跑步模型参数不匹配质心高度规划偏高对比仿真质心轨迹与理论轨迹重新标定质心高度修正轨迹参数落地时姿态回正慢全身控制器权重配置不当检查姿态任务和质心任务的优先级调高姿态任务权重奔跑速度一直上不去执行器力矩饱和或通信时延过高查看关节力矩是否频繁限幅优化步态频率或升级电机/总线状态估计漂移导致摔倒IMU 漂移或足底力触地检测延迟检查滤波后的姿态角是否平滑引入触地约束优化滤波参数这些问题的共性是出现问题后不要只调控制器参数先要判断是“规划层的问题”还是“执行层的问题”。规划层问题表现为轨迹本身不合理执行层问题表现为轨迹正确但跟踪不上。9. 最佳实践与工程建议9.1 建立“仿真-硬件在环-真机”三级测试流程跑步算法对硬件损伤风险极高必须建立分级测试流程纯仿真快速迭代算法验证步态是否存在理论错误硬件在环把真实控制器和电机驱动器接入仿真环境验证通信和时序是否正常真机低速测试在小范围、有防护措施的环境测试验证实际执行效果。9.2 把日志系统当作第一优先级跑步机器人必须在每个控制周期记录关键数据IMU 原始值、状态估计值、期望关节角度/力矩、实际关节角度/力矩、电机温度、电源电压。数据频率建议不低于 500Hz最好到 1kHz。一次摔倒之后这些日志是定位问题的唯一依据。9.3 重视安全边界真机测试必须设置机械急停和程控急停高速奔跑测试场地应有缓冲护栏和人员隔离区实验前要检查所有关节螺丝、线缆、电池固定情况尊重场地管理规定在授权范围内测试。9.4 关注“芯片 软件架构”的趋势从行业趋势看人形机器人芯片和软件架构正在走向“大小脑分离”大脑处理感知与决策小脑负责运动控制。对开发者而言这意味着把运动控制算法做成可复用、低延迟的模块比绑定一块特定主控板更有长期价值。国产边缘控制芯片在实时性和 AI 加速能力上的进步也会逐渐影响机器人的整体成本结构。10. 写在最后38.15 秒之后该做什么回到天工 Ultra 的 38.15 秒。这个成绩之所以值得被记住不只是因为它“跑得快”而是因为它证明了一件事人形机器人的动态运动控制已经从不稳定的实验室 Demo走向了可以在户外赛道连续奔跑、保持长时间稳定输出的工程系统。对普通开发者来说这个新闻带来的启发不是“我也要造一台跑步机器人”而是要意识到机器人运动控制是一个高度依赖系统工程的领域。传感器、电机、实时芯片、动力学建模、状态估计、步态规划、全身控制每一层都需要扎实的工程积累。如果你现在正打算入局具身智能建议从“让仿真机器人稳定走起来”开始然后逐步加快步频直到触发腾空相再着手处理跑步特有的飞行相规划。先把最小闭环跑通再谈速度这条路虽然慢但足够稳。下一次再看到某台人形机器人刷新纪录时希望你看的不只是成绩而是背后那套正在飞速进化的软件架构和算法栈。 “38.15s 跑完 400 米再破人类纪录”当这个成绩出现在一场人形机器人运动会上的时候你会发现判断机器人实力的标准已经彻底变了。过去我们谈人形机器人谈的是“能走”“能爬楼梯”“能握手”现在天工 Ultra 直接把这个行业的评价坐标拉到了“能不能跑进 40 秒”。很多开发者看到这条新闻第一反应是“电机好猛”。但如果只停留在硬件层面很容易错过真正重要的事情人形机器人从“走”到“跑”跨越的不只是速度而是一整套运动控制算法、软件架构和芯片算力方案的升级。这篇文章不打算复述赛事过程而是以天工 Ultra 的 400 米夺冠成绩作为切入口拆解三个问题人形机器人跑步为什么这么难难在哪一层天工 Ultra 这类机器人的软件与硬件架构是怎么支撑高速奔跑的如果团队想在仿真环境里复现“质心轨迹规划 落地稳定控制”的最小闭环到底应该怎么做如果你是做机器人算法、嵌入式开发、具身智能应用或者单纯想看明白这条新闻背后的技术逻辑这篇文章应该能给你一个比“跑得快”更完整的答案。1. 这篇文章真正要解决的问题先给一个判断38.15 秒的 400 米成绩是人形机器人运动控制系统工程化的胜利而不是某个单点硬件的胜利。为什么这么说看两个细节。跑步和走路最大的区别在于跑步存在“飞行相”——腾空状态。当机器人的双脚全部离开地面时它没有任何可靠的物理支撑点整个身体处于“自由落体 姿态旋转”的状态。此时控制系统必须在几十毫秒内依据惯性测量单元IMU的角速度、加速度数据以及规划好的质心轨迹推算出下一脚落地的位置、关节角度和期望力矩。也就是说跑得越快留给算法的“反应时间”越短对状态估计的延迟要求越高对关节电机的扭矩密度和带宽要求也越苛刻。任何一个环节出现几十毫秒的延迟机器人就会在触地瞬间失去平衡直接摔倒。所以这篇文章适合这几类读者正在做双腿机器人步态规划的算法工程师想理解走路算法和跑步算法在建模层面的差异做机器人电控底座的嵌入式工程师想搞明白上层运动控制和关节伺服之间到底需要什么样的通信带宽和实时性关注人形机器人行业趋势的开发者想透过赛事新闻看到“大小脑架构”“人形机器人芯片”“运动控制软件栈”这些概念的真实落点。读完这篇文章你会得到一个完整的判断框架以后看到任何一台人形机器人跑得快你都知道要去检查它的状态估计、步态规划、全身控制、执行器四个层面而不是只盯着电机参数。2. 人形机器人跑步为什么这么难从静态稳定到动态稳定2.1 走路可以“一步一步稳”跑步没有“稳”的瞬间传统双足机器人走路主流做法是参考“零力矩点”理论。简单说机器人只要保证地面反作用力的等效作用点始终落在脚底支撑多边形内部就不会翻倒。这是一种准静态稳定思路每一步都尽量把重心控制在双脚构成的范围内所以看起来慢而谨慎。跑步则完全不同。跑步过程中机器人会进入腾空相双脚离地零力矩点理论失效。此时系统必须依赖“动态稳定”也就是在飞行过程中提前规划好质心的运动轨迹和落足点让触地瞬间产生的冲击恰好被关节力矩吸收并转化为下一步的推进动力。用一个类比走钢丝的人手里拿着长杆讲究“随时平衡”但跑酷运动员跳过楼间距讲究“在失控中重新夺回控制权”。跑步机器人本质上是在做后一件事。2.2 四个让跑步变难的现实约束维度行走阶段跑步阶段影响支撑状态至少有一只脚着地存在双脚离地的飞行相稳定判据改变ZMP 理论不够用触地冲击冲击小可近似准静态触地瞬间冲击力可达体重的数倍足部、膝关节结构强度要求高执行器负载关节速度/力矩需求较低需要同时满足高速度、高力矩电机容易进入饱和区控制频率常见 100Hz1kHz 可支撑需要更高带宽时延要求更严对芯片实时性和通信总线提出更高要求2.3 为什么“飞行相”是控制算法的分水岭在走路算法中控制周期内系统状态至少有一个固定的约束脚在地面上。但跑步的飞行相里机体质心只受重力作用运动近似抛体运动。这意味着控制器必须把“预测能力”放在核心位置而不是只做“反馈纠错”。你可以理解为走路时算法像开车看后视镜不断修正方向跑步时算法像赛车手过弯必须在入弯前就规划好线路和刹车点弯中只能靠经验和微调。所以跑步机器人的软件架构一定是一个“预测 反馈 重规划”的闭环系统。小结论人形机器人跑步难不是难在“跑”这个动作本身而是难在“如何在失去稳定支撑的状态下持续重构稳定性”。3. 天工 Ultra 夺冠背后硬件、算法与软件架构的三层配合从公开新闻来看天工 Ultra 在赛事中以 38.15 秒完赛并夺得首金同时刷新了纪录。要支撑这种速度机器人一般需要在三个层面同时做到位。3.1 硬件层高功率密度关节与高速通信跑步对关节电机的要求是“既要力量大又要转速快”也就是高功率密度。传统工业机器人关节电机偏重、偏慢不适合动态奔跑。而人形跑步机器人通常采用定制化的高扭矩密度电机配合轻量化的连杆结构。同时整个机身的传感器布局也很关键足底需要六维力传感器或压力阵列来感知地面反作用力躯干需要高精度 IMU 来测量姿态关节需要编码器来反馈角度和角速度。高速奔跑时这些传感器数据需要以至少 1kHz 的频率汇总到主控芯片延迟越低控制效果越好。3.2 算法层从倒立摆到全身动力学大部分双足机器人的步态规划都离不开“线性倒立摆模型”。走路时机器人被简化为一个质心加一条无质量腿用于计算落脚点。但跑步时线性倒立摆模型无法描述飞行相很多团队会转向“弹簧负载倒立摆”模型或直接使用“全身动力学轨迹优化”。全身动力学控制的核心是同时考虑所有关节的位置、速度、力矩约束以及地面接触约束通过最优化方法求解当前时刻每个关节的目标力矩。工程上这个过程通常表现为一个二次规划问题由运动控制芯片实时求解。3.3 软件架构层大小脑协同这就要说到最近技术圈讨论很多的人形机器人软件架构。过去机器人主控往往是一块高性能工控机所有任务挤在一起。但跑步这类动态任务对实时性要求极高任务拆分势在必行。一个常见的软件架构是大脑层承担感知、导航、任务决策通常运行在带 GPU 的高算力平台上处理视觉、语音、大模型推理等非实时任务小脑层承担状态估计、步态规划、全身控制要求在 1kHz 或更高频率下执行运行在实时控制器上关节伺服层运行在关节电机驱动器内执行位置环、速度环、力矩环通信周期通常以毫秒甚至微秒计。这个分层思想正好对应了“人形机器人芯片”热潮背后的真实需求不是所有算力都要堆在一块芯片上而是要把低延迟的实时控制算力和高吞吐的 AI 推理算力合理分开。对开发者来说这意味着软件工程能力而不是单纯硬件堆料决定了一台机器人的运动上限。小结论天工 Ultra 能跑进 38.15 秒背后一定是一套已经跑通的“高带宽硬件 动力学算法 分层软件架构”组合而不是某一个组件单点突破的结果。4. 奔跑控制的核心算法原理解析4.1 为什么“线性倒立摆”不够用线性倒立摆模型把机器人简化为质心和落脚点它在走路场景下表现良好因为支撑脚始终存在。但跑步的飞行相里质心运动与支撑脚无关必须单独建模。工程上处理跑步模型有两条主流路径弹簧负载倒立摆模型认为腿在着地时可以等效为弹簧通过“压缩-反弹”过程实现弹性储能和释放。这个模型对跑步的触地冲击、腾空高度有较好的解释力。直接轨迹优化用全身动力学模型描述所有关节把步态规划变成一个最优化问题目标函数通常是能耗最小、冲击最小约束条件是关节角度限制、力矩限制、摩擦锥限制。4.2 状态估计机器人怎么知道自己在哪无论采用哪种模型控制器都要知道当前机体的位置、速度和姿态。双足机器人的状态估计通常融合 IMU加速度、角速度、关节编码器正运动学推算足端位置、足底力传感器判断支撑状态和视觉可选。在跑步过程中IMU 的加速度积分会快速漂移所以纯粹积分不可靠。常见做法是用扩展卡尔曼滤波或互补滤波把加速度计和陀螺仪的数据融合起来并利用“触地瞬间速度为零”这个运动学约束来修正漂移。4.3 全身控制把“想跑”变成“关节力矩”规划层输出的是质心轨迹、落脚点位置和躯干姿态轨迹。但这些轨迹必须被转化为每个关节的目标角度、目标角速度和目标力矩。这个过程就是全身控制。常见方案是建立机器人动力学方程采用分层控制上层任务空间控制定义质心加速度、躯干姿态角加速度作为任务下层关节空间求解求解满足所有任务和约束的关节加速度力矩计算利用逆动力学计算关节力矩。在实际代码中最常用的工具是“基于二次规划的全身控制器”。它会告诉每个关节“在满足物理约束的前提下输出多少力矩才能让质心按照规划轨迹运动。”5. 从“走路 Demo”到“跑步 Demo”软件栈怎么改如果团队已经有一个能稳定行走的机器人想向跑步过渡软件栈一般怎么迁移这里给出一个通用的改造思路不绑定具体机器人品牌重点讲清楚每一层需要做什么。5.1 软件栈分层设计层级主要模块典型工具/框架感知与决策层视觉、定位、任务规划ROS 2、PyTorch、大模型接口状态估计层IMU 融合、触地检测EKF、互补滤波步态规划层质心轨迹、落足点规划LIPM/SLIP、轨迹优化库全身控制层力矩求解、接触约束QP 求解器、动力学库关节伺服层位置环/速度环/力矩环MCU、实时总线5.2 仿真环境的必要性做跑步算法强烈建议先在仿真环境里验证再上真机。否则一次摔倒可能就让价值几十万的硬件受损。常用的仿真工具有 MuJoCo、PyBullet、Isaac Gym 等它们都支持刚体动力学和接触仿真能够模拟机器人落地、冲击、翻转。在仿真里你可以先让机器人做“大步快走”逐步增加速度直到出现腾空相然后优化飞行相的轨迹规划。这个过程比直接上真机安全得多。6. 运动控制最小闭环代码实现接下来我们用一个最小示例演示“传感器读取 → 状态估计 → 步态规划 → 关节控制”的闭环结构。代码使用 Python NumPy 编写仿真部分以 MuJoCo 为例。请根据你的实际环境和模型文件调整路径。6.1 示例 1读取仿真传感器数据# 文件路径sensor_read.py # 功能加载 MuJoCo 模型读取机身 IMU 与关节角度数据 import mujoco import mujoco.viewer import numpy as np # 请替换为你的机器人模型文件 model_path your_robot.xml model mujoco.MjModel.from_xml_path(model_path) data mujoco.MjData(model) # 模拟 1000 步每步读取一次传感器 for step in range(1000): mujoco.mj_step(model, data) # 读取躯干 IMU 角速度单位rad/s gyro data.sensordata[0:3] # 读取躯干 IMU 加速度单位m/s^2 accel data.sensordata[3:6] # 读取第 i 个关节的角度单位rad joint_angle data.qpos[7] # 示例索引以实际模型为准 if step % 100 0: print(fstep{step}, gyro{gyro}, accel{accel})这段代码的核心作用是建立“控制循环”的感觉每一次mj_step代表仿真推进一个控制周期控制器必须在这个周期内完成状态读取、计算、输出。6.2 示例 2IMU 互补滤波姿态估计真实机器人中传感器原始数据噪声大且存在漂移不能直接用加速度计反正切求角度也不能直接用陀螺仪积分求角度。互补滤波是工程上常见的轻量方案低频信任加速度计高频信任陀螺仪。# 文件路径complementary_filter.py # 功能一阶互补滤波估计俯仰角Pitch import numpy as np class ComplementaryFilter: def __init__(self, dt0.001, alpha0.98): self.dt dt self.alpha alpha self.pitch 0.0 def update(self, gyro_pitch_rate, accel_pitch): # accel_pitch 由加速度计计算得到atan2(ax, az) # gyro_pitch_rate 是陀螺仪的俯仰角速度 pitch_gyro self.pitch gyro_pitch_rate * self.dt self.pitch self.alpha * pitch_gyro (1 - self.alpha) * accel_pitch return self.pitch # 示例控制周期 1ms, 100Hz 调用 filt ComplementaryFilter(dt0.001, alpha0.98) for step in range(1000): # 这里的数据应来自传感器读取 gyro_pitch_rate 0.01 accel_pitch 0.02 pitch filt.update(gyro_pitch_rate, accel_pitch)这个滤波器虽然简单但在高速奔跑中如果 IMU 数据延迟过大互补滤波的效果会明显下降。这也是为什么很多高端机器人会使用扩展卡尔曼滤波加入足底力触地约束来修正姿态。6.3 示例 3基于 LIPM 的质心轨迹规划线性倒立摆模型可以生成质心运动轨迹用于步态规划。下面这段代码展示如何用数值积分计算期望质心位置和速度。# 文件路径lipm_trajectory.py # 功能使用线性倒立摆模型生成单步质心轨迹 import numpy as np def generate_lipm_trajectory(zc, x_start, x_goal, step_duration, dt0.001): 参数: zc: 质心高度常数 x_start: 起始质心位置 x_goal: 目标质心位置 step_duration: 单步时长 dt: 控制周期 返回: x_traj: 质心位置序列 v_traj: 质心速度序列 g 9.81 w np.sqrt(g / zc) # 倒立摆固有频率 # 计算边界条件对应的倒立摆常数 # 在 LIPM 中质心轨迹是双曲函数组合 # x(t) A * exp(w*t) B * exp(-w*t) A (x_goal - x_start * np.cosh(w * step_duration)) / (np.sinh(w * step_duration)) B x_start - A t np.arange(0, step_duration, dt) x_traj A * np.exp(w * t) B * np.exp(-w * t) v_traj A * w * np.exp(w * t) - B * w * np.exp(-w * t) return x_traj, v_traj # 示例质心高度 0.8m单步跨越 0.3m x, v generate_lipm_trajectory(zc0.8, x_start0.0, x_goal0.3, step_duration0.5) print(第一步质心位置, x[:5]) print(第一步质心速度, v[:5])这里的 LIPM 轨迹只是走路级别的步态。跑步时质心高度会在腾空相产生周期性波动需要在模型中加入竖直方向动力学或者在轨迹生成后增加“质心上升-下降”的修改。6.4 示例 4PD 控制器输出关节力矩规划层给出期望关节角度和角速度后真正的执行层通常使用 PD 控制器计算关节力矩。下面是一个单关节 PD 控制的示例。# 文件路径pd_controller.py # 功能单关节 PD 控制器 class PDController: def __init__(self, kp, kd, torque_limit): self.kp kp self.kd kd self.torque_limit torque_limit def compute(self, q_des, qd_des, q, qd): # q_des: 目标角度, qd_des: 目标角速度 # q: 当前角度, qd: 当前角速度 torque self.kp * (q_des - q) self.kd * (qd_des - qd) # 力矩限幅 torque max(min(torque, self.torque_limit), -self.torque_limit) return torque # 示例膝关节 PD 控制 knee_pd PDController(kp100.0, kd5.0, torque_limit80.0) q_des 0.5 # 期望膝关节角度 qd_des 0.0 # 期望膝关节角速度 q 0.3 # 当前膝关节角度 qd 0.2 # 当前膝关节角速度 tau knee_pd.compute(q_des, qd_des, q, qd) print(膝关节力矩输出, tau)在全身控制中每个关节的 PD 增益不会随意设置而是要根据动力学模型、机器人质量分布和电机特性来整定。跑步过程中落地瞬间的冲击会让 PD 控制器产生很大的力矩尖峰因此力矩限幅是保护执行器的关键。7. 运行结果与效果验证7.1 仿真验证指标跑步算法在仿真中跑通后不能只看“没摔倒”还要对比以下关键指标指标说明合理范围经验值质心高度波动跑步时质心应跟随规划轨迹波动幅度在规划值的 ±5% 以内腾空相时长飞行相在步态周期中的占比随速度提高飞行相占比约 10%~30%落地冲击力矩触地瞬间关节力矩尖峰不应长时间触发力矩限幅能耗单位距离的能量消耗越高说明步态越不经济姿态角误差躯干俯仰/横滚角稳态误差尽量小于 2°7.2 真机验证步骤真机验证不能一上来就跑 400 米。稳妥的顺序是在跑步机上低速快走观察支撑相与飞行相是否出现逐步提高速度让算法自然进入腾空相注意是否出现节奏不稳在平地上进行短距离冲刺测试确认落地阶段的稳定性和姿态恢复能力连续多圈测试检查电机温度、电池电压、结构件是否有疲劳损伤。如果失败第一步应该查看日志中触地瞬间的关节力矩是否饱和以及状态估计是否发散。力矩饱和说明规划轨迹超出了执行器能力需要降低期望速度或优化步态状态估计发散则需要检查 IMU 原始数据和滤波参数。8. 常见问题与排查思路问题现象可能原因排查方式解决方案单腿原地抖振PD 增益过高或控制频率不足查看关节力矩曲线是否高频振荡降低增益提高控制频率腾空时间过长落地冲击大跑步模型参数不匹配质心高度规划偏高对比仿真质心轨迹与理论轨迹重新标定质心高度修正轨迹参数落地时姿态回正慢全身控制器权重配置不当检查姿态任务和质心任务的优先级调高姿态任务权重奔跑速度一直上不去执行器力矩饱和或通信时延过高查看关节力矩是否频繁限幅优化步态频率或升级电机/总线状态估计漂移导致摔倒IMU 漂移或足底力触地检测延迟检查滤波后的姿态角是否平滑引入触地约束优化滤波参数这些问题的共性是出现问题后不要只调控制器参数先要判断是“规划层的问题”还是“执行层的问题”。规划层问题表现为轨迹本身不合理执行层问题表现为轨迹正确但跟踪不上。9. 最佳实践与工程建议9.1 建立“仿真-硬件在环-真机”三级测试流程跑步算法对硬件损伤风险极高必须建立分级测试流程纯仿真快速迭代算法验证步态是否存在理论错误硬件在环把真实控制器和电机驱动器接入仿真环境验证通信和时序是否正常真机低速测试在小范围、有防护措施的环境测试验证实际执行效果。9.2 把日志系统当作第一优先级跑步机器人必须在每个控制周期记录关键数据IMU 原始值、状态估计值、期望关节角度/力矩、实际关节角度/力矩、电机温度、电源电压。数据频率建议不低于 500Hz最好到 1kHz。一次摔倒之后这些日志是定位问题的唯一依据。9.3 重视安全边界真机测试必须设置机械急停和程控急停高速奔跑测试场地应有缓冲护栏和人员隔离区实验前要检查所有关节螺丝、线缆、电池固定情况尊重场地管理规定在授权范围内测试。9.4 关注“芯片 软件架构”的趋势从行业趋势看人形机器人芯片和软件架构正在走向“大小脑分离”大脑处理感知与决策小脑负责运动控制。对开发者而言这意味着把运动控制算法做成可复用、低延迟的模块比绑定一块特定主控板更有长期价值。国产边缘控制芯片在实时性和 AI 加速能力上的进步也会逐渐影响机器人的整体成本结构。10. 写在最后38.15 秒之后该做什么回到天工 Ultra 的 38.15 秒。这个成绩之所以值得被记住不只是因为它“跑得快”而是因为它证明了一件事人形机器人的动态运动控制已经从不稳定的实验室 Demo走向了可以在户外赛道连续奔跑、保持长时间稳定输出的工程系统。对普通开发者来说这个新闻带来的启发不是“我也要造一台跑步机器人”而是要意识到机器人运动控制是一个高度依赖系统工程的领域。传感器、电机、实时芯片、动力学建模、状态估计、步态规划、全身控制每一层都需要扎实的工程积累。如果你现在正打算入局具身智能建议从“让仿真机器人稳定走起来”开始然后逐步加快步频直到触发腾空相再着手处理跑步特有的飞行相规划。先把最小闭环跑通再谈速度这条路虽然慢但足够稳。下一次再看到某台人形机器人刷新纪录时希望你看的不只是成绩而是背后那套正在飞速进化的软件架构和算法栈。 
