宇树 G1/H1 人形机器人动作捕捉与实时模仿系统-开发者社区

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

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

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

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

宇树目前公开的 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 只负责“把数据送过去”；动作重定向决定“机器人应该做什么”；全身控制和平衡控制决定“机器人能不能安全做出来”；底层闭环控制决定“机器人实际做得准不准”。