该系统本质上不是传统的“机器人自己规划路线”，而是一套：

人体动作采集 + 实时遥操作 + 动作重定向 + 全身平衡控制 + 示教数据训练

系统，它要解决的核心问题不是“机器人从哪里走到哪里”，而是：

人做出一个动作后，怎样让结构不同、质量不同、平衡能力不同的机器人，安全、稳定、尽可能相似地完成这个动作。

宇树目前公开的 G1/H1 开发生态中，已经包含 XR 遥操作、SDK2、ROS 2、MuJoCo、Isaac Lab 和强化学习等工具。官方 xr_teleoperate 项目用于人形机器人遥操作和数据记录；SDK2 基于 Cyclone DDS 实现机器人状态获取与控制；MuJoCo 和 Isaac Lab 仿真工具则支持控制程序验证、数据回放和策略部署。(GitHub)

---

一、先建立整个系统的总体认识

整个系统可以分为六个核心层级。

┌─────────────────────────────┐
│ 1. 人体动作采集层            │
│ 动作捕捉服、IMU、人体骨骼模型 │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│ 2. 数据通信与预处理层         │
│ UDP、Wi-Fi、时间戳、滤波、校准 │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│ 3. 动作重定向层              │
│ 人体骨架 → 机器人关节和末端    │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│ 4. 全身控制与平衡层           │
│ 关节控制、质心控制、足底接触    │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│ 5. 宇树机器人执行层           │
│ SDK2/DDS、机载计算机、电机控制  │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│ 6. 数据记录与策略训练层        │
│ 模仿学习、强化学习、仿真验证    │
└─────────────────────────────┘

这六层并不是简单单向运行，而是一个闭环。

机器人执行动作后，会不断返回：

• 当前关节角度；

• 关节速度；

• 电机状态；

• 机身姿态；

• 足底接触；

• IMU 数据；

• 控制状态

控制程序再根据这些反馈修正下一时刻的动作。

因此，准确的整体结构是：

人体动作
   ↓
人体姿态估计
   ↓
动作重定向
   ↓
机器人目标动作
   ↓
机器人闭环控制
   ↓
机器人实际动作
   ↓
状态反馈
   └────────返回控制器继续修正

---

二、第一层：人体动作采集

1. 动作捕捉服到底采集什么

操作员穿戴动作捕捉服后，服装上的多个传感器分别固定在：

• 胸部；

• 腰部或骨盆；

• 上臂；

• 前臂；

• 手腕；

• 大腿；

• 小腿；

• 足部；

• 有时还包括头部和手指

大多数惯性动作捕捉服使用 IMU。每个 IMU 通常包含：

• 加速度计；

• 陀螺仪；

• 有时还有磁力计

这些传感器本身并不会直接告诉电脑“人的肘关节弯曲了 30 度”

它们最初提供的是：

• 当前加速度；

• 当前旋转速度；

• 重力方向；

• 磁场方向。

动作捕捉系统需要通过姿态融合算法，把这些原始数据转换成身体各个骨段的方向。

---

2. 动作捕捉系统输出的不是人体照片，而是数字骨架

最终传给电脑的通常是一个人体数字骨架。

例如：

骨盆：
位置 = (x, y, z)
方向 = 四元数

胸部：
方向 = 四元数

左上臂：
方向 = 四元数

左前臂：
方向 = 四元数

右大腿：
方向 = 四元数
……

电脑中看到的不是完整人体，而是一组连接起来的骨骼节点。

          头
          │
     左肩─胸部─右肩
       │   │   │
     左肘  腰  右肘
       │   │   │
     左手 骨盆 右手
          / \
       左髋  右髋
        │     │
       左膝  右膝
        │     │
       左脚  右脚

每一个骨段都有自己的方向数据。

---

3. 为什么必须进行穿戴标定

动作服每次穿到人身上时，传感器的位置和方向都会略有不同。

例如：

• 左前臂传感器可能向外偏了 10 度；

• 胸部传感器可能没有完全水平；

• 操作员的肩宽和臂长不同；

