宇树机器人都有哪些产品线？从 53 个开源仓库反推出的家族图谱

你想搞清楚一家机器人公司到底有哪些东西，最容易走的一条路，是去看它的官网产品页。这条路的问题在于：产品页是给采购看的，不是给开发者看的。它会告诉你这台机器很厉害，但不会告诉你这台机器你能不能编程、编程的入口在哪、官方给你留了多少接口。

有一条更笨但更实在的路：去看它的 GitHub 组织。

一家硬件公司往开源仓库里放的东西，几乎不会撒谎。因为那些代码是给自己的客户用的——写得不对，客户第一时间就会来提 issue。更重要的是，仓库的结构会暴露很多产品页上不会写的东西：哪条线是主力、哪条线只是配件、哪条线已经停更但还留着、哪些第三方硬件被官方正式接进了自家系统。

这篇我们就干这件事。样本是 unitreerobotics 这个 GitHub 组织下的公开仓库快照，一共 53 个。我们不聊任何一台机器人的性能，只从仓库结构里反推它的家族图谱。

先把话说在前面：本文全部依据公开仓库的目录结构、README 与仓库描述，没有任何真机验证，也不涉及在售状态和硬件参数。文中出现的所有型号名，都是「代码仓库里有这么一个目录或这么一个仓库」的意思，不是产品目录。

三条线索，各自说明什么

在开始翻之前，先约定读法。一家公司的仓库列表里，能反推产品线的线索主要有三类，它们的证据强度不一样。

线索一：SDK 里按型号分的目录。

这是最直接的信号。一个型号如果在官方 SDK 里有自己的目录，说明官方为它写过、也维护着专门的接口层。这条线索能证明「有官方开发支持」，但不能证明这台机器现在还在卖，更不能证明它比没有目录的型号更重要。

线索二：独立仓库。

某样东西如果重要到需要单独开一个仓库、单独一套 README 和构建流程，那它在公司内部的定位大概率是独立品类，而不是某台机器的附属配件。一个品类能撑起几个仓库，本身就是一种权重。

线索三：服务层仓库。

这是最容易被忽略、但信息量最大的一条。所谓服务层，就是那种「把某个外设翻译成系统内部消息」的小仓库。它的存在说明两件事：第一，这个位置是可插拔的；第二，官方认可了这个位置上有第三方硬件。一个封闭的系统不需要这种仓库。

好，开始翻。

主线：足式与人形，全在 SDK 的目录名里

unitree_sdk2 是官方的主力 SDK。它的两个关键目录——示例目录 example/ 和头文件目录 include/unitree/robot/——都是按型号分的。把目录名列出来：

example/            include/unitree/robot/
  a2/                 a2/
  as2/                as2/
  b2/                 b2/
  b2w/                g1/
  g1/                 go2/
  go2/                h1/
  go2w/               h2/
  h1/                 r1/
  h2/
  r1/

这十个名字（a2、as2、b2、b2w、g1、go2、go2w、h1、h2、r1）就是这套 SDK 当前覆盖的型号线。再强调一次：这是 SDK 的目录名，不是产品目录，不代表在售状态，也不含任何参数信息。

不过光是目录名的拼写规律，就已经能读出一点东西了。

go2 和 go2w、b2 和 b2w——两组名字都是「基础名 + w」。同一个基础名派生出带后缀的变体，说明这是同一条产品线上的不同构型，而不是两条独立的线。这种命名习惯在硬件公司里很常见：主型号定下来之后，变体在后面加字母。

还有一个更有意思的信号，是能力目录的命名分歧。我在拆 unitree_sdk2 架构那篇里提过：有些型号目录下的运动模块叫 sport，有些叫 loco。而 example/ 目录下，g1、h1、h2、r1 这几个都进一步分成了 high_level/ 和 low_level/ 两级，go2、b2 这些则没有这样分。

命名不一致的地方，底层往往真的不一样。接口分了两套，通常意味着控制模型分了两套——这条线索足够拉出一整篇文章，我们放在四足与人形的分野里单独讲。

另一份能交叉验证的材料是 unitree_rl_gym。这个强化学习仓库的 README 里写明支持的训练任务是 go2、g1、h1、h1_2，--task 参数的取值也是这四个。它的 resources/robots/ 目录下，对应地放着几套机器人描述文件：

resources/robots/
  g1_description/     一组区分不同关节配置的 URDF / XML 文件
  go2/                urdf/ 与 dae 网格
  h1/                 urdf/ 与 STL 网格
  h1_2/               urdf、xml 与 STL 网格

注意 g1_description/ 里不是一个 URDF，而是一整组——文件名里区分了不同的关节配置、是否锁定腰部、是否带手、是否只保留双臂。这说明同一个型号在仿真里存在多种可配置形态，训练时你要先决定用哪一种。这是个很实际的坑：模型文件选错了，训出来的策略在真机上根本对不上。

