人形机器人总体架构：硬件系统、软件系统、感知-决策-执行闭环的层次划分
人形机器人的总体架构是理解其功能实现与性能边界的核心框架。与工业机械臂或移动底盘不同，人形机器人需要在非结构化环境中完成双足行走、双臂操作、视觉导航与人机交互等复合任务，这决定了其架构必须同时满足高带宽感知、实时决策、高动态响应与能量自持等多重约束。本章从硬件系统、软件系统以及感知-决策-执行闭环三个维度展开，建立对系统级设计的整体认知。
2.1 硬件系统：从关节模组到整机拓扑
硬件系统是人形机器人的物理载体，决定了机器人的负载能力、运动精度、续航时长与扩展性。从工程视角看，硬件系统可划分为四个子系统：感知硬件、计算硬件、执行硬件以及能源与通信硬件。每个子系统内部有明确的接口规范，子系统之间通过总线或物理连接形成整机拓扑。
核心原理：人形机器人的硬件设计遵循“分布式计算+集中式管理”的原则。关节模组内部集成电机、减速器、编码器与驱动器，形成独立的伺服单元；而主控SoC负责全局感知与决策，通过高速总线（如EtherCAT、PCIe）与各关节模组通信。这种架构将高频控制环（电流环、速度环）下沉到关节驱动器，将低频决策环（路径规划、行为选择）保留在主控，从而降低总线负载并提高响应速度。
硬件选型的关键判断方法：
- 关节峰值扭矩与额定扭矩：根据机器人总重量与运动工况（如跳跃、爬坡）估算所需扭矩，通常取1.5-2倍安全裕量。例如，一个70kg的人形机器人，髋关节峰值扭矩需达到150-200Nm。
- 总线带宽与实时性：若关节数量超过20个，且控制频率要求1kHz以上，EtherCAT是首选；若关节数量较少且成本敏感，CAN总线可满足基本需求。
- 计算资源分配：视觉SLAM与深度学习推理需要GPU或NPU；实时运动控制需要独立MCU或FPGA，避免与主控争抢CPU资源。
- 热设计与功耗预算：整机功耗通常为200-500W，其中关节驱动占60%以上。必须设计有效的散热路径（如液冷或热管），否则长时间运行会导致关节温升过高而降额。
| 子系统 | 关键器件 | 典型参数/规格 | 设计要点 |
|---|---|---|---|
| 感知硬件 | 双目相机、LiDAR、IMU、六维力传感器 | 相机帧率30-60fps；LiDAR 10-20Hz；IMU 200-1000Hz | 传感器同步（硬件触发或时间戳对齐） |
| 计算硬件 | 主控SoC（如NVIDIA Orin）、实时MCU（如STM32H7）、FPGA | 主控算力275 TOPS；MCU主频480MHz | 异构计算，任务分区，避免资源竞争 |
| 执行硬件 | 无框力矩电机、谐波减速器、伺服驱动器 | 减速比50-160；编码器分辨率17-19bit | 关节刚度与背隙控制，力矩闭环 |
| 能源与通信 | 锂电池组、BMS、EtherCAT主站、Wi-Fi模块 | 电压48-72V；容量2-4kWh；EtherCAT周期1ms | 电源隔离、总线冗余、EMC防护 |
2.2 软件系统：分层解耦与实时性保障
软件系统是人形机器人的“神经系统”，负责将硬件能力抽象为可调用的服务，并承载感知、决策、控制等算法。软件架构通常分为三层：系统软件、算法软件与应用软件。层与层之间通过标准接口通信，降低耦合度，便于独立迭代与测试。
核心原理：实时性是人形机器人软件架构的核心矛盾。运动控制要求确定性延迟（通常<1ms），而感知算法（如深度学习）需要较大计算量且延迟波动明显。解决方案是采用“混合实时架构”：将实时任务（关节伺服、状态估计）运行在RTOS或Linux+RT Patch上，将非实时任务（语义理解、全局规划）运行在普通Linux进程中，通过共享内存或DDS进行异步通信。
软件系统操作流程：
- 硬件抽象层（HAL）封装：将不同厂商的传感器、关节模组统一为标准化接口（如ROS 2的硬件接口），屏蔽底层寄存器差异。
- 中间件选型：ROS 2（基于DDS）适合分布式通信与模块化开发；若对实时性要求极高，可采用开源的实时中间件（如EtherCAT主站协议栈）。
- 算法模块化：将感知、规划、控制拆分为独立节点，节点间通过Topic/Service通信，便于单点调试与替换。
- 仿真与实机一致性：使用MuJoCo、Isaac Sim等仿真环境进行算法验证，但需注意仿真与实机的动力学参数差异（如摩擦、延迟），需引入系统辨识与域随机化。
2.3 感知-决策-执行闭环：分层协作与数据流
感知-决策-执行闭环是人形机器人实现自主行为的核心逻辑链。三个层次并非简单的串行流水线，而是存在多速率、多反馈的复杂耦合关系。理解这一闭环的层次划分，是进行系统调试与性能优化的基础。
核心原理：闭环的三个层次具有不同的时间尺度与数据抽象级别。感知层以30-100Hz的频率输出环境状态（如机器人位姿、障碍物位置）；决策层以100-1000Hz的频率生成运动指令（如关节目标角度、足端轨迹）；执行层以1-10kHz的频率完成电流环与速度环控制。层间通过“状态反馈”形成闭环：执行层的实际状态（如关节角度、接触力）被感知层重新采集，用于更新状态估计，从而修正下一轮决策。
层次划分与接口定义：
| 层次 | 输入数据 | 输出数据 | 典型算法 | 运行频率 |
|---|---|---|---|---|
| 感知层 | 图像、点云、IMU、关节编码器 | 位姿、速度、环境地图、物体属性 | ORB-SLAM3、LIO-SAM、YOLO | 30-100Hz |
| 决策层 | 感知输出、任务目标、状态反馈 | 关节目标位置、足端轨迹、操作序列 | WBC（全身控制）、MPC、RRT* | 100-1000Hz |
| 执行层 | 关节目标位置/力矩 | 电机电流、实际关节力矩 | PID、ADRC、阻抗控制 | 1-10kHz |
案例拆解：以“人形机器人从地面站起并走向目标点”为例，完整闭环流程如下：
- 感知：IMU与视觉融合，估计当前躯干姿态（俯仰角、横滚角），同时通过LiDAR构建局部地图，识别目标点位置。
- 决策：全身控制（WBC）根据当前姿态与目标位置，规划躯干质心轨迹与双脚落点序列。MPC在预测时域内优化关节力矩，保证ZMP（零力矩点）落在支撑多边形内。
- 执行：关节驱动器接收力矩指令，以4kHz频率完成电流环控制，实际关节角度通过编码器反馈给决策层，形成闭环修正。
- 反馈：若行走中遇到地面不平导致躯干倾斜，感知层检测到姿态偏差，决策层立即调整步态参数（如步幅、步频），执行层快速响应。
2.4 常见误区与系统级复盘
在工程实践中，团队常陷入以下误区，导致系统性能不达预期或开发周期延长。
误区一：硬件选型过度追求单项指标。例如，选用极高分辨率的力传感器，但忽略了通信带宽限制，导致数据无法实时传输。正确做法是进行系统级预算：计算每个子系统的数据量、延迟与功耗，确保整体平衡。
误区二：软件架构“一刀切”实时化。将所有算法都运行在RTOS中，导致开发效率低下且系统脆弱。正确做法是区分硬实时任务（关节控制）与软实时任务（感知、规划），采用混合架构。
误区三：忽视闭环中的时间同步。感知层、决策层、执行层的数据若时间戳不一致，会导致状态估计偏差。例如，视觉图像延迟30ms，而IMU数据延迟5ms，若未进行时间补偿，融合后的位姿会产生明显漂移。必须使用硬件同步信号或软件时间同步算法（如TSync）。
误区四：仿真与实机脱节。仿真环境中的理想模型（无摩擦、无延迟、无噪声）与实机差异巨大。建议在仿真中加入随机扰动与延迟模型，并采用“域随机化”技术，使策略在实机上具备鲁棒性。
总结复盘：人形机器人总体架构设计的核心在于“分层解耦、闭环协同”。硬件系统提供物理能力边界，软件系统提供灵活性与可扩展性，感知-决策-执行闭环则确保系统在动态环境中稳定运行。在项目启动阶段，建议先完成系统级架构图与接口定义，明确各层的数据流与控制流，再进行详细设计与开发。架构评审时，重点检查：总线带宽是否满足峰值需求？实时任务与非实时任务是否隔离？反馈回路是否存在死锁或振荡风险？通过系统化的架构设计与验证，可显著降低后期集成与调试的复杂度。