• 鞋上的传感器方向可能不同。

所以系统启动后通常需要操作员做标准姿态，例如：

• T 形站立；

• A 形站立；

• 双脚平行站立；

• 手臂自然下垂。

这一步的作用是建立：

传感器方向
      ↓
人体骨段真实方向

之间的偏差关系。

如果不标定，常见结果包括：

• 人抬手，机器人手臂向侧面旋转；

• 人保持站立，机器人腰部已经倾斜；

• 左右手方向相反；

• 人的肘部弯曲映射成机器人肩部旋转。

所以标定不是附加步骤，而是整个系统的基础。

---

三、第二层：数据通过 UDP 和 Wi-Fi 进入电脑

1. Wi-Fi 和 UDP 不是同一个东西

可以把通信过程理解为邮寄包裹。

• Wi-Fi 相当于运输道路；

• IP 相当于地址系统；

• UDP 相当于运输规则；

• 动作数据相当于包裹里的内容；

• DDS 或自定义协议相当于包裹的格式和分类方式。

整体层次如下：

人体骨骼数据
      ↓
自定义消息 / DDS消息
      ↓
UDP
      ↓
IP网络
      ↓
Wi-Fi 或有线以太网

Wi-Fi 决定数据通过无线方式发送。

UDP 决定发送时不建立复杂可靠连接，而是快速地将一帧一帧数据发出去。

---

2. 为什么实时动作通常使用 UDP

人体动作是连续产生的，例如每秒：

• 30 帧；

• 60 帧；

• 100 帧；

• 甚至更高。

在实时控制中，“最新数据”通常比“保证每一帧都收到”更重要。

例如，人正在挥手。

如果网络丢失了第 101 帧，但已经收到第 102、103 和 104 帧，那么再等待第 101 帧重传通常没有意义，因为第 101 帧已经过时。

因此 UDP 的特点反而适合动作流：

• 传输开销小；

• 不等待确认；

• 不因某个旧数据包丢失而阻塞后面的新数据；

• 延迟通常比较低。

但 UDP 不保证：

• 数据一定到达；

• 数据按顺序到达；

• 数据不会重复；

• 数据不会损坏；

• 数据频率稳定。

所以这些问题必须由你们自己的程序处理。

---

3. 每一帧动作数据应该包含什么

一个合理的动作数据包通常应包含：

数据包版本
机器人或操作员编号
当前帧序号
动作采集时间戳
人体根节点位置
各个骨段姿态
关节置信度
校验信息

其中最重要的是帧序号和时间戳。

帧序号

例如：

1001
1002
1003
1005

电脑看到 1004 不见了，就知道发生了丢包。

时间戳

时间戳告诉电脑：

这帧动作是什么时候采集的，而不是什么时候收到的。

因为某一帧可能在网络中停留时间更长。

如果不使用时间戳，程序无法区分：

• 人动作真的突然变慢；

• 网络延迟突然增大；

• 某帧数据晚到了。

---

4. 网络链路的实际逻辑

你们的系统可能存在两段通信。

第一段：

动作捕捉服
    ↓ UDP/Wi-Fi
控制电脑


第二段：

控制电脑
    ↓ SDK2 / DDS / UDP-IP
宇树机器人

宇树 SDK2 提供请求响应和发布订阅式接口，SDK2 和 ROS 2 主要使用 Cyclone DDS 进行通信；Python SDK 同样支持机器人状态订阅和控制命令发布。(GitHub)

因此不要把整个系统简单理解成：

动作服直接控制电机

实际情况更接近：

动作服发送人体信息
        ↓
电脑理解人体动作
        ↓
电脑计算机器人应该怎么动
        ↓
电脑通过宇树接口发送机器人命令

---

四、第三层：数据预处理

动作数据收到以后，不能立刻发送给机器人。

至少需要经过以下处理。

收到人体动作数据
        ↓
检查帧序号和时间戳
        ↓
丢弃过期帧或重复帧
        ↓
坐标系转换
        ↓
穿戴标定修正
        ↓
滤波和异常检测
        ↓
