人形机器人热度最近频繁进入技术社区视野。无论是双足行走、灵巧手操作还是大模型驱动的具身智能真正决定一台人形机器人能不能从演示视频走向稳定运行的关键往往不是某一个算法的突破而是整套软件架构和主控算力平台能否把感知、决策、控制串成一条低延迟、可调试、可升级的闭环。对开发者来说关注“人形机器人软件架构”和“主控芯片选型”比单纯追一个演示效果更有工程价值。本文围绕人形机器人主控 SoC 与软件架构展开先讲清楚系统分层再给出可落地的最小控制链路示例、工程化要点和排查路径适合准备进入机器人开发、或者正在做机器人主控方案评估的嵌入式与软件工程师阅读。1. 人形机器人不能只靠“一个算法跑起来”先理解系统分层1.1 人形机器人与普通设备的本质差异人形机器人通常有十几个到几十个关节自由度双足行走要求在毫秒级时间内完成姿态判断和关节力矩调整灵巧手操作又要兼顾力控制和位置控制。它既不是普通 MCU 设备那样的简单传感器循环也不是纯云端大模型能单独完成的推理任务。真正的问题是不同模块对实时性的要求完全不同对算力的需求也完全不同如果所有逻辑都堆在一个进程里系统很快就无法维护。实际项目中人形机器人至少要同时处理三类任务关节电机控制和传感器读取通常要求控制周期在 1ms 到 10ms 级别。状态估计、运动规划、安全判断通常要求 10ms 到 100ms 级别。视觉感知、语言理解、复杂决策通常是 100ms 到秒级算力需求高但实时性相对宽松。这三类任务混在一起运行就会出现“电机控制被视觉推理卡住”的经典问题。软件架构的核心目标就是把不同实时性、不同算力需求的任务隔离到合适的层级和合适的硬件上。1.2 机器人软件的五层参考模型参考业界常见的机器人系统设计可以按下面五层来理解层级职责典型模块实时性要求执行层驱动关节电机、读取编码器电机驱动、FOC、PID1ms 级感知层采集并处理传感器数据摄像头、IMU、激光雷达、力传感器10ms 级状态与决策层估算位姿、规划运动、做任务决策状态机、行为树、运动规划器10ms 到 100ms 级认知层大模型推理、视觉语言理解VLM、VLA、目标识别100ms 到秒级人机交互层远程遥控、语音、显示遥控协议、语音交互秒级或异步每一层之间通过明确接口通信而不是互相直接调用内部函数。这样才能在替换感知算法时不影响底层控制在升级大模型时不需要重写电机驱动。很多新手把机器人软件理解成“一个主循环里调一堆函数”实际上工程化的人形机器人软件更像一个“消息驱动的分布式系统”只是它运行在有限算力的嵌入式平台上。1.3 从 ROS 到 ROS 2为什么机器人中间件在变化提到机器人软件架构绕不开 ROS。ROS 1 的设计目标是科研场景的快速原型验证主节点roscore负责所有节点通信一旦主节点崩溃整个系统不可用节点间通过 TCP 通信在复杂网络和实时场景下表现有限。ROS 2 针对这些问题做了几项关键变化使用 DDS 作为底层通信中间件节点间可以点对点发现和通信不再依赖中心节点。引入 QoS 策略可以配置消息传输的可靠性、历史和优先级适应不同控制场景。支持生命周期节点节点可以显式管理配置、激活、关闭状态适合机器人启动和故障恢复。实时性更好在 Linux 配合 PREEMPT_RT 内核时可以支撑更严格的控制周期。对人形机器人来说ROS 2 的价值不只是通信而是它建立了“节点、话题、服务、动作”的软件组织方式让不同团队可以并行开发不同模块再通过标准接口集成。注意ROS 2 不是万能的。电机层的 FOC 电流环、关节位置环仍然要放在支持硬实时的 MCU 或 RTOS 里不能指望 Linux 上的 ROS 2 节点去做 1kHz 的电流控制。2. 主控芯片与人形机器人的算力分工2.1 机器人主控到底要承担哪些计算人形机器人的“大脑”不是一颗芯片而是一组芯片协同工作。芯片选型的第一步是分清每一颗芯片承担什么任务。MCU 负责关节电机控制和关键传感器采集。典型代表是 STM32 系列、GD32 系列、ESP32 等。它们跑 RTOS 或裸机控制周期可以做到 1ms保证电机环路稳定。应用处理器 SoC 负责跑 Linux、ROS 2、运动规划、状态估计和外设管理。常见的是 ARM 架构的嵌入式 SoC这类芯片需要有足够的 CPU 性能、丰富的外设接口和完整的 BSP 支持。AI 加速单元负责视觉推理、大模型驱动。可以是 SoC 内置的 NPU也可以是独立的 GPU、NPU 模块。如果人形机器人只做远程遥控和简单运动一颗中高端 SoC 就够了。但一旦加了视觉感知、语言交互、自主规划就要考虑异构算力协同。把视觉大模型推理放在 NPU 上、把运动规划放在 CPU 上、把电机控制放在 MCU 上是目前比较常见的设计。2.2 多芯片协同MCU、SoC 与 NPU 的分工边界在真实产品里这种分工表现为明确的通信拓扑。IMU / 编码器 / 电机 | MCU关节控制 | CAN / UART / SPI SoCLinux ROS 2 | 以太网 / USB / MIPI-CSI NPU / GPUAI 推理MCU 采集到的关节角度、电流、力矩数据通过 CAN 或 UART 上报给 SoCSoC 上的 ROS 2 节点把这些数据融合成机器人的状态估计决策层生成目标轨迹后再把关节目标角度或力矩指令下发给 MCU。AI 推理结果作为高层意图输入不直接指挥电机而是先经过规划器转化为平滑轨迹。这样做的原因很直接AI 推理延迟不稳定如果让大模型直接输出关节角度并下发到电机机器人会抖动甚至摔倒。安全攸关的运动指令必须经过确定性的控制链路。2.3 面向人形机器人的 SoC 选型参考维度在社区讨论中全志科技这类国产 SoC 进入人形机器人主控视野并不是偶然。全志在平板、智能硬件、边缘设备上有大量成熟方案芯片的 CPU 性能、视频输入接口、NPU 算力和量产供货能力都比较成熟对机器人创业团队来说选型成本低、BSP 资料完整、供应链风险小是评估嵌入式主控时值得考虑的厂商。不过选型不能只看品牌建议从以下维度做对比表选型维度关注点错误选择的表现CPU 性能是否满足 Linux ROS 2 运行启动慢、规划卡顿NPU 算力是否能跑视觉模型推理延迟高、掉帧外设接口CAN、UART、SPI、MIPI-CSI、以太网是否足够需要大量扩展板卡BSP 与内核支持是否有长期维护的内核和驱动外设驱动要自己移植供电与功耗是否适合电池供电发热严重、续航短供货与生态是否有量产案例、文档是否完整拿不到样片、资料不全需要注意许多 SoC 的 NPU 只支持特定框架和算子落地前要确认目标模型能否转换。如果主要跑 VLA 双足控制这类大模型单靠中端 SoC 的 NPU 可能不够需要配合边缘 GPU 或云侧推理。3. 人形机器人软件架构的核心模块怎么设计3.1 按功能域拆分模块而不是按文件拆一个可维护的人形机器人软件仓库通常按功能域拆成独立包而不是把所有代码塞进一个“main.py”。建议的模块划分如下sensor_drivers摄像头、IMU、激光雷达、力传感器、编码器驱动。perception目标检测、语义分割、点云处理、人体识别。state_estimationIMU 与编码器融合、里程计、双足落地状态判断。planning全身运动规划、步态规划、避障、关节轨迹生成。control关节位置/力矩控制、全身动力学控制、接触力控制。safety急停检测、关节限位、力矩超限保护、摔倒检测。teleop遥控手柄、手机 App、视觉遥操作指令接入。system生命周期管理、日志、参数服务、看门狗。每个模块以 ROS 2 节点的形式独立运行使用话题和动作进行通信。比如perception输出目标位姿planning订阅这个位姿生成关节轨迹control订阅关节轨迹并转换为电机指令。这样任何一层都可以单独调试和替换。3.2 数据通路要考虑“回环”而非“流水线”很多人在设计软件时会把机器人流程理解成单向流水线传感器数据进、电机指令出。实际上人形机器人系统的关键是有大量回环。内环电流环和速度环在 MCU 内完成控制频率最高。中环姿态环和关节位置环在控制节点完成使用 IMU 和编码器反馈。外环任务规划和目标跟踪在规划节点完成反馈来自感知和状态估计。数据要从“单向传递”改成“带反馈的闭环”设计。比如行走控制不仅要吃目标速度还要实时吃落地状态、IMU 姿态和关节力矩才能处理路面不平、外力推搡等情况。3.3 状态管理与故障恢复防止机器人变成“失控的钢铁”人形机器人最怕的是一旦某个节点出错电机会输出错误指令。软件架构必须包含状态机和安全管理。机器人状态机至少要包含INIT上电自检、关节回零、传感器校准。STANDBY待机不输出动力。ACTIVE正常工作执行任务。DEGRADED部分模块故障进入降级模式。ESTOP急停锁定所有关节并停止输出力矩。FAULT严重故障进入保护状态。每个状态之间的迁移必须有明确条件。例如感知节点连续 3 秒没有发布数据规划层就不能继续下发目标关节力矩超过阈值安全模块要主动切换到 ESTOP而不是等待上层决策。这些保护逻辑必须独立于 AI 决策不能把安全寄托在“模型应该会自己避障”上。4. 最小可运行的人形机器人控制链路示例完整的人形机器人开发需要昂贵的硬件设备但入门时完全可以用仿真环境加一个小型机器人关节模型来验证软件架构。这里给出一个基于 ROS 2 的最小控制链路示例一个控制器节点订阅目标关节角度经过限幅和插值后发布关节控制消息另一个节点模拟关节执行器回读角度。需要说明的是下面的示例用于说明思路和学习流程实际项目要结合自己的电机关节型号、CAN 协议和 ROS 2 版本调整。4.1 环境准备与依赖开发环境建议使用 Ubuntu 22.04 或 Ubuntu 24.04安装 ROS 2 Humble 或 Jazzy。如果只学习软件架构不连接真实电机可以只安装基础 ROS 2 桌面版。# Ubuntu 22.04 安装 ROS 2 Humble 示例 sudo apt update sudo apt install ros-humble-desktop python3-colcon-common-extensions source /opt/ros/humble/setup.bash建议再准备一个仿真环境。Gazebo 和 MuJoCo 都是常见的入门选择。MuJoCo 适合做关节动力学仿真Gazebo 适合做传感器丰富的整机仿真。第一次学习时先用一个urdf描述的简单关节模型即可不需要急着搭建完整人形。4.2 创建一个基础控制器节点创建一个 ROS 2 功能包命名为humanoid_minimal包含一个控制器节点。这个节点订阅目标关节角度话题对目标做限幅与插值再发布到关节命令话题。mkdir -p ~/robot_ws/src cd ~/robot_ws/src ros2 pkg create --build-type ament_python humanoid_minimal在humanoid_minimal/humanoid_minimal/controller_node.py中写入如下代码import rclpy from rclpy.node import Node from std_msgs.msg import Header from sensor_msgs.msg import JointState class JointControllerNode(Node): def __init__(self): super().__init__(joint_controller_node) self.declare_parameter(control_period, 0.01) self.declare_parameter(joint_names, [hip_yaw, hip_pitch, knee_pitch]) self.declare_parameter(max_step, 0.01) period self.get_parameter(control_period).value self.timer self.create_timer(period, self.control_loop) self.target_sub self.create_subscription( JointState, /target_joint_state, self.target_callback, 10) self.cmd_pub self.create_publisher( JointState, /joint_commands, 10) self.joint_names self.get_parameter(joint_names).value self.target_positions {} self.current_positions {name: 0.0 for name in self.joint_names} self.max_step self.get_parameter(max_step).value def target_callback(self, msg): for name, pos in zip(msg.name, msg.position): if name in self.joint_names: self.target_positions[name] pos def control_loop(self): for name in self.joint_names: target self.target_positions.get(name, self.current_positions[name]) diff target - self.current_positions[name] if abs(diff) self.max_step: diff self.max_step if diff 0 else -self.max_step self.current_positions[name] diff cmd JointState() cmd.header Header() cmd.header.stamp self.get_clock().now().to_msg() cmd.name self.joint_names cmd.position [self.current_positions[name] for name in self.joint_names] cmd.velocity [0.0] * len(self.joint_names) cmd.effort [0.0] * len(self.joint_names) self.cmd_pub.publish(cmd) def main(argsNone): rclpy.init(argsargs) node JointControllerNode() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()这段代码的关键点是控制器每control_period秒执行一次默认 10ms对应 100Hz 控制频率。max_step限制每个周期关节角度最大变化量防止指令突变造成电机冲击。代码没有直接输出目标角度而是逐步逼近目标目的是模拟真实机器人中的平滑插值逻辑。在setup.py中把入口函数注册好entry_points{ console_scripts: [ joint_controller humanoid_minimal.controller_node:main, ], },4.3 运行与验证编译并运行cd ~/robot_ws colcon build source install/setup.bash ros2 run humanoid_minimal joint_controller新开一个终端发布目标关节角度ros2 topic pub --once /target_joint_state sensor_msgs/msg/JointState \ {name: [hip_pitch], position: [0.5]}再开一个终端查看控制输出ros2 topic echo /joint_commands预期输出是关节角度逐步从 0 向 0.5 逼近每次变化不超过max_step。这说明控制器节点工作正常消息通路完整。注意不要只验证程序能启动还要验证数据是“逐步变化”而不是“一步到位”因为真实电机根本无法容忍角度突变。这个例子虽然简单但能帮你建立“控制指令必须平滑”的意识。5. 从实验室到量产工程化要解决的问题比算法更多5.1 仿真先行但要清楚仿真与真机的差距人形机器人调试成本高昂一个摔倒动作可能导致昂贵的伺服电机损坏。开发流程上强烈建议“仿真先行真机验证在后”。常见仿真工具有 Gazebo、MuJoCo、Isaac Lab 等。仿真能解决三件事验证软件架构和数据流是否正确。验证运动规划算法在理想动力学环境下是否收敛。批量跑强化学习策略生成大量训练数据。但仿真不能解决所有问题sim-to-real 差距是长期存在的。真实环境中的摩擦、机械间隙、通信延迟、传感器噪声都会导致仿真里能走的策略在真机上摔倒。工程上常用的补偿方式是系统辨识、域随机化、真机数据微调。5.2 日志、数据回放与可观测性是最容易被忽略的架构很多机器人团队在原型阶段不重视日志等到真机上出现一个偶发抖动才发现完全没有数据可以回放。建议从第一天就建立所有控制指令和状态数据通过ros2 bag记录故障后离线回放。关键节点发布diagnostic_msgs/DiagnosticStatus状态方便监控节点健康度。日志带上时间戳和节点名统一落盘别只靠print。对于多芯片系统还要考虑不同芯片之间的时间同步。MCU 上报的关节数据如果不带时间戳SoC 就无法准确判断数据是否过期。常见做法是 MCU 在 CAN 帧里携带微秒级时间戳SoC 做时钟同步或补偿。5.3 学习环境与生产环境的差异项目学习/原型环境生产环境通信笔记本 USB、Wi-FiCAN FD、工业以太网、可靠备份链路电源适配器供电电池管理、软硬件急停安全手动停止E-stop、力矩/位置双重限位、独立安全 MCU软件单机直接运行OTA 升级、配置外置化、崩溃自恢复日志终端打印集中日志、离线回放、远程监控可靠性允许重启看门狗、冗余节点、关键状态持久化认证不做要求功能安全、电磁兼容、机械安全标准把学习环境的代码搬到生产环境时至少要检查有没有硬件看门狗电机断线时控制节点能不能检测主控重启后关节位置如何重新同步这些问题不解决任何演示都无法稳定复现。6. 常见问题与排查路径6.1 关节电机抖动明显现象机器人关节在静止或低速时出现高频抖动电流声明显。排查顺序先确认控制周期是否稳定。在 ROS 2 节点里打印control_loop的实际间隔如果波动大可能是调度问题或负载过高。检查max_step是否过小导致角度一直逼近目标却在目标附近来回震荡。检查 PID 参数是否过激进。位置环增益过大容易引起抖动建议先调低 P再逐步增加 I。检查通信链路是否丢帧。CAN 总线如果丢帧率高中断就会导致控制指令断续。6.2 控制链路延迟高遥控不跟手现象远程遥控时机械臂或人形机器人动作明显滞后操作者感觉指令延迟超过 200ms。排查顺序先数一下数据经过了几个节点。每增加一个节点转发至少要增加一个周期延迟节点间通信如果使用 QoSRELIABLE在弱网环境下会重复发送导致延迟增大。检查规划节点是否占用了大量 CPU。AI 推理节点如果和控制规划节点在同一颗 SoC 上会出现计算争抢建议通过taskset绑核或拆分到不同处理器。检查日志打印是否阻塞。高频循环里使用阻塞型日志服务会将控制周期拉长。如果用 DDS 做跨设备通信还要检查 Wi-Fi 或交换机网络质量建议控制链路走有线以太网。6.3 节点掉线或系统卡死现象运行一段时间后某节点不再发布消息机器人进入 FAULT 状态或完全失控。排查顺序配置看门狗。ROS 2 的timer回调如果持续异常节点不会自动退出需要单独监控心跳。检查是否内存泄漏。长时间运行后 RSS 持续增长大概率是某个感知节点的缓存没有释放。检查是否有线程不安全操作。回调里直接操作共享字典可能产生数据竞争建议使用rclpy的线程安全队列或加锁。确认异常处理是否完整。裸except吞掉异常会造成节点假死必须在异常分支记录日志并让节点进入故障状态。问题现象常见原因检查方式处理建议关节高频抖动PID 增益过高或控制周期不稳定打印实际控制周期、逐步降低 P先降增益再检查调度和总线丢帧遥控延迟高数据通路过长或 AI 推理争抢 CPU统计各节点延迟、查看 CPU 占用缩短通路、绑核、控制链路走有线节点假死异常被吞、死锁、内存泄漏检查心跳、看日志、观察 RSS加看门狗、规范异常处理、修复泄漏电机突然急停安全限位误触发查看力矩和限位日志调整安全阈值增加防抖时间7. 人形机器人软件架构最佳实践清单与扩展方向7.1 一套可以复用的开发检查清单在开始一个人形机器人软件项目时建议把下面这些要点放进代码评审清单电机级控制是否放在硬实时 MCU 上而非 Linux 用户态。高频控制链路是否与 AI 推理链路隔离避免互相影响。所有时间敏感消息是否带时间戳是否能区分“数据过期”和“数据错误”。是否每个关键节点都有心跳监控和故障状态上报。是否所有控制指令都有位置限幅、速度限幅和力矩限幅。机器人的每个任务目标是否经过运动规划器而非直接驱动关节。是否从第一天就启用数据回放能力故障后能离线分析。是否在硬件层面有独立急停通道不依赖主控是否正常运行。代码是否按功能域拆分成独立节点能否单独替换某个模块。是否在仿真环境和真机环境之间做了域随机化准备降低 sim-to-real 成本。这份清单不是一次性能完成的但应该作为每个迭代阶段都必须复核的项目。尤其是“控制指令限幅”和“独立急停通道”这两项任何时候都不能缺失。7.2 下一步可以深入的方向看完本文你已经理解了人形机器人软件架构的分层、芯片选型逻辑和最小控制链路。后续可以根据自己的方向继续深入如果对算法感兴趣可以学习全身运动规划WBC、步态规划和强化学习在双足控制中的应用重点关注仿真到真机的迁移。如果对硬件更感兴趣可以深入研究 FOC 电机控制、CAN FD 通信协议、关节模组里的力传感器数据融合。如果对 AI 感兴趣可以关注视觉语言动作模型VLA如何与大模型结合形成“感知-规划-控制”的完整链路同时注意大模型输出的不可靠性如何被控制层兜底。如果对产品化感兴趣可以研究多芯片异构平台的算力调度比如 SoC 的 NPU 和独立 GPU 如何协同跑多个模型以及低功耗场景下的模型量化方案。人形机器人开发最大的挑战是把多个高难度环节串成一条可靠的链路而链路本身的可调试性、可维护性和安全性正是软件架构的意义所在。对刚入门的开发者来说不必一开始就追求完整人形建议先用一个带关节的仿真模型、一块主控板和几个电机把本文的最小控制链路跑通再逐步加入感知、规划和 AI 模块这是投入产出比最高的进阶路径。 
长河君 · 2026/8/27 10:28:31 · 阅读 1.2k 人形机器人主控SoC与软件架构设计实践指南
人形机器人热度最近频繁进入技术社区视野。无论是双足行走、灵巧手操作还是大模型驱动的具身智能真正决定一台人形机器人能不能从演示视频走向稳定运行的关键往往不是某一个算法的突破而是整套软件架构和主控算力平台能否把感知、决策、控制串成一条低延迟、可调试、可升级的闭环。对开发者来说关注“人形机器人软件架构”和“主控芯片选型”比单纯追一个演示效果更有工程价值。本文围绕人形机器人主控 SoC 与软件架构展开先讲清楚系统分层再给出可落地的最小控制链路示例、工程化要点和排查路径适合准备进入机器人开发、或者正在做机器人主控方案评估的嵌入式与软件工程师阅读。1. 人形机器人不能只靠“一个算法跑起来”先理解系统分层1.1 人形机器人与普通设备的本质差异人形机器人通常有十几个到几十个关节自由度双足行走要求在毫秒级时间内完成姿态判断和关节力矩调整灵巧手操作又要兼顾力控制和位置控制。它既不是普通 MCU 设备那样的简单传感器循环也不是纯云端大模型能单独完成的推理任务。真正的问题是不同模块对实时性的要求完全不同对算力的需求也完全不同如果所有逻辑都堆在一个进程里系统很快就无法维护。实际项目中人形机器人至少要同时处理三类任务关节电机控制和传感器读取通常要求控制周期在 1ms 到 10ms 级别。状态估计、运动规划、安全判断通常要求 10ms 到 100ms 级别。视觉感知、语言理解、复杂决策通常是 100ms 到秒级算力需求高但实时性相对宽松。这三类任务混在一起运行就会出现“电机控制被视觉推理卡住”的经典问题。软件架构的核心目标就是把不同实时性、不同算力需求的任务隔离到合适的层级和合适的硬件上。1.2 机器人软件的五层参考模型参考业界常见的机器人系统设计可以按下面五层来理解层级职责典型模块实时性要求执行层驱动关节电机、读取编码器电机驱动、FOC、PID1ms 级感知层采集并处理传感器数据摄像头、IMU、激光雷达、力传感器10ms 级状态与决策层估算位姿、规划运动、做任务决策状态机、行为树、运动规划器10ms 到 100ms 级认知层大模型推理、视觉语言理解VLM、VLA、目标识别100ms 到秒级人机交互层远程遥控、语音、显示遥控协议、语音交互秒级或异步每一层之间通过明确接口通信而不是互相直接调用内部函数。这样才能在替换感知算法时不影响底层控制在升级大模型时不需要重写电机驱动。很多新手把机器人软件理解成“一个主循环里调一堆函数”实际上工程化的人形机器人软件更像一个“消息驱动的分布式系统”只是它运行在有限算力的嵌入式平台上。1.3 从 ROS 到 ROS 2为什么机器人中间件在变化提到机器人软件架构绕不开 ROS。ROS 1 的设计目标是科研场景的快速原型验证主节点roscore负责所有节点通信一旦主节点崩溃整个系统不可用节点间通过 TCP 通信在复杂网络和实时场景下表现有限。ROS 2 针对这些问题做了几项关键变化使用 DDS 作为底层通信中间件节点间可以点对点发现和通信不再依赖中心节点。引入 QoS 策略可以配置消息传输的可靠性、历史和优先级适应不同控制场景。支持生命周期节点节点可以显式管理配置、激活、关闭状态适合机器人启动和故障恢复。实时性更好在 Linux 配合 PREEMPT_RT 内核时可以支撑更严格的控制周期。对人形机器人来说ROS 2 的价值不只是通信而是它建立了“节点、话题、服务、动作”的软件组织方式让不同团队可以并行开发不同模块再通过标准接口集成。注意ROS 2 不是万能的。电机层的 FOC 电流环、关节位置环仍然要放在支持硬实时的 MCU 或 RTOS 里不能指望 Linux 上的 ROS 2 节点去做 1kHz 的电流控制。2. 主控芯片与人形机器人的算力分工2.1 机器人主控到底要承担哪些计算人形机器人的“大脑”不是一颗芯片而是一组芯片协同工作。芯片选型的第一步是分清每一颗芯片承担什么任务。MCU 负责关节电机控制和关键传感器采集。典型代表是 STM32 系列、GD32 系列、ESP32 等。它们跑 RTOS 或裸机控制周期可以做到 1ms保证电机环路稳定。应用处理器 SoC 负责跑 Linux、ROS 2、运动规划、状态估计和外设管理。常见的是 ARM 架构的嵌入式 SoC这类芯片需要有足够的 CPU 性能、丰富的外设接口和完整的 BSP 支持。AI 加速单元负责视觉推理、大模型驱动。可以是 SoC 内置的 NPU也可以是独立的 GPU、NPU 模块。如果人形机器人只做远程遥控和简单运动一颗中高端 SoC 就够了。但一旦加了视觉感知、语言交互、自主规划就要考虑异构算力协同。把视觉大模型推理放在 NPU 上、把运动规划放在 CPU 上、把电机控制放在 MCU 上是目前比较常见的设计。2.2 多芯片协同MCU、SoC 与 NPU 的分工边界在真实产品里这种分工表现为明确的通信拓扑。IMU / 编码器 / 电机 | MCU关节控制 | CAN / UART / SPI SoCLinux ROS 2 | 以太网 / USB / MIPI-CSI NPU / GPUAI 推理MCU 采集到的关节角度、电流、力矩数据通过 CAN 或 UART 上报给 SoCSoC 上的 ROS 2 节点把这些数据融合成机器人的状态估计决策层生成目标轨迹后再把关节目标角度或力矩指令下发给 MCU。AI 推理结果作为高层意图输入不直接指挥电机而是先经过规划器转化为平滑轨迹。这样做的原因很直接AI 推理延迟不稳定如果让大模型直接输出关节角度并下发到电机机器人会抖动甚至摔倒。安全攸关的运动指令必须经过确定性的控制链路。2.3 面向人形机器人的 SoC 选型参考维度在社区讨论中全志科技这类国产 SoC 进入人形机器人主控视野并不是偶然。全志在平板、智能硬件、边缘设备上有大量成熟方案芯片的 CPU 性能、视频输入接口、NPU 算力和量产供货能力都比较成熟对机器人创业团队来说选型成本低、BSP 资料完整、供应链风险小是评估嵌入式主控时值得考虑的厂商。不过选型不能只看品牌建议从以下维度做对比表选型维度关注点错误选择的表现CPU 性能是否满足 Linux ROS 2 运行启动慢、规划卡顿NPU 算力是否能跑视觉模型推理延迟高、掉帧外设接口CAN、UART、SPI、MIPI-CSI、以太网是否足够需要大量扩展板卡BSP 与内核支持是否有长期维护的内核和驱动外设驱动要自己移植供电与功耗是否适合电池供电发热严重、续航短供货与生态是否有量产案例、文档是否完整拿不到样片、资料不全需要注意许多 SoC 的 NPU 只支持特定框架和算子落地前要确认目标模型能否转换。如果主要跑 VLA 双足控制这类大模型单靠中端 SoC 的 NPU 可能不够需要配合边缘 GPU 或云侧推理。3. 人形机器人软件架构的核心模块怎么设计3.1 按功能域拆分模块而不是按文件拆一个可维护的人形机器人软件仓库通常按功能域拆成独立包而不是把所有代码塞进一个“main.py”。建议的模块划分如下sensor_drivers摄像头、IMU、激光雷达、力传感器、编码器驱动。perception目标检测、语义分割、点云处理、人体识别。state_estimationIMU 与编码器融合、里程计、双足落地状态判断。planning全身运动规划、步态规划、避障、关节轨迹生成。control关节位置/力矩控制、全身动力学控制、接触力控制。safety急停检测、关节限位、力矩超限保护、摔倒检测。teleop遥控手柄、手机 App、视觉遥操作指令接入。system生命周期管理、日志、参数服务、看门狗。每个模块以 ROS 2 节点的形式独立运行使用话题和动作进行通信。比如perception输出目标位姿planning订阅这个位姿生成关节轨迹control订阅关节轨迹并转换为电机指令。这样任何一层都可以单独调试和替换。3.2 数据通路要考虑“回环”而非“流水线”很多人在设计软件时会把机器人流程理解成单向流水线传感器数据进、电机指令出。实际上人形机器人系统的关键是有大量回环。内环电流环和速度环在 MCU 内完成控制频率最高。中环姿态环和关节位置环在控制节点完成使用 IMU 和编码器反馈。外环任务规划和目标跟踪在规划节点完成反馈来自感知和状态估计。数据要从“单向传递”改成“带反馈的闭环”设计。比如行走控制不仅要吃目标速度还要实时吃落地状态、IMU 姿态和关节力矩才能处理路面不平、外力推搡等情况。3.3 状态管理与故障恢复防止机器人变成“失控的钢铁”人形机器人最怕的是一旦某个节点出错电机会输出错误指令。软件架构必须包含状态机和安全管理。机器人状态机至少要包含INIT上电自检、关节回零、传感器校准。STANDBY待机不输出动力。ACTIVE正常工作执行任务。DEGRADED部分模块故障进入降级模式。ESTOP急停锁定所有关节并停止输出力矩。FAULT严重故障进入保护状态。每个状态之间的迁移必须有明确条件。例如感知节点连续 3 秒没有发布数据规划层就不能继续下发目标关节力矩超过阈值安全模块要主动切换到 ESTOP而不是等待上层决策。这些保护逻辑必须独立于 AI 决策不能把安全寄托在“模型应该会自己避障”上。4. 最小可运行的人形机器人控制链路示例完整的人形机器人开发需要昂贵的硬件设备但入门时完全可以用仿真环境加一个小型机器人关节模型来验证软件架构。这里给出一个基于 ROS 2 的最小控制链路示例一个控制器节点订阅目标关节角度经过限幅和插值后发布关节控制消息另一个节点模拟关节执行器回读角度。需要说明的是下面的示例用于说明思路和学习流程实际项目要结合自己的电机关节型号、CAN 协议和 ROS 2 版本调整。4.1 环境准备与依赖开发环境建议使用 Ubuntu 22.04 或 Ubuntu 24.04安装 ROS 2 Humble 或 Jazzy。如果只学习软件架构不连接真实电机可以只安装基础 ROS 2 桌面版。# Ubuntu 22.04 安装 ROS 2 Humble 示例 sudo apt update sudo apt install ros-humble-desktop python3-colcon-common-extensions source /opt/ros/humble/setup.bash建议再准备一个仿真环境。Gazebo 和 MuJoCo 都是常见的入门选择。MuJoCo 适合做关节动力学仿真Gazebo 适合做传感器丰富的整机仿真。第一次学习时先用一个urdf描述的简单关节模型即可不需要急着搭建完整人形。4.2 创建一个基础控制器节点创建一个 ROS 2 功能包命名为humanoid_minimal包含一个控制器节点。这个节点订阅目标关节角度话题对目标做限幅与插值再发布到关节命令话题。mkdir -p ~/robot_ws/src cd ~/robot_ws/src ros2 pkg create --build-type ament_python humanoid_minimal在humanoid_minimal/humanoid_minimal/controller_node.py中写入如下代码import rclpy from rclpy.node import Node from std_msgs.msg import Header from sensor_msgs.msg import JointState class JointControllerNode(Node): def __init__(self): super().__init__(joint_controller_node) self.declare_parameter(control_period, 0.01) self.declare_parameter(joint_names, [hip_yaw, hip_pitch, knee_pitch]) self.declare_parameter(max_step, 0.01) period self.get_parameter(control_period).value self.timer self.create_timer(period, self.control_loop) self.target_sub self.create_subscription( JointState, /target_joint_state, self.target_callback, 10) self.cmd_pub self.create_publisher( JointState, /joint_commands, 10) self.joint_names self.get_parameter(joint_names).value self.target_positions {} self.current_positions {name: 0.0 for name in self.joint_names} self.max_step self.get_parameter(max_step).value def target_callback(self, msg): for name, pos in zip(msg.name, msg.position): if name in self.joint_names: self.target_positions[name] pos def control_loop(self): for name in self.joint_names: target self.target_positions.get(name, self.current_positions[name]) diff target - self.current_positions[name] if abs(diff) self.max_step: diff self.max_step if diff 0 else -self.max_step self.current_positions[name] diff cmd JointState() cmd.header Header() cmd.header.stamp self.get_clock().now().to_msg() cmd.name self.joint_names cmd.position [self.current_positions[name] for name in self.joint_names] cmd.velocity [0.0] * len(self.joint_names) cmd.effort [0.0] * len(self.joint_names) self.cmd_pub.publish(cmd) def main(argsNone): rclpy.init(argsargs) node JointControllerNode() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()这段代码的关键点是控制器每control_period秒执行一次默认 10ms对应 100Hz 控制频率。max_step限制每个周期关节角度最大变化量防止指令突变造成电机冲击。代码没有直接输出目标角度而是逐步逼近目标目的是模拟真实机器人中的平滑插值逻辑。在setup.py中把入口函数注册好entry_points{ console_scripts: [ joint_controller humanoid_minimal.controller_node:main, ], },4.3 运行与验证编译并运行cd ~/robot_ws colcon build source install/setup.bash ros2 run humanoid_minimal joint_controller新开一个终端发布目标关节角度ros2 topic pub --once /target_joint_state sensor_msgs/msg/JointState \ {name: [hip_pitch], position: [0.5]}再开一个终端查看控制输出ros2 topic echo /joint_commands预期输出是关节角度逐步从 0 向 0.5 逼近每次变化不超过max_step。这说明控制器节点工作正常消息通路完整。注意不要只验证程序能启动还要验证数据是“逐步变化”而不是“一步到位”因为真实电机根本无法容忍角度突变。这个例子虽然简单但能帮你建立“控制指令必须平滑”的意识。5. 从实验室到量产工程化要解决的问题比算法更多5.1 仿真先行但要清楚仿真与真机的差距人形机器人调试成本高昂一个摔倒动作可能导致昂贵的伺服电机损坏。开发流程上强烈建议“仿真先行真机验证在后”。常见仿真工具有 Gazebo、MuJoCo、Isaac Lab 等。仿真能解决三件事验证软件架构和数据流是否正确。验证运动规划算法在理想动力学环境下是否收敛。批量跑强化学习策略生成大量训练数据。但仿真不能解决所有问题sim-to-real 差距是长期存在的。真实环境中的摩擦、机械间隙、通信延迟、传感器噪声都会导致仿真里能走的策略在真机上摔倒。工程上常用的补偿方式是系统辨识、域随机化、真机数据微调。5.2 日志、数据回放与可观测性是最容易被忽略的架构很多机器人团队在原型阶段不重视日志等到真机上出现一个偶发抖动才发现完全没有数据可以回放。建议从第一天就建立所有控制指令和状态数据通过ros2 bag记录故障后离线回放。关键节点发布diagnostic_msgs/DiagnosticStatus状态方便监控节点健康度。日志带上时间戳和节点名统一落盘别只靠print。对于多芯片系统还要考虑不同芯片之间的时间同步。MCU 上报的关节数据如果不带时间戳SoC 就无法准确判断数据是否过期。常见做法是 MCU 在 CAN 帧里携带微秒级时间戳SoC 做时钟同步或补偿。5.3 学习环境与生产环境的差异项目学习/原型环境生产环境通信笔记本 USB、Wi-FiCAN FD、工业以太网、可靠备份链路电源适配器供电电池管理、软硬件急停安全手动停止E-stop、力矩/位置双重限位、独立安全 MCU软件单机直接运行OTA 升级、配置外置化、崩溃自恢复日志终端打印集中日志、离线回放、远程监控可靠性允许重启看门狗、冗余节点、关键状态持久化认证不做要求功能安全、电磁兼容、机械安全标准把学习环境的代码搬到生产环境时至少要检查有没有硬件看门狗电机断线时控制节点能不能检测主控重启后关节位置如何重新同步这些问题不解决任何演示都无法稳定复现。6. 常见问题与排查路径6.1 关节电机抖动明显现象机器人关节在静止或低速时出现高频抖动电流声明显。排查顺序先确认控制周期是否稳定。在 ROS 2 节点里打印control_loop的实际间隔如果波动大可能是调度问题或负载过高。检查max_step是否过小导致角度一直逼近目标却在目标附近来回震荡。检查 PID 参数是否过激进。位置环增益过大容易引起抖动建议先调低 P再逐步增加 I。检查通信链路是否丢帧。CAN 总线如果丢帧率高中断就会导致控制指令断续。6.2 控制链路延迟高遥控不跟手现象远程遥控时机械臂或人形机器人动作明显滞后操作者感觉指令延迟超过 200ms。排查顺序先数一下数据经过了几个节点。每增加一个节点转发至少要增加一个周期延迟节点间通信如果使用 QoSRELIABLE在弱网环境下会重复发送导致延迟增大。检查规划节点是否占用了大量 CPU。AI 推理节点如果和控制规划节点在同一颗 SoC 上会出现计算争抢建议通过taskset绑核或拆分到不同处理器。检查日志打印是否阻塞。高频循环里使用阻塞型日志服务会将控制周期拉长。如果用 DDS 做跨设备通信还要检查 Wi-Fi 或交换机网络质量建议控制链路走有线以太网。6.3 节点掉线或系统卡死现象运行一段时间后某节点不再发布消息机器人进入 FAULT 状态或完全失控。排查顺序配置看门狗。ROS 2 的timer回调如果持续异常节点不会自动退出需要单独监控心跳。检查是否内存泄漏。长时间运行后 RSS 持续增长大概率是某个感知节点的缓存没有释放。检查是否有线程不安全操作。回调里直接操作共享字典可能产生数据竞争建议使用rclpy的线程安全队列或加锁。确认异常处理是否完整。裸except吞掉异常会造成节点假死必须在异常分支记录日志并让节点进入故障状态。问题现象常见原因检查方式处理建议关节高频抖动PID 增益过高或控制周期不稳定打印实际控制周期、逐步降低 P先降增益再检查调度和总线丢帧遥控延迟高数据通路过长或 AI 推理争抢 CPU统计各节点延迟、查看 CPU 占用缩短通路、绑核、控制链路走有线节点假死异常被吞、死锁、内存泄漏检查心跳、看日志、观察 RSS加看门狗、规范异常处理、修复泄漏电机突然急停安全限位误触发查看力矩和限位日志调整安全阈值增加防抖时间7. 人形机器人软件架构最佳实践清单与扩展方向7.1 一套可以复用的开发检查清单在开始一个人形机器人软件项目时建议把下面这些要点放进代码评审清单电机级控制是否放在硬实时 MCU 上而非 Linux 用户态。高频控制链路是否与 AI 推理链路隔离避免互相影响。所有时间敏感消息是否带时间戳是否能区分“数据过期”和“数据错误”。是否每个关键节点都有心跳监控和故障状态上报。是否所有控制指令都有位置限幅、速度限幅和力矩限幅。机器人的每个任务目标是否经过运动规划器而非直接驱动关节。是否从第一天就启用数据回放能力故障后能离线分析。是否在硬件层面有独立急停通道不依赖主控是否正常运行。代码是否按功能域拆分成独立节点能否单独替换某个模块。是否在仿真环境和真机环境之间做了域随机化准备降低 sim-to-real 成本。这份清单不是一次性能完成的但应该作为每个迭代阶段都必须复核的项目。尤其是“控制指令限幅”和“独立急停通道”这两项任何时候都不能缺失。7.2 下一步可以深入的方向看完本文你已经理解了人形机器人软件架构的分层、芯片选型逻辑和最小控制链路。后续可以根据自己的方向继续深入如果对算法感兴趣可以学习全身运动规划WBC、步态规划和强化学习在双足控制中的应用重点关注仿真到真机的迁移。如果对硬件更感兴趣可以深入研究 FOC 电机控制、CAN FD 通信协议、关节模组里的力传感器数据融合。如果对 AI 感兴趣可以关注视觉语言动作模型VLA如何与大模型结合形成“感知-规划-控制”的完整链路同时注意大模型输出的不可靠性如何被控制层兜底。如果对产品化感兴趣可以研究多芯片异构平台的算力调度比如 SoC 的 NPU 和独立 GPU 如何协同跑多个模型以及低功耗场景下的模型量化方案。人形机器人开发最大的挑战是把多个高难度环节串成一条可靠的链路而链路本身的可调试性、可维护性和安全性正是软件架构的意义所在。对刚入门的开发者来说不必一开始就追求完整人形建议先用一个带关节的仿真模型、一块主控板和几个电机把本文的最小控制链路跑通再逐步加入感知、规划和 AI 模块这是投入产出比最高的进阶路径。