外观
解读Unitree G1 产品页5 天前
宇树G1/H2全栈拆解：23至43DoF硬件反差与SDK2状态机互斥避坑
从23DoF基础版到43DoF EDU版的构型差异揭示了人形机器人研发与交付的边界，本文结合CycloneDDS SDK2与RL Gym实测，解析Sim-to-Real部署中的控制权仲裁陷阱与真机复现痛点。
宇树 G1宇树 H1宇树 H2宇树 Go2unitreerobotics-unifolm-vlm-baseunitreerobotics-unifolm-er-1Unitree SDK2 Pythonunitree_sdk2unitree_rl_gymunitree_mujocounitree_lerobot
一分钟速览
- 硬件构型断层： 宇树 G1 基础版仅23 DoF，EDU版选配达43 DoF；宇树 H2 固定31 DoF且额定负载7kg。这种自由度与负载的非线性分布，决定了同一套RL策略无法跨机型零样本迁移，必须针对关节拓扑重新定义动作空间。
- SDK2控制权陷阱： unitree_sdk2 的
motion_switcher服务采用互斥锁机制，SelectMode接口无返回载荷。真机部署自主算法前，必须通过CheckMode显式核验当前是否处于ai模式，否则运动指令将被底层状态机静默丢弃。 - RL环境版本锁死： unitree_rl_gym 强依赖 Isaac Gym 1.0rc4 与 Python 3.8~3.10，不兼容 3.11+；而 unitree_lerobot 要求 PyTorch 2.x + CUDA 12.x。两套框架环境完全隔离，切勿尝试在同一虚拟环境中混合安装。
- Sim资产一致性校验： 官方 unitree_mujoco 提供G1 23DoF MJCF，但Menagerie存在29DoF版本。Sim-to-Real部署时必须核对URDF/MJCF的自由度定义与真机固件版本一致，否则关节映射错位将导致真机启动瞬间过流保护或失控。
材料说明
本文所有技术参数均源自宇树官方GitHub仓库（unitree_sdk2, unitree_rl_gym, unitree_mujoco等）、产品结构化数据库及Wiki实操记录。G1/H2的DoF、负载、续航等指标为官方标称值；SDK2状态机行为基于G1 EDU真机实测Wiki；RL框架兼容性来自仓库pinned_versions声明。租金与价格数据仅作市场参考，不构成采购建议。文中未提及的“端到端大模型实车成功率”、“非官方改装方案”等均不在材料覆盖范围内，严禁 extrapolation。
- 23~43 DoF G1基础版与EDU版自由度跨度达20个关节，直接决定操作能力上限与控制算法复杂度
- API ID 1001 motion_switcher CheckMode接口ID，真机切换控制权后必须调用此接口复核状态
- Isaac Gym 1.0rc4 unitree_rl_gym唯一支持的仿真器版本，不兼容新版Isaac Sim或Python 3.11+
- 7 kg / 15 kg H2额定与峰值负载分离标定，持续作业需按7kg设计，瞬时抓取才可触及15kg上限
硬件构型断层：23DoF与43DoF并非简单加减法
在人形机器人选型与算法开发中，最致命的认知误区是将同一型号的不同配置视为同质化平台。宇树 G1 的结构化数据明确显示，其基础版为 23 DoF，而EDU版通过选配可扩展至 43 DoF。这20个自由度的差异绝非简单的“解锁更多关节”，而是代表了两种截然不同的机构学范式与控制论挑战。
基础版23 DoF构型主要覆盖双足行走与基础手臂摆动，其膝关节最大扭矩标定为 90 N.m，整机含电池重量约 35 kg，站立尺寸1320×450×200mm。这一构型的设计目标是高动态 locomotion 验证与轻量级交互，其控制策略的动作空间（Action Space）维度较低，适合在 unitree_rl_gym 中进行快速步态迭代。然而，当开发者试图将基础版上训练的“抓取”策略迁移至EDU版时，会发现额外的腕部旋转、手指驱动或腰部冗余关节改变了整个动力学链。EDU版可选配Orin等高算力模块以支撑高维感知与灵巧操作，但其手臂最大负载仍限定在约 3 kg，这意味着即便自由度增加，末端执行器的力控带宽并未同比提升。
相比之下，宇树 H2 采用了固定的 31 DoF 构型，整机含电池重约 70 kg，站立高度1820mm。其核心差异在于负载能力的工程化标定：官方明确区分了 额定负载 7 kg 与 峰值负载 15 kg。这一分离标定揭示了电机热管理与减速器疲劳寿命的真实边界——在连续作业场景下，控制策略必须以7kg为约束进行规划，15kg仅适用于毫秒级的瞬态冲击吸收。若开发者在仿真中以15kg作为常态训练目标，真机部署时将面临电机过热降频或关节保护性停机。
| 参数 | G1 基础版 | G1 EDU (Max) | H2 基础/EDU |
|---|---|---|---|
| 总自由度 | 23 DoF | 23~43 DoF | 31 DoF |
| 整机重量(含电) | ~35 kg | ~35 kg | ~70 kg |
| 手臂负载 | ~2 kg | ~3 kg | 7kg (额定) / 15kg (峰值) |
| 核心算力 | 8核CPU | 可选Orin | i5/i7/Thor可选 |
| 电池容量 | 9000 mAh | 9000 mAh | ~3h续航 |
此外，宇树 H1 作为全尺寸前辈，基础版仅 19 DoF，重47kg，移动速度达3.3m/s。其腿部采用髋3+膝1+踝1的经典5DoF构型，与G1/H2形成代际差异。开发者在复用H1的locomotion策略时，必须注意G1/H2可能引入的踝部横滚或腰部俯仰自由度对ZMP稳定性判据的改变。仿真资产方面，官方 unitree_mujoco 仓库提供了G1 23DoF MJCF与H2 MJCF，但MuJoCo Menagerie中存在29DoF的g1.xml。工程铁律： 在Sim-to-Real部署前，务必通过 rostopic echo 或SDK2状态读取接口确认真机实际激活的关节数，并与仿真模型逐关节比对，任何URDF/MJCF与固件的不匹配都将导致坐标变换矩阵错位，引发真机启动瞬间的剧烈抖动或过流保护。
SDK2状态机互斥：motion_switcher的隐性契约
从ROS 1时代的unitree_legged_msgs迁移至 unitree_sdk2 / Unitree SDK2 Python，开发者面临的不仅是API名称的变更，更是底层通信范式从“话题广播”向“CycloneDDS服务化”的根本转型。SDK2基于CycloneDDS构建，其核心设计理念是状态机的强互斥性与控制权的显式仲裁。这一点在G1/H2的高层运动控制中体现得尤为残酷。
根据 wiki/g1-motion-mode-switching 的真机实操记录，motion_switcher 服务（服务名：motion_switcher，API版本1.0.0.1）是整机运动控制权的唯一网关。该服务提供三个核心方法：CheckMode() (API ID 1001)、SelectMode(name) (API ID 1002) 和 ReleaseMode() (API ID 1003)。这里隐藏着一个极易踩坑的工程细节：SelectMode 和 ReleaseMode 的底层返回对象中不携带数据载荷。这意味着，当你调用 SelectMode("ai") 并收到成功返回码时，仅代表“请求已被接收”，并不代表“控制权已成功切换”。
在真机运行自主导航或强化学习策略前，工程师必须遵循以下原子操作序列：
- 调用
CheckMode()查询当前模式； - 若返回值非目标模式（如
{'form': '0', 'name': 'ai'}），则调用SelectMode("ai")； - 立即再次调用
CheckMode()进行复核，直到确认模式字段确实变为ai。
省略第3步是导致“代码跑通但机器人不动”的头号原因。因为G1/H2的底层 sport 服务（在Python SDK中封装为 LocoClient，服务名同为 sport）内部维护了一个有限状态机（FSM）。正常行走状态下FSM ID通常为 802（通过 GetFsmId() API ID 7001 获取）。如果 motion_switcher 未真正释放 normal 模式或未成功切入 ai 模式，sport 服务会静默丢弃所有外部发来的速度或关节指令，且不会抛出异常。这种设计是为了防止多节点争抢控制权导致的肢体冲突，但对调试极不友好。
此外，SDK2的环境兼容性极为严苛。unitree_sdk2 C++版仅支持Ubuntu 22.04 LTS + GCC 9.4.0+，不支持Windows原生环境（WSL2可兼容但不推荐用于实时控制）；Unitree SDK2 Python 明确要求Python 3.10+，且暂不支持macOS。更关键的是，SDK2完全不支持ROS 1，如需接入ROS生态必须使用ROS 2 Humble及以上版本。对于习惯在Noetic环境下开发的团队，这是一次强制性的技术栈升级。建议在项目初始化阶段即锁定Ubuntu 22.04 + ROS 2 Humble + Python 3.10的标准容器镜像，避免因系统库版本漂移导致的DDS通信丢包或序列化失败。
RL训练框架分裂：Gym与LeRobot的环境隔离墙
宇树开源生态中存在两套定位迥异、环境完全互斥的训练框架，开发者必须根据任务类型做出非此即彼的选择，切勿尝试融合。
unitree_rl_gym 是面向运动控制（Locomotion） 的经典强化学习框架。其核心依赖是 Isaac Gym 1.0rc4，这是一个已停止更新的旧版GPU物理仿真器。该框架的 pinned_versions 明确声明仅支持 Python 3.8~3.10、PyTorch 1.12+ 与 CUDA 11.3+。关键边界： 它完全不兼容Python 3.11及以上版本，也不支持新版Isaac Sim或Isaac Lab。这是因为Isaac Gym 1.0rc4的Python绑定使用了已弃用的ABI接口。如果你的主机环境是最新的Ubuntu 24.04或conda默认安装了Python 3.11，pip install 阶段就会报错。解决方案是使用专用的Docker容器或conda环境，严格锁定Python 3.10与CUDA 11.3。该框架适配Go2、H1、G1，主要用于训练步态恢复、地形适应等底层策略，输出的是低维MLP或CNN策略网络。
unitree_lerobot 则是面向具身智能（Embodied AI） 与模仿学习的新一代框架。它基于HuggingFace LeRobot修改，专为VLA（Vision-Language-Action）模型的数据采集、微调与部署设计。其环境要求与rl_gym截然相反：Python 3.10+、PyTorch 2.x、CUDA 12.x。该框架目前主要适配G1人形机器人，支持从遥操作数据采集（配合 xr_teleoperate）到ACT/Diffusion Policy训练的全流程。它不依赖Isaac Gym，而是侧重于真实世界数据的处理与Transformer架构的微调。
| 特性 | unitree_rl_gym | unitree_lerobot |
|---|---|---|
| 核心用途 | Locomotion RL训练 | VLA/Imitation Learning |
| 仿真器 | Isaac Gym 1.0rc4 | 无内置物理仿真(侧重Real) |
| Python版本 | 3.8 ~ 3.10 (禁3.11+) | 3.10+ |
| PyTorch | 1.12+ | 2.x |
| CUDA | 11.3+ | 12.x |
| 适配机型 | Go2, H1, G1 | G1 (主), 其他待扩展 |
| 部署链路 | ONNX/TensorRT导出 | LeRobot Hub / 端侧推理 |
复现坑点： 许多开发者试图在一个环境中同时安装两者以实现“RL预训练+IL微调”。这是徒劳的。PyTorch 1.x与2.x的CUDA运行时库冲突，Isaac Gym与PyTorch 2.x的二进制不兼容，都会导致环境崩溃。正确的工程实践是建立两个完全隔离的开发环境：一个unitree-loco环境专攻rl_gym，另一个unitree-vla环境专攻lerobot。两者之间仅通过策略权重文件（.pt/.onnx）或数据集（parquet/mp4）进行交互，绝不共享Python包路径。
Sim-to-Real资产对齐：URDF版本与传感器配置的隐式耦合
仿真与真机的“数字孪生”程度，直接决定了Sim-to-Real迁移的成功率。在宇树生态中，仿真资产的版本管理比代码本身更易出错。官方 unitree_mujoco 仓库提供了经过验证的MJCF模型，例如 unitree_robots/g1/g1_23dof.xml 与 unitree_robots/h2/h2_mujoco.xml。这些模型与SDK2的关节映射表严格对齐。然而，第三方仓库如MuJoCo Menagerie中存在 g1.xml (29 DoF) 等变体。这些模型可能来源于早期原型机或特定定制版，若误用于23 DoF基础版G1的策略训练，会导致仿真中多余的6个关节在真机上找不到对应执行器，进而引发状态估计发散或力矩分配错误。
传感器配置的仿真同样需要祛魅。宇树 G1 标配深度相机、3D LiDAR与4麦克风阵列；宇树 H2 则配备宽视场双目相机与麦克风阵列。但在 unitree_mujoco 的基础仿真中，LiDAR与深度相机通常以理想化的Ray Sensor或RGB-D Camera插件形式存在，并未模拟真实传感器的噪声模型、FOV遮挡、多径效应或曝光延迟。例如，G1的深度相机在强光或黑色物体表面会产生空洞，而仿真中的完美点云会让避障策略过拟合。工程师在Sim-to-Real迁移时，必须在仿真中主动注入传感器噪声、丢帧模拟与外参扰动，否则真机部署时会出现“仿真中丝滑绕障，真机前撞墙”的典型Gap。
此外，xr_teleoperate 工具虽支持G1/H1/H2全系列遥操作，但其依赖ROS 2 Humble与特定的XR设备驱动。在Windows宿主机上使用WSL2运行时，USB设备透传是常见瓶颈。若XR手柄或头显的USB直通不稳定，会导致遥操作指令出现百毫秒级抖动，采集到的演示数据质量下降，直接影响后续IL训练效果。建议在数据采集阶段优先使用原生Ubuntu 22.04主机直连XR设备，仅在纯算法开发阶段使用WSL2。
商业交付与开发成本的隐性账本
技术参数之外，商业交付条件构成了工程落地的硬约束。宇树 G1 官方商店标价 13,500美元（基础版）至 21,500美元（Pro版），不含税运；EDU版需联系销售，证券时报引述京东首发价为9.9万元人民币。这一价格区间使其成为高校与初创公司可负担的研发平台。但需注意，低价不等于低门槛。基础版23 DoF缺失灵巧手与腰部冗余，若研究目标是复杂操作，后期自行加装第三方末端执行器的机械接口、电气通信与动力学辨识成本可能超过本体价格的30%。
宇树 H2 基础版标价 29,900美元，显著低于H1的90,000美元。H2的31 DoF与7kg额定负载使其更适合工业巡检与服务场景验证。但其70kg的重量与1820mm的身高，意味着运输、搬运与安全围栏搭建成本远高于G1。租赁市场数据显示，H2日租价约 8,999元，G1日租价约 3,899元（擎天租2026-10-09报价）。对于仅需短期验证Demo的团队，租赁可能是比购买更理性的选择，尤其是考虑到人形机器人迭代周期极快，购入即贬值的风险较高。
开发成本的另一面是时间。SDK2从ROS 1迁移的学习曲线、rl_gym环境配置的排错耗时、motion_switcher状态机调试的试错成本，都应纳入项目排期。材料显示，SDK2与rl_gym均不支持Windows原生环境，这意味着团队必须全员切换至Linux工作流。对于习惯Windows/Mac开发的团队，初期1-2周的环境适配与肌肉记忆重建是不可避免的沉没成本。建议在立项前预留专门的“基础设施搭建Sprint”，而非将其压缩在算法开发周期内。
已经验证与覆盖的事实
- SDK2状态机可控： Wiki实测证实通过CheckMode+SelectMode+CheckMode三步法可可靠切换G1运动控制权，sport服务FSM ID 802为正常行走基准。
- RL训练链路闭环： unitree_rl_gym与unitree_lerobot均提供完整Python接口与示例配置，支持从仿真训练到真机部署的全流程，文档与代码同步更新。
- 仿真资产官方验证： unitree_mujoco仓库提供的23DoF G1与31DoF H2 MJCF模型与SDK2关节映射一致，可作为Sim-to-Real的可信起点。
- 遥操作数据采集可行： xr_teleoperate支持G1/H1/H2全系列XR遥操，配合unitree_lerobot可完成VLA所需的高质量演示数据采集与格式转换。
尚未证明或需警惕的工程边界
- 跨DoF策略不可迁移： 材料未提供任何23DoF与43DoF G1之间的策略迁移验证，不同构型间动作空间与动力学参数差异巨大，禁止直接复用权重。
- 传感器噪声未建模： unitree_mujoco未包含真实LiDAR/深度相机的噪声、遮挡与延迟模型，直接使用仿真感知数据训练的策略真机部署必然失效。
- Windows/macOS原生不支持： SDK2、rl_gym、lerobot、xr_teleoperate均明确不支持Win/Mac原生环境，WSL2存在USB透传与实时性风险，不建议生产使用。
- 峰值负载非持续能力： H2的15kg峰值负载仅为瞬态指标，材料未给出持续时间与热管理约束，连续作业必须按7kg额定值设计，否则触发电机保护。
上手卡 · 环境隔离、状态机核验与资产对齐清单
- 环境隔离 创建两个独立conda/env：
unitree-loco(Py3.10+CUDA11.3+IsaacGym1.0rc4)与unitree-vla(Py3.10+CUDA12+PyTorch2.x)，绝不混装。 - 状态机核验 每次下发运动指令前，强制执行CheckMode→SelectMode→CheckMode三步序列，确认返回name字段为目标模式后再发送sport指令。
- 资产对齐 下载unitree_mujoco官方MJCF后，用
mjcf.parse打印关节列表，与真机unitree_sdk2py读取的joint_state.name逐字比对，禁用Menagerie变体。 - 负载保守设计 H2/G1连续作业策略的力矩/负载上限按额定值（7kg/3kg）设定，峰值仅用于碰撞缓冲，训练reward函数中加入热累积惩罚项。
带走一句
宇树G1/H2的开发不是开箱即用，而是建立在严格的环境隔离、状态机显式核验与仿真资产精确对齐之上的系统工程，忽视任一边界都将导致真机部署失败。
本站说明
- 所有DoF、负载、续航、价格数据均来自宇树官方结构化数据库与GitHub仓库README，租金数据引自擎天租与36氪公开报道，仅作市场行情参考。
- SDK2状态机行为描述基于G1 EDU真机Wiki实操记录，不同固件版本可能存在API ID或模式名称差异，请以本机
unitree_sdk2py源码常量为准。 - RL框架版本号取自各仓库pinned_versions字段，社区fork或第三方适配版不在本文讨论范围，环境配置请严格遵循官方指定版本以避免二进制不兼容。
来源
本页事实对应的公开页面，以原文为准。
- Unitree G1 产品页访问 2026-10-12
- Unitree G1 遥控器文档访问 2026-10-12