最近圈子里热度最高的消息，就是北京人形机器人跑出百米 9.39 秒这件事。如果按公开报道中的说法，这个成绩比博尔特的世界纪录还快，而且是在人形双足构型下跑出来的。先不争论这个成绩是否满足传统田径规则，单看它能稳定跑完百米、具备高速奔跑能力，就足以说明人形机器人的运动控制、硬件结构和软件架构已经到了一个全新的阶段。
这篇文章不追热点，而是把这个事件拆开来看：要让一台双足机器人跑进 10 秒，需要什么样的电机和关节、什么样的控制算法、什么样的芯片算力，以及什么样的软件架构。同时结合“全志科技 人形机器人芯片”这类行业动态，梳理一下目前人形机器人从仿真训练到真机部署的完整技术链路。
文章适合三类读者：做人形机器人本体和运动控制的工程师，正在选型主控芯片和实时系统的嵌入式开发者，以及想了解人形机器人技术栈但不知道从哪里入手的算法同学。
1. 核心能力速览
从公开信息看，这次成绩背后的人形机器人，核心能力可以概括为几个维度：
| 能力项 | 说明 |
|---|---|
| 运动形态 | 双足人形，直立奔跑，非轮式或四足构型 |
| 极限速度 | 公开报道称百米 9.39 秒，需以原始发布信息为准 |
| 技术关键 | 腿部关节输出能力、动态步态规划、高带宽力控 |
| 算力需求 | 需要实时运动控制算力 + 感知决策算力，通常采用异构方案 |
| 软件架构 | 感知、规划、控制分层，或采用端到端强化学习策略 |
| 芯片方案 | 行业常见做法：主控 SoC + 实时 MCU + GPU/NPU 加速模块 |
| 启动方式 | 冷启动需要先初始化关节、加载控制策略、再进入待机 |
| 接口能力 | 通常提供 ROS 2 接口、SDK、日志和远程监控接口 |
| 安全边界 | 必须配置急停、力矩限制、速度限制、物理围栏 |
这里要说明一点：9.39 秒这个成绩来自新闻报道，具体测量方式、风速条件、赛道认证没有完整公开。技术文章更值得关注的是，它背后验证了哪些工程能力。
2. 从奔跑成绩反推：人形机器人的关键工程维度
一台人形机器人能跑多快，不是某一个部件的功劳，而是机械、电气、算法、软件共同作用的结果。
2.1 关节电机与减速器
跑步和走路最大的区别在于冲击力。走路时，每一步触地时地面反作用力大约是体重的 1 到 1.5 倍；跑步时，这个数值会冲到体重的 3 到 5 倍。也就是说，如果机器人重量是 50 公斤，跑动时单腿承受的瞬间冲击力可能达到 150 到 250 公斤力。
这就对关节电机提出了很直接的要求：
- 峰值扭矩要足够大，尤其是髋关节和膝关节。
- 扭矩密度要高，否则电机会很重，机器人总重量压不住。
- 响应速度要快，力控带宽不够，机器人会“软脚”。
- 散热要跟上，大功率输出下绕组温度会快速上升。
目前主流方案是高密度无框力矩电机 + 谐波减速器或行星减速器，配合高分辨率编码器做力闭环。跑得快不快，先看腿部关节的峰值扭矩和带宽够不够。
2.2 动态步态规划
双足跑步和双足行走本质上是两种不同的运动模式。行走时，机器人始终有至少一只脚在地面，可以看作“倒立摆”的连续支撑过程。跑步时，存在腾空相，也就是双脚都离地的阶段，机器人会短暂处于弹道运动状态。
控制算法上，常用的是：
- 线性倒立摆模型（LIPM）做质心轨迹规划。
- 模型预测控制（MPC）做落脚点规划。
- 全身动力学控制（WBC）做关节力矩分配。
- 强化学习（RL）训练隐式策略，直接输出关节动作。
一个简化的跑步控制循环大致是：
每个控制周期（通常 1kHz）： 1. 读取IMU、关节编码器、足底力传感器 2. 估计当前质心位置、速度、姿态角 3. 根据目标速度计算落脚点 4. 用MPC求解最优质心轨迹 5. 用WBC把质心加速度映射到关节力矩 6. 发送力矩指令到关节电机整个循环要在 1 毫秒内完成，对算力和通信延迟的要求很高。
2.3 状态估计
机器人跑起来的时候，机身震动剧烈，IMU 数据噪声很大，足底力传感器频繁冲击。这个时候状态估计如果不稳，控制策略再强也跑不起来。
常用做法是：
- IMU + 关节编码器做运动学推算。
- 扩展卡尔曼滤波（EKF）或无迹卡尔曼滤波（UKF）融合数据。
- 足底力传感器做零速修正。
- 视觉或激光雷达做外部定位，但高速奔跑时视觉帧率容易成为瓶颈。
3. 芯片与算力：人形机器人需要什么样的“大脑”
这次热点中提到了“全志科技 人形机器人芯片”，说明国产芯片厂商已经开始针对人形机器人做专用方案。
人形机器人对算力的需求是分层的，不是一颗芯片解决所有问题。
3.1 主控芯片（应用处理器）
负责感知、决策、导航、人机交互，类似机器人的“大脑皮层”。要求：
- 多核 CPU，支持 Linux 或 Android。
- 内置或外接 NPU，用于目标检测、语义分割、视觉语言模型。
- 丰富的外设接口，包括 USB、以太网、PCIe、CAN。
常见方案有 NVIDIA Jetson 系列、地平线旭日系列、全志科技 T 系列或新一代机器人专用芯片。
3.2 实时控制芯片（MCU/DSP）
负责关节控制、力控、电流环、急停逻辑，要求：
- 硬实时，控制周期稳定在 1kHz 甚至更高。
- 多路 CAN 或 EtherCAT 接口。
- 低延迟中断响应。
通常每个关节使用一颗 MCU 做底层电机控制，整机再有一颗高性能 MCU 做运动学正逆解和控制策略下发。
3.3 异构计算架构
现在业界主流不是用一颗芯片包打天下，而是采用异构方案：
感知与决策层（高算力 SoC） ↓ 高频指令 实时控制层（实时 MCU/FPGA） ↓ 关节指令 执行层（关节电机 + 驱动器）某些强化学习方案会把神经网络推理直接放到控制板上，用 GPU/NPU 跑策略网络，输出关节目标位置或力矩。
3.4 全志科技芯片方向的判断
从行业公开动向看，全志科技这类国产 SoC 厂商切入人形机器人，瞄准的是主控芯片和端侧 AI 推理场景。优势在于成本、供货稳定性、国内生态支持和系统集成度。劣势在于高性能计算、GPU 生态和工具链成熟度，与 NVIDIA 的方案还有差距。
选型建议是：
- 纯运动控制、不需要复杂感知，实时 MCU + 低功耗 SoC 就够。
- 需要视觉导航 + 大模型交互，必须上高算力 SoC + NPU。
- 量产场景更看重成本和供应，国产 SoC 会越来越有竞争力。
- 科研和原型验证阶段，NVIDIA 生态还是最省事的方案。
4. 人形机器人软件架构：从感知到关节的完整链路
之前提到过“全志科技 人形机器人芯片”，这里就顺着芯片的话题深入到软件架构层面。因为芯片只是硬件底座，真正决定机器人能不能跑起来的是上层软件架构。
4.1 分层架构
一个成熟的人形机器人软件架构通常分为五层：
| 层级 | 功能 | 典型组件 |
|---|---|---|
| 感知层 | 环境感知、人体检测、地形识别 | 摄像头、激光雷达、IMU、足底力传感器 |
| 决策层 | 任务规划、路径规划、行为决策 | 状态机、行为树、LLM/VLM |
| 规划层 | 步态规划、落脚点规划、轨迹生成 | MPC、WBC、RL 策略 |
| 控制层 | 关节力矩计算、底层驱动 | 关节控制器、EtherCAT 主站 |
| 执行层 | 电机驱动、制动、急停 | 关节电机、刹车、安全电路 |
4.2 通信框架
现代人形机器人普遍使用 ROS 2 作为中间件。原因很直接：
- 分布式节点天然适合异构计算架构。
- DDS 通信支持实时性配置。
- 传感器、控制、导航都有现成生态。
一个典型的 ROS 2 节点结构可以这样建模：
# 人形机器人控制节点伪代码 import rclpy from rclpy.node import Node from sensor_msgs.msg import JointState from std_msgs.msg import Float64MultiArray class HumanoidController(Node): def __init__(self): super().__init__('humanoid_controller') self.state_sub = self.create_subscription( JointState, '/joint_states', self.state_callback, 10 ) self.cmd_pub = self.create_publisher( Float64MultiArray, '/joint_torque_commands', 10 ) def state_callback(self, msg): # 读取关节角度、速度，运行控制策略 torques = self.compute_torques(msg) self.cmd_pub.publish(Float64MultiArray(data=torques)) def compute_torques(self, joint_state): # 这里替换为 MPC/WBC/RL 策略 return [0.0] * len(joint_state.position) def main(): rclpy.init() node = HumanoidController() rclpy.spin(node) rclpy.shutdown()4.3 实时性设计
人形机器人跑步时，关节控制周期至少要 1kHz，也就是 1 毫秒一次。这个要求下，ROS 2 的标准 DDS 通道无法直接满足控制闭环，需要把实时控制放到独立线程或独立 MCU 上。
工程上常见做法是：
- 控制循环跑在 RT 线程，使用
sched_setscheduler设置实时优先级。 - 关节指令走共享内存或 EtherCAT，不走网络协议栈。
- ROS 2 只负责上层监控和低速消息。
高优先级实时线程（1kHz）： IMU读取 -> 状态估计 -> MPC求解 -> 力矩下发 低优先级非实时线程（10-50Hz）: 视觉处理 -> 导航规划 -> 行为决策 -> 日志记录5. 从仿真训练到真机部署流程
现在人形机器人的运动能力，尤其是奔跑这类动态动作，基本都是先在仿真环境里训练，再迁移到真机。为什么？因为真机试错成本太高，摔一次可能就是几万块的维修费。
5.1 仿真环境选择
常用的人形机器人仿真环境包括：
- MuJoCo：物理引擎轻量，适合强化学习训练。
- Isaac Gym / Isaac Lab：支持 GPU 并行，能同时跑成千上万个环境。
- Gazebo：适合 ROS 集成和传感器仿真。
- 自研物理引擎：部分大厂会基于 Bullet、PhysX 二次开发。
5.2 域随机化
仿真和真机之间永远存在差距。为了让策略在真机上也能跑，训练时要做域随机化：
- 随机化电机扭矩输出系数。
- 随机化摩擦系数、质心位置、关节阻尼。
- 随机化传感器噪声和控制延迟。
- 随机化地面摩擦力和弹性。
5.3 强化学习训练
一个基于强化学习的奔跑策略训练，核心步骤可以简化为：
# 强化学习策略训练配置示例（伪代码） env = HumanoidRunEnv( asset="humanoid.xml", task="run", reward={ "forward_velocity": 1.0, # 鼓励向前速度 "orientation": 0.5, # 防止摔倒 "joint_torque": 0.01, # 最小化能耗 "feet_air_time": 0.2, # 鼓励腾空 }, domain_randomization=True ) agent = PPO( policy="mlp", hidden_dims=[512, 256, 128], lr=3e-4, num_envs=4096 ) agent.train(env, total_timesteps=1_000_000_000)训练完成后，导出为 ONNX 或 TensorRT 格式，部署到机器人主控上，用 NPU 或 GPU 推理。
5.4 真机迁移与安全
仿真到真机的迁移不是直接加载模型就能跑，需要一套严格的流程：
- 在仿真中全面测试边界条件，包括极端扰动和地形。
- 使用仿真转真机工具验证策略输出是否符合电机物理极限。
- 真机测试先做“悬挂测试”，让机器人悬空验证关节动作方向。
- 首次行走使用保护索或减重装置。
- 逐步放开速度上限，从 0.5m/s 慢慢加到目标速度。
- 全程开启急停和力矩限制。
6. 环境准备与前置条件
如果你在实验室或公司想复现类似的高速奔跑能力，前期需要准备这些条件。
6.1 硬件环境
- 一台高性能工作站，建议 NVIDIA GPU（用于仿真训练）。
- 人形机器人本体：包含 6 到 12 个腿部关节、IMU、足底力传感器。
- 关节电机驱动套件：支持力矩控制模式。
- 实时通信设备：EtherCAT 主站或 CAN 转 USB 适配器。
6.2 软件环境
# 通用环境准备示例，按实际项目调整 sudo apt update && sudo apt install -y \ build-essential \ cmake \ git \ python3-pip \ python3-venv # ROS 2 安装（按机器人 SDK 要求选择版本） # Ubuntu 22.04 对应 ROS 2 Humble # Python 依赖 pip install numpy scipy torch mujoco pip install ruffus # 任务流管理，按需使用6.3 磁盘与性能要求
人形机器人项目会消耗大量磁盘空间：
- 仿真环境和 SDK 约 10 到 30 GB。
- 训练数据集和日志可持续增长到数百 GB。
- 渲染缓存、模型 checkpoint 也占用空间。
磁盘建议至少预留 256 GB，如果要做大规模仿真训练，建议 1TB NVMe SSD。
7. 功能测试与效果验证
从软件角度看，测试一个奔跑策略是否有效，不只是看它能否跑完一百米。下面是一套可用于评估的测试维度。
7.1 平衡保持测试
- 测试目的：验证静止和慢走状态下的稳定性。
- 操作方式：让机器人站立 30 秒，施加外部推力扰动。
- 预期结果：机器人能恢复站立，不跌倒。
- 判断标准：施加 20N 水平力后，质心偏移在 5cm 以内。
7.2 速度梯度测试
- 测试目的：验证从慢走到奔跑的速度平滑过渡。
- 操作方式：设定目标速度从 0.5m/s 逐步加到 3m/s 再到 6m/s。
- 预期结果：速度切换时无明显卡顿和摔倒。
- 判断标准：每一步的触地时间差异小于 20%。
7.3 连续奔跑耐久测试
- 测试目的：验证电机散热和策略稳定性。
- 操作方式：连续奔跑 5 分钟，记录关节温度。
- 预期结果：关节温度在安全范围内。
- 失败原因：电机过热、策略漂移、电池电压下降导致力矩不足。
7.4 输入输出接口测试
人形机器人通常需要通过远程接口控制。一个简化示例：
import requests # 远程下发速度指令 url = "http://192.168.1.100:8080/cmd_vel" payload = { "linear_x": 3.0, "angular_z": 0.0 } response = requests.post(url, json=payload, timeout=2) print(response.json())8. 接口 API 与数据采集
实际工程中，人形机器人很少只靠遥控器操作，通常需要向外部系统提供接口服务。
8.1 常见接口类型
| 接口类型 | 用途 | 协议 |
|---|---|---|
| 运动控制接口 | 下发速度、步态、动作 | ROS 2 / gRPC / HTTP |
| 状态查询接口 | 读取关节角度、温度、电压 | MQTT / WebSocket |
| 遥操作接口 | 人工介入操作 | WebRTC / UDP |
| 日志接口 | 导出调试数据 | 文件系统 / 云存储 |
8.2 批量任务场景
人形机器人在工业巡检、物流搬运等场景需要批量执行任务。这种情况下，建议把任务队列放在上位机：
{ "task_queue": [ { "task_id": "TASK-001", "type": "walk_to", "target_position": [10.0, 2.0, 0.0], "speed": 1.5 }, { "task_id": "TASK-002", "type": "grab_object", "object_id": "box_001", "approach": "front" } ], "retry_policy": { "max_retries": 3, "retry_interval_ms": 1000 } }这里的核心原则是每一条任务都能独立追踪状态，失败能重试，不会阻塞整条队列。
9. 资源占用与性能观察
人形机器人项目在测试时，最需要关注的是三个指标：控制延迟、算力占用、功耗。
9.1 控制延迟
控制延迟是端到端指标，从传感器数据采集到关节力矩输出，理想情况下要小于 1 毫秒。如果超过 2 到 3 毫秒，高速奔跑时机器人很容易出现抖动或摔倒。
排查顺序：
- 先看关节驱动器的电流环频率。
- 再看通信总线带宽和周期。
- 最后看主控的实时调度是否被打断。
9.2 算力占用
当机器人在奔跑时，机载主控的计算负载和平时完全不一样。高速运动时，状态估计和控制策略需要更高的计算频率，视觉感知也会消耗大量算力。
可以用top、htop或专用 profiling 工具观察 CPU 占用。需要注意进程优先级和 CPU 核心绑定，实时控制线程不能被后台日志、模型推理抢占。
9.3 功耗和散热
奔跑是功耗最高的运动模式。以 50 公斤级人形机器人为例，奔跑时峰值功耗可能达到 1kW 以上。这个功耗会直接转化为关节发热，所以散热设计非常关键。
观察重点：
- 关节电机温度。
- 电机驱动器温度。
- 电池压降。
- 主控芯片温度。
如果关节温度持续超过额定值，策略性能会快速下降，甚至触发保护性断电。
10. 常见问题与排查方法
人形机器人项目踩坑概率很高，很多问题不是某一个模块出错，而是多个因素叠加。下面是一张常用的排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 机器人站立时频繁抖动 | 关节力矩增益过高或控制周期不稳定 | 查看关节力矩指令是否振荡 | 降低增益，检查控制线程实时性 |
| 奔跑时容易摔倒 | 落脚点规划滞后或状态估计漂移 | 对比质心估计值和实际值 | 增加状态估计的测量输入，降低速度目标 |
| 电机过热保护 | 关节持续大扭矩输出 | 查看关节温度日志 | 增大散热面积，限制单次奔跑时长 |
| 关节响应延迟 | 通信周期过大或总线拥塞 | 抓包分析 EtherCAT/CAN 报文 | 缩短控制周期，减少总线节点 |
| 仿真中效果很好真机不行 | 仿真和真机参数差距过大 | 检查关节延迟、力矩系数、摩擦系数 | 增加域随机化范围和噪声模型 |
| 主控 CPU 占用率过高 | 后台进程抢占实时线程 | 使用htop查看进程占用 | 绑定 CPU 核心，设置实时优先级 |
| 电池电压快速下降 | 峰值功耗过大 | 记录奔跑时电压曲线 | 增加电池容量，限制加速度 |
10.1 模块日志规范
日志是排查问题的第一手段。建议从项目一开始就统一日志格式：
# 日志输出示例 [2025-06-15 10:00:00.123] [CONTROL] [INFO] iteration=500, vel=3.2m/s, pos=12.5m [2025-06-15 10:00:00.124] [JOINT] [WARN] hip_right temp=78C, torque_limit=85%日志至少应包含：时间戳、模块名、级别、关键数值。这种格式便于后续脚本化分析和可视化。
11. 最佳实践与使用建议
在做人形机器人运动控制项目时，以下几点是长期踩坑总结出来的经验。
- 先做仿真，再做真机。仿真训练出初步策略，真机测试只做验证和微调，不要直接在真机上试错。
- 保留一套最小可运行配置。不要等所有模块都完成才联调，先跑通站立和慢走，再逐步推进到奔跑。
- 每次变换场地或任务，先做安全和环境预检。确认地面平坦度、空间大小、周围人员安全。
- 策略版本管理比代码版本管理更重要。算法迭代频繁，一定要记录每个策略对应的训练数据和超参数。
- 数据要结构化保存。状态估计、关节指令、IMU 原始数据都要保存，否则出了问题无从追溯。
- 涉及人体检测、视觉感知、人群场景时，必须考虑隐私合规。摄像头采集数据前应明确用途和保存期限。
- 远程调试接口必须做认证和加密，防止未授权访问导致机器人被恶意控制。
11.1 仿真转真机的升级路径
从简单到复杂推荐这样的演进路径：
- 第一阶段：站桩平衡。
- 第二阶段：慢速行走。
- 第三阶段：快速行走，测试转弯和斜坡。
- 第四阶段：慢速奔跑。
- 第五阶段：全力冲刺，配合专用赛道测试。
每一步都要有通过标准，不以“刚好能跑”为完成标准，要以“连续跑 N 次不出问题”为准。
12. 总结与实际建议
这次北京人形机器人百米跑进 10 秒的事件，最值得关注的不是“超越博尔特”这个结果，而是它背后完整验证了人形机器人在高速动态运动下的机械设计、实时控制、芯片算力和软件架构能力。从产业角度看，人形机器人正在从“能走”走向“能跑”，下一步的竞争点会集中在三个方向：
- 关节硬件：高功率密度电机、轻量化结构件、高效散热。
- 运动控制算法：强化学习 + 模型预测控制的深度融合。
- 主控芯片与软件生态：国产 SoC 的算力提升和开发工具链完善。
如果你正在做人形机器人相关项目，或者准备入行，最先应该验证的是一套基础的运动控制闭环：从关节驱动到状态估计，再到策略输出。把这个闭环跑稳了，再考虑加视觉、加大模型、做任务调度。最容易踩的坑就是跳过基础步态，直接上端到端方案，最后发现仿真和真机差距太大，策略根本跑不动。
这个方向技术更新非常快，建议把本文收藏备用，后续有新的运动控制算法、芯片方案或开源软件架构，我会继续拆解。
人形机器人的技术栈会越来越成熟，从实验室到产线只是时间问题，先把基础打牢。