形成稳定的人体姿态

---

1. 坐标系转换

动作捕捉服和机器人通常不使用同一个坐标定义。

动作捕捉系统可能定义：

X：向右
Y：向上
Z：向前

宇树机器人程序可能定义：

X：向前
Y：向左
Z：向上

如果不进行坐标转换，那么：

• 人向前伸手，机器人可能向上抬手；

• 人向左转，机器人可能向右转；

• 人弯腰，机器人可能后仰。

所以程序需要明确三套坐标系：

动作捕捉世界坐标系
        ↓
人体骨盆或躯干坐标系
        ↓
机器人基座坐标系

每一层都要进行方向转换。

---

2. 四元数连续性

人体骨段方向通常用四元数表示。

四元数有一个特殊性质：

q 和 -q 表示同一个空间方向

动作捕捉设备有时会在相邻两帧之间从 q 跳到 -q。

从物理姿态看没有发生变化，但如果程序直接对数字做插值，就可能认为人体突然旋转了很大角度，因此必须做四元数连续性处理，简单理解就是：

每收到一帧姿态，都要判断它与上一帧是否走了“最短旋转方向”。

---

3. 滤波

人体动作数据会有轻微抖动。

抖动来源包括：

• IMU 噪声；

• 传感器绑带松动；

• 人体自然震颤；

• 无线网络抖动；

• 磁场干扰；

• 姿态融合误差。

如果直接传给机器人，机器人手臂和电机可能不停做小幅高频修正。

滤波的目标是：

保留真实动作
      +
去除无意义抖动
      +
尽量不增加明显延迟

滤波太弱：

• 机器人抖动；

• 电机频繁调整；

• 运动不自然。

滤波太强：

• 人已经抬手，机器人过一会才抬；

• 快速动作被削弱；

• 机器人感觉“黏滞”。

所以实时遥操作最重要的不是滤得最平滑，而是找到：

平滑性与响应速度之间的平衡。

---

4. 异常值检测

必须识别明显不合理的数据，例如：

• 某关节一帧跳变 90 度；

• 四元数全部为零；

• 数据包含 NaN；

• 人体骨架突然消失；

• 根节点位置突然跳到几米外；

• 时间戳回退；

• 数据包长度错误。

发现异常后，不能把它直接发送给机器人。

通常处理方式是：

轻微异常
  ↓
使用上一帧或插值补偿

连续异常
  ↓
机器人平滑减速

长时间无数据
  ↓
机器人进入安全姿态或停止

---

五、第四层：人体动作重定向

这是系统最核心、也是最难的一层。

1. 什么叫动作重定向

动作重定向不是简单复制人体关节角，而是：

在保留人体动作意图和整体外观的同时，将动作转换成符合机器人结构、关节限制和平衡要求的机器人动作。

人体和 G1/H1 的结构存在明显差异。

人体                        机器人

肌肉和柔性关节              电机和刚性关节
肩胛骨可自由活动             肩部自由度有限
脊柱有大量小关节             腰部自由度有限
脚趾可以参与平衡             机器人足底结构固定
人体比例因人而异             机器人连杆固定
人可通过微小肌肉调整平衡       机器人依赖控制算法

因此，不能直接进行：

人体左肩角度 = 机器人左肩角度

---

2. 动作重定向的三种基本思路

方法一：关节直接映射

把人体关节和机器人关节一一对应。

人体肩关节 → 机器人肩关节
人体肘关节 → 机器人肘关节
人体髋关节 → 机器人髋关节
人体膝关节 → 机器人膝关节

优点：

• 实现简单；

• 计算快；

• 延迟小；

• 适合初步测试。

缺点：

• 人与机器人关节轴不一致；

• 手的位置未必准确；

• 容易超过机器人关节范围；

• 无法自动保证平衡；

• 肩、腰、腕部动作容易失真。

适合：

• 单关节测试；

• 上肢简单动作；

• 系统通信验证。

---

方法二：末端位姿映射

不强求每一个关节角都与人相同，而是重点让机器人的：

• 手；

• 脚；

• 头；