把 SDK 的目录和 RL 仓库的任务列表放一起看，会发现两边不完全重合。这是正常的——SDK 覆盖的是「能用官方接口控制」，RL 仓库覆盖的是「官方给了强化学习训练配方」，两件事本来就不是一回事。某个型号出现在 SDK 但没出现在 RL 仓库，只能说明这个仓库没提供它的训练配置，不能推断成这个型号不能用强化学习。

机械臂：四个仓库撑起来的独立品类

翻到 z1 的时候，我停了一下。因为它不是一个仓库，是四个：

z1_sdk         SDK tools for controlling z1 robot
z1_controller  控制器
z1_ros         ros package for z1 simulation
z1_joystick    用宇树手柄控制 z1

一个东西如果只是某台机器上的挂件，不会有这个待遇。SDK、控制器、ROS 仿真包、手柄遥控包——这是一条完整产品线才会有的仓库配置：底层控制一套、上层调用一套、仿真环境一套、人工操作入口一套。

尤其是 z1_controller 和 z1_sdk 分开。控制器和 SDK 拆成两个仓库，通常意味着两者跑在不同的地方、由不同的人维护：控制器贴着硬件跑，SDK 给应用开发者用。这种拆法在工业设备里很典型。

z1_ros 的描述里明确写了是 for z1 simulation——仿真。也就是说官方假设你会先在仿真里把轨迹和抓取逻辑调通，再上真机。这个假设是合理的，机械臂撞坏东西的代价比机器狗摔一跤高。如果你还不熟悉机械臂的运动学基础，可以先补一下机械臂运动学入门，再回头看这套仓库的接口设计。

机械臂这条线上还有一个更新的名字：UniArmL1，仓库描述写的是「一个轻量化的机械臂遥操作框架，支持三种控制模式与标准化数据采集」。「标准化数据采集」这几个字很关键——这说明这个框架的目标不只是让你把胳膊挥起来，而是为了产出可用于训练的数据。这个指向和后面要讲的具身智能那批仓库是连着的。

灵巧手：这里藏着整篇文章最重要的一个发现

现在看手。相关仓库有四个：

dex1_1_service        Serial2dds service for Unitree Dex1-1 Hand
dfx_inspire_service   Unitree Robot RH56DFX Inspire Hand Controller
brainco_hand_service  Serial2dds service for Brainco Revo2 Hand
linker_hand_service   serial2dds service for linker hand

第一眼你可能只注意到「宇树有灵巧手」。但真正值得停下来的是：四个仓库里，只有一个是自家的手，另外三个是第三方品牌的手。

这意味着什么？意味着在这套系统里，手是一个可替换的模块，而不是焊死的部件。

再看这些仓库的描述用词——Serial2dds service，串口转 DDS 服务。这个命名把整个机制说透了：第三方的手大多通过串口通信，官方给每一款手写一个小服务，把串口协议翻译成系统内部的 DDS 消息。翻译层做好之后，上层应用调的是统一的消息，根本不需要知道底下插的是哪一家的手。

这个判断在 SDK 内部还能找到交叉证据。include/unitree/idl/hg/ 目录下有这么两个文件：

HandCmd_.hpp     手部指令
HandState_.hpp   手部状态

手的指令和状态在 IDL 层（也就是通信消息的类型定义层）就有独立的消息类型，和 LowCmd_、MotorState_、IMUState_ 这些并列。这是标准的「独立子系统」待遇——不是把手的关节混进整机的电机数组里，而是给它单独开一组话题。

example/g1/ 目录下还有 dex3/ 和 g1_hand_sdk_example.cpp，说明手的示例代码同时存在于两个位置：一部分在主 SDK 的型号示例里，一部分在独立的 service 仓库里。

把这三条证据串起来，**「模块化的手 + 统一的消息接口 + 每款硬件一个翻译服务」**这个架构就浮出来了。这套设计的价值不在于手本身有多灵活，而在于它把「换一款硬件」的成本压到了一个小仓库的量级。这条线的细节我们在灵巧手那篇里展开。

顺带说一句，这种「服务层」的思路是可以偷来用在自己项目上的。你做一台机器，如果预见到某个位置的硬件将来会换，那就别把它的协议写进主程序，单独做一个进程去做协议翻译，主程序只认统一消息。

感知与激光雷达：两代并存

激光雷达是两个仓库：

unilidar_sdk    SDK for Unitree L1 LiDAR
unilidar_sdk2   SDK for Unitree Lidar L2

命名规律和 SDK 本身一样——新一代不覆盖旧仓库，而是开一个 2。新旧并存而不是替换，这在硬件公司是常态：老设备还在客户手里跑着，仓库删了客户就没法维护了。

