2、人形机器人系统概述：典型硬件架构（关节、传感器、执行器）、软件框架与常用仿真环境（如MuJoCo、PyBullet）
人形机器人是机电软深度耦合的复杂系统，其运动控制与平衡能力并非单一算法或单一硬件所能支撑，而是建立在层次化的硬件架构、实时软件框架与高保真仿真环境三者协同的基础之上。理解系统架构是学习运动控制的前提：硬件决定了执行与感知的物理边界，软件框架决定了算法部署的实时性与可扩展性，仿真环境则决定了开发迭代的效率与安全性。本章从工程视角拆解人形机器人的典型硬件组成、软件分层逻辑以及主流仿真工具的使用要点，为后续章节的动力学建模与平衡控制打下系统认知基础。
上图给出了人形机器人系统架构的整体视图。硬件层是物理基础，软件层是控制核心，仿真层是开发工具。三者并非孤立存在：硬件通过总线向软件层提供传感器数据并接收控制指令，软件层通过仿真环境进行算法验证后再部署到真实硬件。下面分别对三个层次进行深入剖析。
2.1 典型硬件架构：关节、传感器与执行器
核心原理：机电一体化设计
人形机器人的硬件架构围绕“感知-决策-执行”闭环展开。关节是运动执行的基本单元，通常采用“电机+减速器+编码器”的模组化设计。执行器（电机）提供驱动力矩，减速器（谐波减速器或行星减速器）放大扭矩并降低转速，编码器反馈关节位置和速度。传感器系统包括本体感知（IMU、关节编码器、力/力矩传感器）和外感感知（相机、激光雷达）。主控单元（通常是高性能实时计算板卡）负责运行控制算法，通过EtherCAT或CAN等实时总线与各关节驱动器通信。
| 硬件模块 | 典型器件 | 关键参数/指标 | 作用 |
|---|---|---|---|
| 关节执行器 | 无框力矩电机+谐波减速器 | 峰值扭矩 50-200 Nm，减速比 50-160 | 提供关节驱动力矩 |
| 关节传感器 | 磁编码器/光编码器 | 分辨率 19bit，采样率 1kHz | 测量关节位置/速度 |
| 本体传感器 | 6轴IMU（加速度计+陀螺仪） | 加速度 ±16g，角速度 ±2000dps | 估计机身姿态与角速度 |
| 力觉传感器 | 六维力/力矩传感器 | 力 500N，力矩 50Nm，过载 300% | 检测足底/手部接触力 |
| 主控计算单元 | Intel NUC / NVIDIA Jetson Orin | 实时核 + GPU，EtherCAT主站 | 运行控制算法与感知处理 |
| 通信总线 | EtherCAT / CAN FD | 周期 1ms，抖动 < 50μs | 关节驱动与传感器数据同步 |
判断方法：硬件选型与匹配
硬件选型需遵循“扭矩-速度-精度”匹配原则。首先根据各关节负载力矩需求确定电机峰值扭矩，再结合运动速度要求选择减速比，最后根据控制精度要求选择编码器分辨率。例如，髋关节需要大扭矩（约100Nm）和中等速度，适合采用大减速比谐波减速器；而手腕关节需要高精度和较小扭矩，可选用直驱或小减速比方案。电源系统需按峰值功率的1.5倍冗余设计，并考虑母线电压波动对控制性能的影响。
案例拆解：双足机器人腿部关节配置
以一款典型双足机器人（身高1.2m，体重30kg）为例，其腿部采用6自由度设计：髋关节3自由度（俯仰、滚转、偏航），膝关节1自由度（俯仰），踝关节2自由度（俯仰、滚转）。髋关节俯仰采用峰值扭矩120Nm的电机+谐波减速器（减速比100），膝关节峰值扭矩150Nm（减速比120），踝关节峰值扭矩60Nm（减速比80）。所有关节均配备双编码器（电机端+输出端），用于高精度位置控制和柔性碰撞检测。IMU安装于骨盆中心，六维力传感器安装于足底。该配置可支撑行走、跑步和跳跃等运动模式。
常见误区与总结
- 误区1：只关注电机峰值扭矩，忽略连续扭矩和热平衡。实际运行中电机温度会限制持续输出能力。
- 误区2：编码器分辨率越高越好。过高的分辨率会引入噪声，且增加通信负担，需结合控制频率选择。
- 误区3：忽视结构刚度。关节减速器、连杆和连接件的弹性变形会显著影响控制精度，需进行模态分析。
2.2 软件框架：实时控制与算法分层
核心原理：分层架构与实时性保障
人形机器人软件框架通常分为三层：实时控制层（1kHz控制周期）、中间件层（ROS2等通信框架）和应用层（感知、规划、决策）。实时控制层运行在RTOS或带实时补丁的Linux上，负责状态估计、动力学解算和关节控制指令生成。中间件层提供进程间通信、日志记录和参数管理。应用层处理视觉感知、路径规划和任务调度。层间通过共享内存或零拷贝通信机制传递数据，确保延迟可控。
操作流程：软件框架搭建步骤
- 选择实时操作系统：推荐使用Ubuntu + PREEMPT_RT补丁，或直接采用RTOS（如FreeRTOS、QNX）。
- 配置EtherCAT主站：使用SOEM或IgH EtherCAT Master，配置周期为1ms的同步任务。
- 部署ROS2节点：将控制算法封装为ROS2节点，通过DDS通信与感知模块交互。
- 实现状态估计：融合IMU和关节编码器数据，采用扩展卡尔曼滤波（EKF）估计机身姿态和速度。
- 编写控制循环：在实时线程中执行逆动力学计算、平衡控制和关节PD控制。
// 实时控制循环伪代码（1kHz）
while (rt_loop_active) {
imu_data = read_imu(); // 读取IMU
joint_state = read_encoders(); // 读取关节编码器
pose = ekf_update(imu_data, joint_state); // 状态估计
torque_cmd = balance_controller(pose); // 平衡控制
write_torque(torque_cmd); // 发送力矩指令
wait_next_period(); // 等待下一个周期
}案例拆解：基于ROS2的全身控制框架
某实验室采用ROS2 + real-time Linux搭建了人形机器人控制框架。实时控制层运行在独立CPU核心上，通过EtherCAT与关节通信，控制周期1ms。状态估计节点（EKF）和平衡控制器（基于模型预测控制MPC）部署在实时层。ROS2中间件负责将传感器数据发布给上层感知节点，并将规划好的足端轨迹发送给实时层。实测端到端延迟约2ms，满足动态行走需求。该框架支持仿真环境（MuJoCo）与真实机器人无缝切换，只需修改硬件接口层。
常见误区与总结
- 误区1：所有算法都放在ROS2节点中运行。ROS2的DDS通信存在不确定性，不适合高频控制回路。
- 误区2：忽视时间同步。IMU、编码器和力传感器数据必须带有精确时间戳，否则状态估计会发散。
- 误区3：仿真与实机代码不一致。应通过硬件抽象层隔离差异，确保同一套控制代码可部署到仿真和实机。
2.3 常用仿真环境：MuJoCo与PyBullet
核心原理：物理引擎与接触建模
仿真环境的核心是物理引擎，它通过数值积分计算刚体动力学、碰撞检测和接触力。MuJoCo（Multi-Joint dynamics with Contact）采用基于凸优化的接触模型，计算效率高、数值稳定性好，特别适合人形机器人这类多接触系统。PyBullet基于Bullet物理引擎，提供更灵活的碰撞形状和约束设置，适合快速原型验证和强化学习训练。两者均支持URDF模型导入、传感器仿真和可视化调试。
| 特性 | MuJoCo | PyBullet |
|---|---|---|
| 接触模型 | 软接触/硬接触，凸优化求解 | 基于约束的接触，支持摩擦锥 |
| 计算效率 | 高（C++实现，支持批量仿真） | 中等（Python接口，适合交互） |
| 强化学习支持 | 官方API + Gymnasium接口 | PyBullet Gym接口，社区丰富 |
| 可视化 | 内置查看器，支持离屏渲染 | OpenGL可视化，支持调试线 |
| 典型应用 | 全身控制、MPC验证、接触丰富的运动 | 快速原型、算法教学、小规模仿真 |
操作流程：从URDF到仿真部署
- 准备URDF模型：包含连杆惯性参数、关节限位、电机参数和传感器配置。
- 导入仿真环境：使用
mujoco.load_model_from_xml()或pybullet.loadURDF()加载模型。 - 配置仿真参数：设置时间步长（通常1ms）、求解器迭代次数、接触参数。
- 添加传感器：在模型中加入IMU、力传感器和关节编码器模拟。
- 编写控制接口：通过Python/C++ API发送关节力矩指令并读取状态。
# MuJoCo 加载与步进示例
import mujoco
model = mujoco.MjModel.from_xml_path("humanoid.xml")
data = mujoco.MjData(model)
for _ in range(1000):
data.ctrl[:] = compute_torque(data) # 控制指令
mujoco.mj_step(model, data) # 仿真步进案例拆解：基于MuJoCo的行走控制器验证
某团队在MuJoCo中验证MPC行走控制器。首先将真实机器人URDF导入MuJoCo，校准惯性参数和关节摩擦。然后实现MPC控制器，以1kHz频率求解优化问题，输出关节力矩。仿真中设置地面摩擦系数0.8，模拟真实地面条件。通过对比仿真与实机的关节轨迹和ZMP（零力矩点）数据，发现仿真与实机误差在5%以内，验证了控制器的有效性。该流程将实机调试时间缩短了60%。
常见误区与总结
- 误区1：仿真模型与实机参数不一致。必须进行惯性参数辨识和关节摩擦标定。
- 误区2：忽略仿真时间步长的影响。步长过大导致接触不稳定，步长过小增加计算负担。
- 误区3：过度依赖仿真结果。仿真无法完全模拟真实世界的噪声、延迟和结构柔性，需保留实机验证环节。