企业官网建设流程全解析

人形机器人跑步比赛最近很受关注。第二届世界人形机器人运动会 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 米。我一般会拆成四个阶段：

1. 单腿站立或双脚原地站立，确认姿态估计和控制闭环能稳住。
2. 原地踏步，确认腿可以按指定步频抬起和落下，关节没有异响。
3. 直线行走，确认每一步落点偏差在可接受范围内，没有明显偏航。
4. 带弯道跑步，确认内外侧腿步长差异和侧向倾斜控制有效。

每个阶段都要记录指标，不要凭感觉“看起来还行”就进入下一阶段。如果你发现直线上机器人总是往左偏，不要急着加大 PID 增益，先检查左右腿的关节零位是否正确、足底压力传感器是否标定一致。很多偏航问题不是算法问题，而是机械装配误差。

5.3 记录哪些指标，如何判断是否进步

跑步实验需要记录的关键指标包括：全程用时、摔倒次数、最大连续步数、平均步频、左右脚步距偏差、躯干俯仰角范围、电池电压变化、关节最高温度。其中摔倒次数和最大连续步数是最直观的稳定性指标，左右脚步距偏差能反映步态对称性，电池电压曲线能反映系统能耗效率。

下面的参数表只作为入门参考，实际要根据机器人尺寸、重量和电机选型调整：

判断有没有进步，不能只看“今天跑得快了一点”。要看同样的输入条件下，机器人是否连续三次都能跑完。如果一次成功、一次摔倒，说明系统还不稳定，这时候去调速度参数没有意义。

6. 比赛跑崩时，优先排查这几条链路

6.1 现象不同，排查入口不同

机器人跑崩的原因很多，先看现象再定方向。如果是一启动就倒，优先怀疑初始姿态、状态机切换和足底压力信号；如果是跑着跑着突然向一侧偏，优先怀疑 IMU 数据、弯道步态参数和传动机构；如果是后半程速度明显下降，优先怀疑电池电压、电机温度和功率限制；如果是关节抖动，优先怀疑控制频率、通讯丢包和机械共振。

最怕的是不做现象分类，直接去调步态参数。调参之前至少要搞清楚：问题是每次都出现，还是偶尔出现；是固定在某一段赛道出现，还是全赛道随机出现。每次都出现，大概率是系统性问题；偶尔随机出现，大概率是传感器噪声、接触状态或者外部扰动。

6.2 最容易被忽略的几类问题

第一类是线缆问题。机器人跑步时关节反复运动，线缆会跟着弯曲，如果存在内部断芯，就会出现“静止时一切正常，跑起来偶尔报错”的状态。排查时可以用示波器或日志观察编码器信号，看有没有瞬间跳变。

第二类是电压问题。小机身电池容量有限，跑动时电压跌落很快。如果控制器和关节驱动器共用一路电源，关节大电流会导致主控电压波动，轻则传感器数据异常，重则系统重启。更稳的做法是分路供电，或者在软件里做电压补偿。

第三类是热问题。小机器人的关节电机没有足够散热空间，连续跑 30 秒后温度可能明显上升。温度升高后，电机输出力矩下降，编码器信号也可能漂移。跑之前先做空载连续旋转测试，记录温度升到保护阈值的速度。

6.3 一套通用排查顺序

我这里给一套偏保守的排查流程：

1. 先看日志时间戳，是否有长时间中断或控制周期抖动。
2. 再看电池电压曲线，是否在某个时间点出现明显跌落。
3. 然后看关节电流和温度，是否接近驱动器保护阈值。
4. 接着看足底压力传感器，是否每个脚掌的信号都正常，有没有固定偏移。
5. 再看 IMU 原始数据，是否有异常尖峰或持续漂移。
6. 最后才看步态参数，确认是不是速度或步幅设置得太激进。

这套顺序的核心逻辑是：先排除“信号和供电有硬伤”，再排查“执行机构到达极限”，最后才怀疑算法参数。很多人一遇到跑崩就改步态增益，结果把机器人越调越别扭。真正的问题可能只是电压不够或者一根线松了。

7. 从 45.66 秒看人形机器人运动控制的真实边界

7.1 成绩背后的“成功率”比单次成绩更关键

45.66 秒是一个让人印象深刻的数字。不过，技术价值不能只看单次成绩，还要看成功率。一个机器人完成 100 次尝试，只有 1 次跑完，单次成绩再快也不适合实际比赛；另一个机器人成绩稍慢，但 10 次里有 8 次稳定跑完，后者的工程价值更高。比赛直播只会把成功的那一次放出来，技术团队真正要盯的是失败率分布。

此外，不同组别的赛道条件、计时规则、机器人尺寸和判罚标准不完全一样，跨组别比较绝对时间没有太大意义。更值得关注的是：在连续转弯、电池衰减、电机升温这些叠加条件下，机器人还能不能维持步态稳定性。天工 Omni 这次夺冠，最大的增量可能不在“快”，而在“完整地把全程跑完了”。

7.2 当前技术容易卡在哪几个地方

人形机器人跑步的瓶颈主要有三个：关节力矩密度不够，电池能量密度不够，实时控制算法对不确定性的适应能力有限。关节力矩密度决定机器人能不能以高步频输出足够的推进力；电池能量密度决定后半程会不会掉速；算法适应能力决定弯道、摩擦变化和轻微地形扰动会不会引发摔倒。

这三个瓶颈会互相放大。关节太重，电池就要多背，续航就变差；算法不够鲁棒，为了安全就只能降低速度，成绩就上不去。所以短期内的比赛成绩提升，不一定是单点突破，更多是整体工程优化的结果。真正要跨过“实验室跑一圈”到“比赛稳定冲线”的坎，靠的是反复的可靠性测试。

7.3 后续更值得关注的方向

下一步值得关注的方向有三个：一是更高效率的关节电机和减速器方案，让机器人在相同电池容量下跑得更久；二是融合强化学习和传统控制律的步态框架，让机器人能更快适应未知扰动；三是更成熟的芯片和软件架构，把实时控制、感知和决策放到功耗更低的平台上。

对普通开发者来说，不一定能马上做出像天工 Omni 这样的整机平台，但可以先从仿真步态、单腿平衡和小型双足验证板开始。把人形机器人“为什么能跑”“为什么跑崩”“怎么跑得更稳”这三个问题搞清楚，比追逐一个峰值速度更有价值。

回到开头那句话：45.66 秒只是一个结果。真正让人形机器人从“会跑”走到“稳定地跑完比赛”的，是每一次摔倒后的日志分析，是每一个参数的谨慎调整，是硬件、控制、感知和软件架构不断对齐的过程。如果只留一条调试经验，我会把“先让机器人稳定跑完全程”放在“跑得更快”前面。这个顺序反了，后面很多参数都会失真。