• 骨盆；

• 胸部

到达与人体相似的位置和方向。

例如，人把右手伸到身体前方。

系统并不是问：

人的每个肩关节角是多少？

而是问：

人的手相对于胸口在哪里？机器人怎样调整肩和肘，才能让手到达相似位置？

然后通过逆运动学计算机器人关节。

人体右手位置和方向
          ↓
按人体与机器人尺寸缩放
          ↓
生成机器人右手目标
          ↓
逆运动学
          ↓
机器人肩、肘、腕关节角

这种方法通常比直接复制关节角更合理。

---

方法三：全身优化重定向

这是效果更好的方法。

系统同时考虑：

• 双手位置；

• 双脚位置；

• 头部方向；

• 胸部方向；

• 骨盆方向；

• 机器人关节范围；

• 自碰撞；

• 动作连续性；

• 机器人平衡。

其思路可以理解为：

人体动作目标
      ↓
机器人尝试多个可行姿态
      ↓
比较哪个姿态：
  手最接近人体
  脚最稳定
  关节不超限
  身体不碰撞
  动作最平滑
      ↓
选择综合最优姿态

这不是简单求一个关节角，而是在多个要求之间做平衡。

---

六、人体尺寸与机器人尺寸的差异

假设操作员手臂长 70 cm，而机器人手臂长 55 cm。

人把手伸到距离肩部 65 cm 的位置，机器人显然不能完全照搬。

因此，必须做比例映射。

人体肩到手的相对位置
        ↓
根据人体臂长归一化
        ↓
乘以机器人臂长
        ↓
生成机器人手部目标

类似地，还要处理：

• 肩宽差异；

• 躯干长度差异；

• 腿长差异；

• 髋宽差异；

• 操作员身高差异。

需要注意，动作缩放并不是简单地把所有位置乘同一个比例。

例如：

• 手臂按臂长缩放；

• 双手间距按肩宽缩放；

• 脚步距离按腿长和稳定范围缩放；

• 躯干倾角通常不能完全按比例复制。

---

七、关节限制与自碰撞

人体可以完成的动作，机器人未必可以完成。

例如：

• 人的肩部可以通过肩胛骨扩大运动范围；

• 人能把手放到背后；

• 人的腰部可进行复杂扭转；

• 人可以交叉双臂；

• 人的手腕灵活度通常高于部分机器人结构。

机器人必须限制：

关节最小角度
关节最大角度
最大运动速度
最大加速度
最大允许力矩

同时还要检查：

• 左手是否碰到胸部；

• 右臂是否穿过身体；

• 双膝是否相撞；

• 手是否碰到头；

• 手臂是否碰到腰部；

• 两只手是否互相碰撞。

因此动作重定向结束前，需要经过机器人模型验证。

人体动作
   ↓
初步机器人姿态
   ↓
关节限位检查
   ↓
自碰撞检查
   ↓
速度和加速度检查
   ↓
输出安全目标

---

八、动作平滑和轨迹生成

动作捕捉每一帧给出的是一个离散目标。

例如 60 Hz 时，每隔约 16.7 ms 得到一个人体动作。

机器人不能只把这些离散目标直接连接起来，因为：

• 网络时间间隔并不完全均匀；

• 人体数据有噪声；

• 某些帧可能丢失；

• 目标变化可能超过电机能力。

因此电脑还要将离散动作转换成连续轨迹。

人体离散姿态帧
  帧1 帧2 帧3 帧4
    ↓
时间对齐
    ↓
插值和平滑
    ↓
速度限制
    ↓
加速度限制
    ↓
连续机器人轨迹

这里的核心目标不是重新规划一条复杂路径，而是：

让机器人在两个连续人体动作之间，平稳、安全地过渡。

---

九、第五层：全身控制与平衡

动作重定向只能告诉机器人“希望做什么姿势”。

但它不能保证机器人不会摔倒。

例如，人向右侧倾斜。

人可以通过：

• 脚趾用力；

• 脚踝调整；

• 髋部补偿；

• 快速迈步；

• 上肢摆动