围绕雷达还有一圈算法仓库：

point_lio_unilidar    Point-LIO algorithm for Unitree LiDAR products
unitree_slam          Interface for unitree slam
Python_unitree_demos  SLAM 行业应用场景的 Python 示例

Point-LIO 是一类紧耦合的激光惯性里程计算法，仓库描述写明是为宇树的雷达产品做的。再加上一个 SLAM 接口仓库和一批面向行业场景的 Python 示例，这三个凑在一起，说明感知这条线不只是卖一个传感器，而是配了从驱动到定位建图的一整条软件栈。想深入的话可以顺着雷达家族和SLAM 栈这两篇往下读。

电机与舵机：另一条容易被忽略的线

还有一组仓库，指向的既不是整机也不是传感器：

unitree_actuator_sdk               执行器 SDK
Unitree-Motor-Assistant            电机助手
unitree-motor-debugging-assistant  电机调试助手（HTML）
digital_servo                      数字舵机示例

四个仓库围着「电机」转，还专门有调试助手工具——而且其中一个是 HTML 写的，说明它是个网页形态的调试工具。执行器有独立的 SDK 和独立的调试工具，通常意味着它是可以单独拿来用的部件，不只是整机内部的零件。

这条线对 DIY 玩家的意义很大。整机的门槛高，但一颗能用官方 SDK 直接驱动的关节电机，是很多自制项目的起点。关于这类电机在结构上的位置，可以对照机器人电机选型那篇一起看。

历史型号：老仓库为什么不删

列表里有几个明显更老的名字：

laikago_ros         Laikago working with ROS
aliengo_sdk         （无描述）
UnitreecameraSDK    Unitree GO1 camera SDK
unitree_legged_sdk  SDK tools for control robots
unitree_ros_to_real
unitree_ros2_to_real  A ROS2 package you can use to control the real Go1 robot
unitree_pybullet

这些仓库还挂在组织下面，没有删。你可以把它当成一条时间线来读：从 Laikago、Aliengo 到 Go1，再到现在的 unitree_sdk2 体系，接口方式换过代——旧的那套叫 unitree_legged_sdk，走的是另一条路线，新旧之间的差异我们在SDK 一代与二代对比里讲。

老仓库留着这件事本身，说明的是一种维护态度：已经卖出去的设备，代码不能说撤就撤。对你来说这也是个实用信息——如果你手上有一台上一代设备，或者从二手渠道弄到一台，代码入口还在。

UnitreecameraSDK 是个单独的相机 SDK，说明那一代的相机是作为独立组件暴露给开发者的。这类历史仓库的读法要格外小心：它们能证明「曾经存在过这样的官方支持」，不能证明现在的状态。

开源 DIY 线：Qmini

Qmini 这个仓库和上面所有仓库都不一样。README 的原话说它是一台完全开源、可由个人完整 3D 打印的低成本双足机器人，面向爱好者、教育者和研究者，强调像搭积木一样模块化组装。

它开源了什么？README 列得很清楚：

硬件      完整 BOM、电气系统框图、DIY 说明文档（PDF）
机械结构  全部机械件的 STEP 文件、装配 SOP
软件      URDF 模型、核心软件栈（指向外部的 RoboTamer4Qmini 项目）

仓库文件树也对得上——STEP_file/ 下有两个版本的压缩包，urdf/ 下是 URDF 加一组 STL 网格，网格文件名是 LL_hip_pitch、RL_knee、LL_ankle 这样的左右腿关节命名。

一家做商用机器人的公司，为什么要开源一台可以自己打印的双足？ 我不去猜官方的战略考虑，但从工程和生态的角度看，这件事的作用是明确的：它把「亲手做一台会走路的机器」这件事的门槛，从买一台整机降到了打印加采购零件。README 里也提到软件栈用的是宇树自家的一款电机，并且给了一块常见单板机作为默认参考控制板，同时明确说开发者可以换成别的控制板。

想动手的话，Qmini DIY 那篇会把这套开源材料拆得更细。

从仓库数量分布，读它的技术重心

前面都是在读「有什么」。最后我们换个角度读「投入在哪」——办法是数一数同一个方向上有几个仓库。一个方向如果只有一个仓库，说明它是个功能；如果有四五个仓库并行，那是在下注。

方向一：强化学习。

unitree_rl_gym        基于 Isaac Gym 的训练实现
unitree_rl_lab        强化学习实现仓库
unitree_rl_mjlab      强化学习实现仓库
unitree_sim_isaaclab  基于 Isaac Lab 搭的仿真环境
unitree_mujoco        MuJoCo 相关
unitree_pybullet      PyBullet 相关

