人形机器人跑步比赛最近很受关注。第二届世界人形机器人运动会 400 米小型组决赛里天工 Omni 以 45.66 秒夺冠。这个成绩单独看是一个数字放进比赛场景里就是在说三件事它把 400 米的连续弯道跑下来了没有在中途摔倒并且全程速度分配比较稳。很多人看这类比赛第一反应是看谁跑得快做机器人控制的人看的是另一套东西——每一步的落点有没有偏差、关节在高速摆动下有没有过热、电池电压下降后步态有没有变形。下面按实际落地顺序拆一遍先讲比赛考什么再讲背后的控制、硬件和软件架构最后给出一套可以复现和排查的方法。如果你正在准备同类比赛或者在做双足机器人的步态控制这篇应该能帮你少走一些弯路。1. 先看懂这场比赛为什么 400 米比 100 米更适合检验稳定性1.1 400 米考验的不是瞬时爆发而是连续稳定100 米项目往往更吸引观众因为起跑快、爆发力强、几秒钟就出结果。但从机器人运动控制的角度看100 米的偶然性很大起跑那几步只要撑住后面几乎可以靠开环大步冲完。即使中途有一点步态偏差也可能靠快速调整救回来。400 米不一样它是一段带弯道的连续奔跑。弯道会让机器人内外侧腿的步长不一致身体需要持续侧向倾斜这对步态规划的要求比直道高很多。而且 400 米不是匀速跑完那么简单。机器人在前 100 米和后 100 米的状态会有明显差别电池电压会下降关节电机温度会升高足底缓冲材料的特性会变化。到后半程还能保持前半程的步态质量比单纯提高峰值速度难得多。所以这类比赛真正比较的不是谁的单步爆发力更强而是谁能在连续跑动中把误差控制住。天工 Omni 45.66 秒这个成绩背后一定有“连续稳定”这套体系撑着而不只是某一个关节特别快。1.2 小型组难在步幅短、步频高、容错低小型组机器人通常整机尺寸更小、重量更轻。块头小听起来更灵活实际上问题更多。腿短意味着步幅有限想跑完 400 米就必须提高步频。步频一旦提上去每一步的落地时间窗口就被压缩控制器必须在更短的时间里完成触地检测、重心调整和下一步规划。同时小型机器人的腿部惯量小受到地面扰动后反应更快但这也意味着它没有太多时间去修正。一个大机器人跨一步可能 50 厘米小机器人跨一步可能只有 10 到 20 厘米同样的横向偏差对于大机器人可能只占步幅的一小部分对于小机器人却可能直接引发绊倒。小型组看起来“可爱”实际容错率非常低。这也是为什么很多小型双足机器人能在平地上走得很顺一上弯道就暴露问题。1.3 名次之外真正值得记录的是“能不能跑完”比赛直播里最紧张的是冲线瞬间但做技术复盘的人更该关注“完成率”。一组机器人里哪个先摔倒、哪个中途降速、哪个全程没有掉状态这些信息比名次本身更有价值。按这类比赛的通用判读标准通常会有几个关键判断维度是否在规定的赛道内完成全程是否借助了外部遥控或人为干预是否在中途发生摔倒后重新起步以及最终成绩是否稳定可重复。单次跑出好成绩说明上限不错连续多次都能跑完说明系统具备鲁棒性。如果你只看单次夺冠视频很容易低估背后试错和调试的工作量如果你把这些维度列出来就会发现 400 米项目本质上是一场面向“可靠性”的测试。注意不同赛事的“小型组”划分方式不一样有的按整机高度有的按重量还有的按足底到髋关节的高度。以具体比赛规程为准不要拿一个组别的规则直接套到另一个组别。2. 天工 Omni 夺冠背后的四个技术环节2.1 硬件本体关节输出和结构刚性先要撑住跑步对机器人硬件的冲击比走路大很多。每一步落地都会有冲击力关节电机既要快速响应位置指令又要承受反向冲击。如果结构刚度不够机器人跑起来会出现肉眼可见的晃动量控制器再准也很难稳住。所以这类机器人本体通常会在几个位置重点设计髋关节承担侧向平衡膝关节提供推进力踝关节负责落地缓冲和姿态微调。关节编码器、足底压力传感器和 IMU 的安装位置也很关键。IMU 装得越靠近质心测出来的角速度和加速度越能反映机器人整体姿态足底压力传感器要能区分脚跟、脚掌不同区域的受力这样控制器才能判断支撑状态。硬件设计不一定要堆最好的材料但一定要保证信号链路稳定。实际调试中很多“控制器发疯”其实是编码器线缆松动、传感器供电噪声偏大导致的。2.2 实时控制每一步都在“倒下之前把脚接住”双足跑步的控制本质是不断失去平衡、再不断找回平衡。跑步和走路最大的区别在于存在腾空相两条腿都会离开地面机器人处于完全不受支撑的状态。这个阶段控制器不能靠地面反作用力修正姿态只能提前把脚摆到预期的落点等待触地后再快速吸收冲击。常见的人形机器人控制循环频率在 500Hz 到 1000Hz 之间具体数值取决于控制器算力、总线带宽和执行机构响应速度。频率越高控制延迟越小但 CPU 占用和通信负载也会上升。实跑时不会只用一套固定的步态参数而是根据状态机切换站立、启动、加速、匀速、转弯、减速、停止、摔倒。每一步都要判断当前处于支撑相还是腾空相再选择不同的控制策略。2.3 感知与自适应弯道和地面扰动不能只靠离线脚本有些人以为机器人跑步就是播放一段预设动作。平地直线跑可以这样做但 400 米赛道有弯道地面摩擦可能不一致甚至会有轻微坡度或接缝。只用离线脚本一旦出现偏差机器人就会越跑越偏。感知层的核心任务有三个知道自己当前姿态、知道脚什么时候触地、知道机器人相对赛道的位置。IMU 提供姿态估计足底压力判断支撑状态外部视觉或预设路径信息用来修正前进方向。实际比赛中不一定需要很强的视觉因为赛道环境相对固定但方向纠偏必须存在。如果机器人跑成一条弧线误差会随时间累积最后直接跑出赛道。天工 Omni 这类机器人跑 400 米能稳定冲线说明它的感知层已经能把姿态估计、触地检测和方向修正放进同一条控制回路里。这个链路只要有一个环节延迟过高表现就会迅速劣化。2.4 软件架构状态机、控制频率和任务调度机器人跑步的软件架构通常分两层实时控制层和上层决策层。实时控制层跑在 RTOS 或带有实时补丁的系统上负责关节指令、IMU 读取、足底压力采集和控制律计算上层决策层负责状态切换、路径规划、故障诊断和日志记录。两层之间的通信不能使用容易被阻塞的机制常见做法是共享内存、双缓冲或低延迟消息队列。状态机一定要把异常状态覆盖全尤其是“摔倒检测”和“启动失败恢复”。如果机器人已经摔倒控制器还在持续输出大步态指令轻则电机堵转重则损坏关节或减速器。更稳妥的设计是任何状态机在转移到跑步状态之前都要确认当前姿态接近预期、足底压力信号正常、关节角度没有超限。3. 小型组的软硬件取舍不能照搬大人形机器人的方案3.1 为什么不能只做“等比缩小”大人形机器人验证过的步态算法直接搬到小型机器人上往往跑不通。原因不是算法错了而是动力学比例变了。腿短之后同样的质心偏移百分比对应的绝对偏移更小但步态周期也更短控制系统必须在更短时间内完成同样的调整动作。关节减速比、电机惯量、连杆质量分布都要重新匹配。小型机器人的优势是重量轻、冲击小不会像大机器人那样一旦摔倒就造成严重硬件损坏。劣势是负载能力有限能搭载的传感器和算力板选择更少。设计时不能只看“能不能动”还要看“整机重量是否都花在了必须的地方”。如果电池、线缆和结构件占掉太多重量实际可用负载就会很紧张。3.2 电机、减速器和驱动器的匹配跑步机器人对关节电机的要求是质量轻、响应快、峰值力矩够用。但这三者往往互相矛盾。电机扭矩越大通常体积和重量也越大减速比越高输出力矩越大但高速奔跑时关节转速可能跟不上。实际选型不是选一个“最强电机”而是选一个在目标步频和步幅下刚好有余量的组合。驱动器部分要关注电流环响应速度和通讯方式。跑步时关节电流会快速变化如果驱动器电流环带宽不够力矩输出会滞后。常见做法是用 CAN、EtherCAT 等实时总线连接各关节并统一时间基准。调试时可以先记录原地踏步的电流曲线看看是否有明显尖峰如果峰值电流经常接近驱动器的保护阈值说明电机选型余量不够或者步态参数太激进。3.3 电池、重量与续航的平衡小型组机器人能带的电池容量有限但 400 米比赛需要持续输出较高功率。锂电池的放电能力、电压平台和内阻都会影响末端表现。刚充满电时电压高电机响应快电量下降后相同的电流指令对应的实际功率会变化机器人步幅可能变小甚至出现“跑着跑着越来越没劲”的现象。一种常见的做法是设置电压阈值低于阈值就降低速度指令而不是让扭矩控制器继续按满功率输出。这样虽然成绩变慢但至少能稳定跑完。比跑到一半突然失电强得多。比赛前还要做一次完整的放电测试记录从满电到阈值电压大概能跑多少步提前规划是否需要降速保稳。3.4 芯片和算力部署要紧贴实时控制小型机器人对算力很敏感。计算板太重会影响质心功耗太高会挤压电池容量发热太大会在小尺寸机身里很难散热。所以小型组通常不会只依赖一块高算力主板而是把实时控制放在 MCU 上把上层感知和决策放在应用处理器上。很多人搜“全志科技 人形机器人芯片”这类词是想找一块适合做人形机器人主控的芯片。具体型号和参数以官方发布为准这里更值得说清的是原则芯片选型不能只看算力跑分还要看实时性、外设接口、功耗和生态。跑步控制里最怕的不是算力不够而是中断延迟不确定、通信接口不稳定、工具链难调试。稳定比峰值性能重要。4. 芯片热词背后人形机器人需要什么样的计算架构4.1 芯片在人形机器人里到底负责什么人形机器人不是只有一块“大脑”。它内部通常有多级计算单元各自处理不同实时性要求的任务。最低层是关节驱动器内部的控制器负责电流环和位置环往上是一块 MCU 或实时处理器负责整机控制律、状态机和触地检测再往上才是运行 Linux 或 RTOS 的应用处理器负责视觉、路径规划和用户交互。跑步动作的绝大部分控制计算发生在 MCU 这一层因为它是硬实时任务。如果每个控制周期都稳定在 1ms步态规划就算复杂一点也能保证平滑如果偶尔被刷日志或网络操作卡成 3ms机器人立刻会感觉到“腿发飘”。所以芯片架构里要严格区分实时任务和非实时任务不能把所有事情都塞进同一个大循环。4.2 实时控制芯片、应用处理器和 AI 加速器的分工不同芯片对应不同任务不能互相替代。实时控制芯片重点是运行控制律要求中断响应快、时序稳定应用处理器重点是跑感知算法和任务调度要求接口丰富、生态成熟AI 加速器则更多用于视觉识别、强化学习推理这类高密度计算。在跑步场景里AI 加速器不一定是最关键的。如果比赛场地固定、光照稳定视觉任务不会太重。反而是实时控制芯片的稳定性和关节总线的同步性更重要。如果某个方案把所有计算都压在一块高功耗芯片上不仅散热困难实时性也很难保证。像全志科技这类厂商开始把人形机器人作为一个独立场景来投入说明行业正在从“先攒算法、后找硬件”转向“算法和硬件一起定”。对开发者来说这是好事因为可用 SoC 和外设方案会越来越多。但落到自己项目里时仍然要先跑一个最小控制循环确认中断延迟、总线丢包率、通信频率都符合要求再往上加功能。4.3 软件架构如何把芯片能力变成实际跑动芯片只是底子真正把能力发挥出来的是软件架构。一个跑步机器人至少要分这几个线程传感器采集线程、状态估计线程、步态规划线程、控制输出线程、安全监控线程。传感器采集频率可以很高但状态估计和控制输出必须保证同步。日志记录不能阻塞控制线程最好单独用一个低优先级任务写磁盘。实际中我一般会先画一张数据流图从 IMU 读数开始到姿态估计再到步态规划最后到关节指令。每一步延迟多少毫秒、缓存在哪里、如果数据超时怎么办都要写清楚。这样做不是追求完美架构而是为了出现问题时有据可查。很多机器人跑崩之后只留下一句“当时感觉控制失效了”其实就是因为日志没有记录时间戳无法判断是哪一层先出错。注意给机器人加 AI 功能之前先把基本的状态机跑稳。一个会摔倒的机器人加再强的视觉模型也救不回来。5. 普通人怎么复现和验证从仿真到单腿平衡5.1 先在仿真环境里跑通步态周期如果你没有完整的人形机器人硬件也可以从仿真开始。MuJoCo、PyBullet、Isaac Lab 这类工具都支持导入机器人模型和设置地面摩擦。仿真阶段主要解决三件事确认步态参数能产生周期性动作确认模型不会因为初始条件不合理而直接飞出确认传感器数据的频率和噪声水平可接受。仿真参数和实体参数不会完全一致尤其是地面接触、电机力矩响应和电池电压跌落这些环节。但仿真能帮你快速试错。比如同一个步幅在不同步频下的表现如何质心高度调高或调低会对稳定性产生什么影响。先用仿真缩小参数范围再上实体验证能省很多时间。5.2 再在实体上做四个递进实验实体实验不要一上来就跑 400 米。我一般会拆成四个阶段单腿站立或双脚原地站立确认姿态估计和控制闭环能稳住。原地踏步确认腿可以按指定步频抬起和落下关节没有异响。直线行走确认每一步落点偏差在可接受范围内没有明显偏航。带弯道跑步确认内外侧腿步长差异和侧向倾斜控制有效。每个阶段都要记录指标不要凭感觉“看起来还行”就进入下一阶段。如果你发现直线上机器人总是往左偏不要急着加大 PID 增益先检查左右腿的关节零位是否正确、足底压力传感器是否标定一致。很多偏航问题不是算法问题而是机械装配误差。5.3 记录哪些指标如何判断是否进步跑步实验需要记录的关键指标包括全程用时、摔倒次数、最大连续步数、平均步频、左右脚步距偏差、躯干俯仰角范围、电池电压变化、关节最高温度。其中摔倒次数和最大连续步数是最直观的稳定性指标左右脚步距偏差能反映步态对称性电池电压曲线能反映系统能耗效率。下面的参数表只作为入门参考实际要根据机器人尺寸、重量和电机选型调整参数常见起点范围影响步态周期0.3s 到 0.6s越短步频越高对执行器要求越高步幅5cm 到 20cm影响速度也影响落地稳定性迈步高度2cm 到 6cm太低容易绊倒太高浪费能量质心目标高度站立高度的 70% 到 90%影响整体姿态和关节负载控制频率500Hz 到 1000Hz越高延迟越小但负载越大判断有没有进步不能只看“今天跑得快了一点”。要看同样的输入条件下机器人是否连续三次都能跑完。如果一次成功、一次摔倒说明系统还不稳定这时候去调速度参数没有意义。6. 比赛跑崩时优先排查这几条链路6.1 现象不同排查入口不同机器人跑崩的原因很多先看现象再定方向。如果是一启动就倒优先怀疑初始姿态、状态机切换和足底压力信号如果是跑着跑着突然向一侧偏优先怀疑 IMU 数据、弯道步态参数和传动机构如果是后半程速度明显下降优先怀疑电池电压、电机温度和功率限制如果是关节抖动优先怀疑控制频率、通讯丢包和机械共振。最怕的是不做现象分类直接去调步态参数。调参之前至少要搞清楚问题是每次都出现还是偶尔出现是固定在某一段赛道出现还是全赛道随机出现。每次都出现大概率是系统性问题偶尔随机出现大概率是传感器噪声、接触状态或者外部扰动。6.2 最容易被忽略的几类问题第一类是线缆问题。机器人跑步时关节反复运动线缆会跟着弯曲如果存在内部断芯就会出现“静止时一切正常跑起来偶尔报错”的状态。排查时可以用示波器或日志观察编码器信号看有没有瞬间跳变。第二类是电压问题。小机身电池容量有限跑动时电压跌落很快。如果控制器和关节驱动器共用一路电源关节大电流会导致主控电压波动轻则传感器数据异常重则系统重启。更稳的做法是分路供电或者在软件里做电压补偿。第三类是热问题。小机器人的关节电机没有足够散热空间连续跑 30 秒后温度可能明显上升。温度升高后电机输出力矩下降编码器信号也可能漂移。跑之前先做空载连续旋转测试记录温度升到保护阈值的速度。6.3 一套通用排查顺序我这里给一套偏保守的排查流程先看日志时间戳是否有长时间中断或控制周期抖动。再看电池电压曲线是否在某个时间点出现明显跌落。然后看关节电流和温度是否接近驱动器保护阈值。接着看足底压力传感器是否每个脚掌的信号都正常有没有固定偏移。再看 IMU 原始数据是否有异常尖峰或持续漂移。最后才看步态参数确认是不是速度或步幅设置得太激进。这套顺序的核心逻辑是先排除“信号和供电有硬伤”再排查“执行机构到达极限”最后才怀疑算法参数。很多人一遇到跑崩就改步态增益结果把机器人越调越别扭。真正的问题可能只是电压不够或者一根线松了。7. 从 45.66 秒看人形机器人运动控制的真实边界7.1 成绩背后的“成功率”比单次成绩更关键45.66 秒是一个让人印象深刻的数字。不过技术价值不能只看单次成绩还要看成功率。一个机器人完成 100 次尝试只有 1 次跑完单次成绩再快也不适合实际比赛另一个机器人成绩稍慢但 10 次里有 8 次稳定跑完后者的工程价值更高。比赛直播只会把成功的那一次放出来技术团队真正要盯的是失败率分布。此外不同组别的赛道条件、计时规则、机器人尺寸和判罚标准不完全一样跨组别比较绝对时间没有太大意义。更值得关注的是在连续转弯、电池衰减、电机升温这些叠加条件下机器人还能不能维持步态稳定性。天工 Omni 这次夺冠最大的增量可能不在“快”而在“完整地把全程跑完了”。7.2 当前技术容易卡在哪几个地方人形机器人跑步的瓶颈主要有三个关节力矩密度不够电池能量密度不够实时控制算法对不确定性的适应能力有限。关节力矩密度决定机器人能不能以高步频输出足够的推进力电池能量密度决定后半程会不会掉速算法适应能力决定弯道、摩擦变化和轻微地形扰动会不会引发摔倒。这三个瓶颈会互相放大。关节太重电池就要多背续航就变差算法不够鲁棒为了安全就只能降低速度成绩就上不去。所以短期内的比赛成绩提升不一定是单点突破更多是整体工程优化的结果。真正要跨过“实验室跑一圈”到“比赛稳定冲线”的坎靠的是反复的可靠性测试。7.3 后续更值得关注的方向下一步值得关注的方向有三个一是更高效率的关节电机和减速器方案让机器人在相同电池容量下跑得更久二是融合强化学习和传统控制律的步态框架让机器人能更快适应未知扰动三是更成熟的芯片和软件架构把实时控制、感知和决策放到功耗更低的平台上。对普通开发者来说不一定能马上做出像天工 Omni 这样的整机平台但可以先从仿真步态、单腿平衡和小型双足验证板开始。把人形机器人“为什么能跑”“为什么跑崩”“怎么跑得更稳”这三个问题搞清楚比追逐一个峰值速度更有价值。回到开头那句话45.66 秒只是一个结果。真正让人形机器人从“会跑”走到“稳定地跑完比赛”的是每一次摔倒后的日志分析是每一个参数的谨慎调整是硬件、控制、感知和软件架构不断对齐的过程。如果只留一条调试经验我会把“先让机器人稳定跑完全程”放在“跑得更快”前面。这个顺序反了后面很多参数都会失真。