维持平衡。

机器人没有完全相同的身体能力。

因此机器人控制器还必须决定：

• 骨盆应该放在哪里；

• 躯干允许倾斜多少；

• 双脚如何受力；

• 膝盖应该弯曲多少；

• 是否需要迈步；

• 上肢动作是否需要缩小。

---

1. 支撑区域

机器人双脚站立时，两只脚与地面的接触区域形成支撑区域。

俯视图

┌────────┐       ┌────────┐
│ 左脚   │       │ 右脚   │
└────────┘       └────────┘

两脚及中间区域形成支撑范围

机器人整体重心如果过度偏离该区域，就有倾倒风险。

因此人体做大幅倾斜动作时，系统通常不能完全复制，而是需要：

• 缩小躯干倾角；

• 调整骨盆；

• 弯曲膝盖；

• 移动脚步；

• 减弱手臂动作。

---

2. 上肢动作与下肢平衡解耦

实际工程中，一种常见而安全的做法是：

操作者直接控制：
双臂
双手
头部
有限腰部动作

机器人自主控制：
骨盆稳定
双腿
双脚接触
站立平衡
必要的迈步

也就是：

人控制动作意图，机器人控制自己的身体稳定。

宇树官方 XR 遥操作说明中也包含由运动控制程序继续控制下半身、通过 DDS 接口执行双臂遥操作的模式。这表明在实际系统中，上肢遥操作和下肢运动控制可以分开处理。(GitHub)

这种架构比直接把人体全身关节全部强行映射给机器人更安全。

---

3. 全身控制器的职责

全身控制器可以看作一个协调者。

它同时接收：

上层给出的手部目标
上层给出的头部目标
上层给出的躯干目标
机器人当前关节状态
机器人当前身体姿态
双脚是否接触地面

然后协调：

• 哪些关节优先完成手部动作；

• 哪些关节用于保持平衡；

• 哪些动作需要缩小；

• 哪些关节不能继续运动；

• 是否需要通过迈步恢复稳定。

---

十、控制优先级

人形机器人中，不同任务的重要程度不同。

一般可以理解为：

最高优先级：
不能摔倒
不能发生严重碰撞
不能超过电机和关节限制

第二优先级：
双脚稳定接触
身体姿态稳定
骨盆和质心合理

第三优先级：
手、头、腰部跟踪人体动作

第四优先级：
动作外观尽量与人体完全一致

也就是说：

当“完全模仿人”和“保持机器人稳定”发生冲突时，必须优先保证机器人稳定。

例如人突然快速弯腰，机器人可能只执行一部分弯腰动作。

这不是控制失败，而是安全控制在主动限制不稳定动作。

---

十一、第六层：机器人底层轨迹跟踪

经过动作重定向和平衡修正后，系统得到机器人目标关节状态。

例如：

左肩目标角度
左肘目标角度
右肩目标角度
右肘目标角度
腰部目标角度
……

但电机当前状态未必等于目标状态。

所以机器人内部还有一个快速闭环控制器。

目标关节状态
        ↓
与当前关节状态比较
        ↓
得到跟踪误差
        ↓
控制器计算电机命令
        ↓
电机运动
        ↓
编码器返回最新状态
        └────继续修正

这个闭环的运行频率通常要比人体动作采集频率高得多。

例如：

动作捕捉：60 Hz
上层动作重定向：50～100 Hz
机器人控制循环：数百 Hz 或更高

这里的具体频率取决于机器人接口、控制模式和你们使用的软件版本，不能仅根据型号统一假定。

---

十二、SDK2、DDS 和机器人控制接口

宇树 SDK2 的作用是为上层程序提供机器人通信接口，例如：

• 订阅机器人状态；

• 读取关节状态；

• 获取 IMU；

• 发布控制命令；

• 调用机器人服务；

• 进行高层或低层控制。

SDK2 使用 Cyclone DDS 建立发布—订阅通信机制；官方 Python SDK 保持了与 SDK2 类似的接口，可通过请求响应或 Topic 发布订阅完成状态获取和控制。(GitHub)