同一件事（训练一个运动策略）有多个并行的仓库，各自绑在不同的仿真后端上。这不是重复造轮子，而是在对冲仿真平台的技术路线风险——仿真器本身在换代，把身家全押在一个后端上是危险的。unitree_rl_gym 的 README 把工作流写成 Train → Play → Sim2Sim → Sim2Real 四步，其中 Sim2Sim 那一步的说法是「把在 Gym 里训好的策略放到另一个仿真器里跑，确保它没有过度依赖 Gym 的特性」。**多个仿真后端的存在，本身就是这个方法论的基础设施。**这条线我在unitree_rl_gym 那篇里做过完整拆解。

方向二：遥操作与具身智能。

xr_teleoperate              XR 遥操作
televuer                    XR 视觉与手/手柄遥操作接口
kinect_teleoperate          基于体感相机的遥操作
teleimager                  多路 UVC 相机图像服务器
unitree_lerobot             基于 LeRobot 的改造
unifolm-vla                 （无描述）
unifolm-world-model-action  （无描述）
UniArmL1                    机械臂遥操作与标准化数据采集

八个仓库，指向的是同一条链路：人来演示 → 采集数据 → 训练模型 → 机器人自己做。

teleimager 这个仓库尤其能说明问题。它的描述是「一个从多个 UVC 相机采集视频流的图像服务器」——这是纯粹的数据采集基础设施，没有任何炫技成分。一家公司愿意为「怎么把多路相机的画面稳定地收下来」单独开一个仓库，说明数据采集这件事已经从副产品变成了正事。

unitree_lerobot 的描述写的是「对 LeRobot 开源项目的改造」，这是往社区通用的数据与训练框架上靠。unifolm-vla 从名字看指向视觉-语言-动作方向，unifolm-world-model-action 指向世界模型方向——这两个仓库没有公开描述，我不去猜它们的具体能力，但名字本身摆在这里，方向是清楚的。想先补概念的话，具身智能是什么和 VLA 模型这两篇是入口。

方向三：应用与生态。

unitree-app-templates  App Templates for Unitree App Store
unibot_submission      UniBot Challenge 的资源
unitree_model          机器人模型仓库
unitree_cad            （无描述）
Publications           官方发表的论文
logging-mp             轻量级 Python 日志工具

出现「App Store 的应用模板」这种仓库，说明这套系统上有第三方应用分发的设计。unibot_submission 对应的是一个挑战赛。Publications 这个仓库的存在则说明公司在维护自己的学术产出记录。这几个都不是核心技术仓库，但它们共同指向一件事：生态位的经营已经在做了。

把三个方向的仓库数量摆在一起看，结论就出来了：强化学习和具身智能这两块，占了整个组织公开仓库里相当大的比例，而且是并行下注而非单点押注。至于底层的通信和 SDK，只有一套主力加若干配套——基础设施已经收敛，前沿方向还在发散。这是一家技术公司处在特定阶段时很典型的仓库形态。

这套方法怎么用到别的公司身上

回过头看，我们从头到尾没打开过一台机器，也没跑过一行代码，就把一家公司的产品版图和技术重心画了个七八成。这套动作是可以照搬的：

1. 先把仓库列表按名字前缀分组。 同一个前缀下的多个仓库（z1_*、unitree_rl_*、unilidar_sdk*）会自动聚成产品线，这一步基本不用动脑子，但信息量最大。
2. 找主力 SDK，读它按型号分的目录。 这是唯一能确认「官方开发支持覆盖了哪些型号」的硬证据。同时记住这条线索的边界：它证明不了在售状态，也证明不了型号之间的高低。
3. 专门找「service」「bridge」「adapter」这类词。 它们标记的是系统的可插拔位置，往往能反推出整套架构的模块边界——比灵活性宣传语可靠得多。
4. 数方向上的仓库个数。 一个方向一个仓库是功能，四五个仓库并行是下注。数量分布就是投入方向的指示器。
5. 别删掉老仓库不看。 历史仓库能拉出一条技术路线的演进时间线，也能告诉你这家公司对已售设备的维护态度。
6. 看仓库描述里的动词和名词。 「标准化数据采集」「串口转 DDS」「for simulation」这类短语，每一个都是设计意图的直接证词，比任何二手分析都近。

最后再把边界重复一遍，因为这是这类分析最容易翻车的地方：仓库结构能证明「官方做了什么」，不能证明「机器能做什么」。 某个型号目录下没有某个模块，只能说明这套 SDK 没暴露这项能力，绝不能推成「这个型号做不到」。分析到哪儿就写到哪儿，剩下的交给官方文档和真机。

接下来的路线是这样的：想从架构层继续深挖，去看unitree_sdk2 架构拆解；想从零补机器人基础，机器人与具身智能卷里从机器人的组成开始更稳；本卷的其余文章都挂在卷 U 的目录页上。