最近圈子里热度最高的消息就是北京人形机器人跑出百米 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(datatorques)) 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( assethumanoid.xml, taskrun, reward{ forward_velocity: 1.0, # 鼓励向前速度 orientation: 0.5, # 防止摔倒 joint_torque: 0.01, # 最小化能耗 feet_air_time: 0.2, # 鼓励腾空 }, domain_randomizationTrue ) agent PPO( policymlp, hidden_dims[512, 256, 128], lr3e-4, num_envs4096 ) agent.train(env, total_timesteps1_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, jsonpayload, timeout2) 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] iteration500, vel3.2m/s, pos12.5m [2025-06-15 10:00:00.124] [JOINT] [WARN] hip_right temp78C, torque_limit85%日志至少应包含时间戳、模块名、级别、关键数值。这种格式便于后续脚本化分析和可视化。11. 最佳实践与使用建议在做人形机器人运动控制项目时以下几点是长期踩坑总结出来的经验。先做仿真再做真机。仿真训练出初步策略真机测试只做验证和微调不要直接在真机上试错。保留一套最小可运行配置。不要等所有模块都完成才联调先跑通站立和慢走再逐步推进到奔跑。每次变换场地或任务先做安全和环境预检。确认地面平坦度、空间大小、周围人员安全。策略版本管理比代码版本管理更重要。算法迭代频繁一定要记录每个策略对应的训练数据和超参数。数据要结构化保存。状态估计、关节指令、IMU 原始数据都要保存否则出了问题无从追溯。涉及人体检测、视觉感知、人群场景时必须考虑隐私合规。摄像头采集数据前应明确用途和保存期限。远程调试接口必须做认证和加密防止未授权访问导致机器人被恶意控制。11.1 仿真转真机的升级路径从简单到复杂推荐这样的演进路径第一阶段站桩平衡。第二阶段慢速行走。第三阶段快速行走测试转弯和斜坡。第四阶段慢速奔跑。第五阶段全力冲刺配合专用赛道测试。每一步都要有通过标准不以“刚好能跑”为完成标准要以“连续跑 N 次不出问题”为准。12. 总结与实际建议这次北京人形机器人百米跑进 10 秒的事件最值得关注的不是“超越博尔特”这个结果而是它背后完整验证了人形机器人在高速动态运动下的机械设计、实时控制、芯片算力和软件架构能力。从产业角度看人形机器人正在从“能走”走向“能跑”下一步的竞争点会集中在三个方向关节硬件高功率密度电机、轻量化结构件、高效散热。运动控制算法强化学习 模型预测控制的深度融合。主控芯片与软件生态国产 SoC 的算力提升和开发工具链完善。如果你正在做人形机器人相关项目或者准备入行最先应该验证的是一套基础的运动控制闭环从关节驱动到状态估计再到策略输出。把这个闭环跑稳了再考虑加视觉、加大模型、做任务调度。最容易踩的坑就是跳过基础步态直接上端到端方案最后发现仿真和真机差距太大策略根本跑不动。这个方向技术更新非常快建议把本文收藏备用后续有新的运动控制算法、芯片方案或开源软件架构我会继续拆解。人形机器人的技术栈会越来越成熟从实验室到产线只是时间问题先把基础打牢。