可以把 DDS 理解成一个数据总线：

机器人状态主题：
joint_state
imu_state
motor_state

控制程序订阅这些主题
        ↓
计算下一步动作
        ↓
向控制主题发布：
joint_command
arm_command
motion_command

---

十三、网络异常时机器人应该怎么办

无线网络不可能始终稳定。

可能出现：

• 短时丢包；

• 延迟突然增加；

• 数据乱序；

• Wi-Fi 断开；

• 控制电脑程序崩溃；

• 动作捕捉服掉线。

所以系统必须设计状态机。

                 ┌────────────┐
                 │ 正常控制状态 │
                 └─────┬──────┘
                       │
            收不到新数据或数据异常
                       ↓
                 ┌────────────┐
                 │ 短时保持状态 │
                 │ 保持并平滑减速│
                 └─────┬──────┘
                       │
                 持续超时
                       ↓
                 ┌────────────┐
                 │ 安全恢复状态 │
                 │ 回归安全姿态 │
                 └─────┬──────┘
                       │
                 严重异常
                       ↓
                 ┌────────────┐
                 │ 阻尼/急停状态│
                 └────────────┘

---

1. 为什么不能一直保持最后一帧

假设最后一帧动作是：

• 抬起左腿；

• 身体向右倾斜；

• 双臂快速挥动。

此时网络断开。

如果机器人永久保持最后一帧命令，可能失去平衡。

正确策略应该根据超时时长逐步处理。

短暂超时：
保持最近目标并降低速度

中等超时：
停止跟随新动作，恢复站立姿态

长时间超时：
进入阻尼、锁定或安全停机

---

2. 心跳机制

控制电脑应定期向机器人发送心跳。心跳不代表动作，而是告诉机器人：

控制程序还在正常运行。

机器人或机载程序持续检测：

最近一次心跳距离当前时间多久

超过阈值就进入安全状态。

动作数据包本身也可以作为心跳，但单独设计控制状态和心跳通常更加清晰。

---

十四、实时遥操作与训练不是同一件事

这是非常容易混淆的地方。

1. 实时遥操作

实时遥操作是：

人现在动
   ↓
机器人现在跟着动

特点：

• 人必须持续在线；

• 动作由当前人体姿态决定；

• 重点是低延迟和稳定跟踪；

• 不一定使用神经网络训练。

---

2. 示教数据采集

示教采集是：

人控制机器人完成任务
       ↓
把整个过程记录下来

记录内容通常包括：

• 人体动作；

• 机器人目标动作；

• 机器人实际动作；

• 相机图像；

• 机器人 IMU；

• 足底接触；

• 任务结果；

• 时间戳。

宇树官方 xr_teleoperate 提供数据记录模式；unitree_lerobot 也明确将 G1 遥操作作为采集自定义数据集的一种方式。(GitHub)

---

3. 策略训练

训练阶段使用已经记录的数据，让模型学习：

看到什么状态
      ↓
应该输出什么动作

训练完成后可能形成：

• 动作跟踪策略；

• 操作任务策略；

• 视觉—动作策略；

• 行走策略；

• 全身协调策略。

---

4. 部署执行

部署后，机器人可以不再完全依赖动作服。

实时遥操作：

人体动作 → 机器人动作


训练后自主执行：

机器人传感器 + 任务指令
             ↓
         已训练策略
             ↓
         机器人动作

所以“采集人的动作并训练到机器人身上”实际上包含两个阶段：

第一阶段：人教机器人
第二阶段：机器人自己执行

---

十五、训练数据应该怎样记录

不能只保存人体关节数据。

正确的数据结构应同时保存：

同一时刻 t：

人体骨架姿态
机器人目标关节
机器人实际关节
机器人身体姿态
机器人关节速度
足底接触状态
相机图像
任务状态
网络延迟与丢包情况

可以理解为：

┌─────────────────────────┐
│ 时间戳 t                 │
├─────────────────────────┤
│ 人做了什么               │
│ 程序希望机器人做什么      │
│ 机器人实际上做了什么      │
│ 机器人看到了什么          │
│ 机器人是否稳定            │
│ 任务是否成功              │
└─────────────────────────┘

如果只记录人的动作，模型不知道：

• 机器人是否成功跟上；

• 是否发生滑动；

• 是否接触物体；

• 是否失去平衡；

• 相机中当时看到了什么。

---

十六、时间同步是训练质量的关键

假设：

• 人体动作采集延迟 20 ms；

• 相机延迟 80 ms；

• 机器人关节状态延迟 5 ms。

如果简单地按电脑接收顺序保存，可能出现：

保存的人体动作：已经伸手
保存的相机图像：手还没有伸出
保存的机器人状态：正在伸手一半

这些数据在时间上不一致。

模型会错误地学习：

看到旧图像时，应该输出未来动作。

因此应尽量统一时间轴。

动作服时间戳 ─┐
相机时间戳   ─┼─→ 时间对齐 → 训练样本
机器人时间戳 ─┘

时间同步通常比单纯提高采样频率更重要。

---

十七、为什么需要仿真

动作数据或训练策略不能直接部署到真机。

因为可能存在：

• 左右关节方向写反；

• 零位错误；

• 关节角超限；

• 动作速度过快；

• 机器人自碰撞；

• 足部打滑；

• 质心失稳；

• 策略输出异常。

宇树官方提供基于 SDK2 的 MuJoCo 仿真项目，允许将 SDK2、ROS 2 和 Python SDK 控制程序接入仿真；Isaac Lab 项目也采用与真机一致的 DDS 通信方式，用于数据采集、回放、生成和模型验证。(GitHub)

推荐流程是：

人体动作数据
      ↓
离线动作重定向
      ↓
仿真机器人回放
      ↓
检查：
关节限位
自碰撞
足底接触
身体平衡
      ↓
训练策略
      ↓
仿真扰动测试
      ↓
悬挂真机测试
      ↓
低速站立测试
      ↓
正常真机运行

---

十八、整个系统最容易出现的技术问题

1. 动作方向错误

原因通常是：

• 坐标轴定义不同；

• 左右手坐标系混淆；

• 四元数顺序错误；

• 旋转乘法顺序错误；

• T-pose 标定错误。

---

2. 机器人动作抖动

可能原因：

• IMU 噪声；

• Wi-Fi 抖动；

• 滤波不足；

• 目标更新频率不稳定；

• 关节控制增益过高；

• 动作重定向解在不同姿态之间跳变。

---

3. 机器人动作明显滞后

可能原因：

• 动作捕捉服内部滤波延迟；

• 网络缓冲过大；

• 程序串行执行；

• 逆运动学计算过慢；

• 多次滤波；

• Wi-Fi 拥塞；

• 使用旧帧排队处理。

实时控制程序应优先处理最新帧，而不是把所有旧帧依次执行完。

---

4. 人动作正常，但机器人容易摔倒

原因通常不是动作捕捉精度，而是：

• 直接复制下肢动作；

• 没有质心约束；

• 足底接触未建模；

• 躯干倾角过大；

• 动作速度超过平衡控制能力；

• 上肢快速运动产生较大惯性；

• 下肢控制与上肢目标冲突。

---

5. 仿真正常，真机效果差

这是仿真到现实差异造成的。

真实机器人存在：

• 摩擦；

• 电机延迟；

• 关节间隙；

• 地面柔软度；

• 传感器噪声；

• 电池电压变化；

• 结构柔性；

• 实际负载变化。

所以训练时通常需要：

• 随机化质量；

• 随机化摩擦；

• 随机化控制延迟；

• 加入传感器噪声；

• 随机化地面条件；

• 限制策略输出。

宇树官方强化学习项目目前支持 G1、H1 和其他平台，为策略训练与部署提供了公开基础。(GitHub)

---

十九、推荐的软件模块结构

┌────────────────────────────────┐
│ 模块1：动作捕捉接收             │
│ UDP接收、数据解析、帧号和时间戳   │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块2：人体姿态预处理            │
│ 标定、坐标转换、滤波、异常检测     │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块3：动作重定向                │
│ 人体骨架到机器人骨架、逆运动学     │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块4：安全动作生成              │
│ 限位、自碰撞、速度限制、动作平滑    │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块5：全身和平衡控制             │
│ 骨盆、质心、足底、上肢动作协调      │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块6：宇树通信                  │
│ SDK2、DDS、状态订阅和控制发布      │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块7：安全状态机                │
│ 心跳、超时、恢复站立、阻尼、急停    │
└───────────────┬────────────────┘
                ↓
┌────────────────────────────────┐
│ 模块8：数据记录                  │
│ 人体、机器人、图像、任务和网络数据   │
└────────────────────────────────┘

建议这些模块相互解耦。

例如 UDP 接收线程不应同时负责：

• 求逆运动学；

• 写硬盘；

• 控制电机；

• 处理相机。

否则某个耗时操作就可能阻塞全部系统。

---

二十、最终完整逻辑框图

┌──────────────────────────────────────┐
│             人体操作员               │
│ 穿动作捕捉服，完成示教或实时动作       │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│           动作捕捉与骨骼解算          │
│ IMU采样 → 姿态融合 → 人体数字骨架      │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│             数据封装                 │
│ 帧号、时间戳、根节点、骨段姿态、置信度  │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│          UDP/IP + Wi-Fi传输          │
│ 低延迟发送，允许少量丢包，不等待旧帧    │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│            控制电脑接收              │
│ 丢包检测、乱序检查、时间同步、异常检测   │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│            人体姿态预处理            │
│ 坐标转换、穿戴校准、滤波、四元数连续性   │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│              动作重定向              │
│ 人体骨架 → G1/H1骨架                  │
│ 尺寸缩放、末端映射、逆运动学            │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│             动作安全修正             │
│ 关节限位、自碰撞、速度和加速度限制      │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│          全身控制与平衡控制           │
│ 手臂跟踪人体，骨盆和下肢维持稳定        │
│ 必要时缩小动作或生成恢复动作            │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│          SDK2 / Cyclone DDS          │
│ 发布控制命令，订阅机器人实时状态        │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│            G1/H1底层控制器           │
│ 关节控制、电机驱动、IMU和足底反馈       │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│             机器人实际运动            │
└──────────────────┬───────────────────┘
                   ↓
        ┌────────机器人状态反馈─────────┐
        │                              │
        └────→ 控制器修正下一时刻动作 ←──┘


同时进行数据记录：

人体动作
机器人目标动作
机器人实际状态
相机图像
IMU与足端接触
任务成功情况
网络延迟与丢包
        ↓
数据清洗和时间对齐
        ↓
模仿学习或强化学习
        ↓
MuJoCo / Isaac Lab仿真验证
        ↓
真机部署

---

二十一、用一句话理解每一层

层级	它解决的问题
动作捕捉	人现在做了什么
网络通信	怎样快速把人体动作送到电脑
数据预处理	收到的数据是否准确、连续、及时
动作重定向	机器人怎样做出与人相似的动作
安全约束	这个动作机器人能不能安全完成
平衡控制	机器人做动作时怎样不摔倒
底层跟踪	电机怎样准确执行目标动作
数据记录	人是怎样教机器人的
策略训练	机器人怎样逐渐学会自己完成
安全状态机	通信或算法异常时机器人怎样停下来

最终，可以把你们系统的核心逻辑浓缩为：

人做动作
   ↓
动作服测出人体姿态
   ↓
电脑理解人体动作
   ↓
把人体动作变成机器人可行动作
   ↓
机器人平衡控制器对动作进行安全修正
   ↓
通过SDK2和DDS发送给宇树机器人
   ↓
机器人电机执行
   ↓
状态反馈给电脑
   ↓
持续修正并记录为训练数据

最重要的认识是：

UDP 和 Wi-Fi 只负责“把数据送过去”；动作重定向决定“机器人应该做什么”；全身控制和平衡控制决定“机器人能不能安全做出来”；底层闭环控制决定“机器人实际做得准不准”。