简介Unitree与LeRobot机器人训练测试项目资料面向机器人研究者、开源爱好者与具身智能入门者。Unitree机器人以强大运动能力见长LeRobot提供统一的训练评测框架二者结合可用于构建可复现的机器人学习流程。资源以Python源码为主共22个文件包含15个py脚本、2个Markdown文档、项目依赖配置与许可证等压缩包约43KB包体小、结构清晰。脚本涵盖数据加载、H5数据集读取、模型测试、机器人评估等模块配合README和文档目录能帮助理解从安装配置、数据采集到训练算法选择与评估的完整链路同时可掌握依赖安装、数据封装、评估工具等关键环节。已有159人学习下载适合希望复现Unitree机器人策略训练、从数据准备走到模型验证全流程并可直接阅读、修改与二次开发的进阶开发者。 如果你手里有一台宇树 Go2还想用 lerobot 这种开源学习框架做点“让狗自己学走路”的实验大概率第一步就会被卡住Go2 默认只给你一个 UDP 运动控制口而 lerobot 只认自己那套 robot 抽象类中间隔着半条 ROS2 的河。最近我把 unitree go2 ros 的桥接、lerobot 的数据采集和训练链路全部打通总算是把“走两步就偏”的模型调到了能看的程度。下面这份记录不是官方文档的搬运是我从零开始踩出来的完整链路适合手里有 Go2、又想少走弯路的机器人爱好者。先交代一下背景我这里说的 lerobot是 Hugging Face 开源的那个机器人学习工具箱主要覆盖数据采集、策略训练和模型部署Unitree 这边我主要用 Go2。两者加在一起可以直接做端到端的行为克隆给它一个第一视角相机画面它输出底盘速度和转向量不用手工写绕障逻辑全靠示范数据学出来。听起来很美好实际落地时有大量细节。下面按我自己的推进顺序来写。1. Unitree 和 LeRobot为什么非要凑一起1.1 LeRobot 在整条链路里管哪一段LeRobot 的核心是把“机械臂怎么夹杯子”这件事拆成标准流程记录人的示范动作保存成带图像和状态的数据集然后跑一个模仿学习模型最后把训练好的权重加载到机器人上实时推理。它的抽象做得不错没有把机器人绑定死在某一款品牌上而是定义了一个 robot 接口只要是符合这个接口的硬件就能接入。网上很多 lerobot 教程都在教你接桌面机械臂但接口本身是通用的四足机器人同样能套进去。所以我在考虑给四足机器人加学习能力时没打算自己写一套训练 loss 和数据处理代码而是直接复用 LeRobot 的数据集格式和训练器。对做应用的人来说这是最划算的方式你不需要成为强化学习专家也能把“感知到动作”的映射交给神经网络去学。你要做的只是把 Go2 的观测、动作和遥控信号翻译成 LeRobot 能理解的形式。这个翻译层就是后面会详细说的适配器。1.2 Unitree Go2 在 LeRobot 面前缺什么Go2 作为四足机器人运动能力已经很成熟走斜坡、过门槛都没问题但它缺的是一个“如何知道自己该去哪”的上层决策。常规做法是写状态机加局部规划把传感器信息转成速度指令。这套东西能用可规则稍微一变就得重新调参更不要说在复杂环境里处理那些没见过的边角情况。而 LeRobot 这样的模仿学习方案正好把“感知到动作”的映射直接学出来省掉大部分手工特征工程。反过来LeRobot 生态里最缺的恰恰是移动平台。它的默认场景大多是固定基座机械臂动作空间比较小。把 Go2 放进去之后动作空间就变成了“前进速度、横向速度、转向角速度”的组合机身高度这类状态可以先固定不动观测空间里再加入里程计和 IMU。这其实是很自然的一个扩展。SeedStudio 出的 lerobot 桌面套件能帮你先用小机器人理解整套流程但真要到四足移动平台上跑通信和运动学那部分还是得自己补这也是这篇文章最有价值的地方。2. 硬件链路与通信方案先把底子打扎实2.1 算力怎么分训练和推理不能抢一块卡LeRobot 训练通常需要一块 NVIDIA 显卡参数越大越吃显存。Go2 内置的算力模块不算弱但让它边跑相机、边跑模型、边处理 ROS 通信压力还是很大。我建议把整个系统拆成两段训练节点放在带 RTX 显卡的电脑上数据采集和实时推理放在挂在 Go2 背部的迷你主机上。这样分还有一个原因训练时经常要反复读数据、做数据增强如果直接在狗上训练电池续航和散热都扛不住。部署时只做前向推理一块 Jetson 系列或者稍好一点的迷你主机就够了。机载端只跑三样东西Unitree ROS2 桥、相机驱动、LeRobot inference然后通过 ROS2 topic 和底层运动 SDK 交互。别一开始想把所有东西都塞进一个小盒子先保证链路简单后面排查问题会省很多时间。我第一次就是把训练环境也装在机载端结果跑个 epoch 要十几分钟后来分开才正常。2.2 从 Go2 到 LeRobot 的通信中转站Go2 对外通信主要走 UDP官方提供的 unitree_ros2 包会在中间起一层 ROS2 节点把机器狗的状态发布成 ROS2 topic也接收上层下发的运动指令。LeRobot 适配器要做的就是订阅这些状态 topic把策略输出“翻译”成运动指令再发布回去。这条链路上最容易被忽略的是频率。策略输出一般是 10 到 30 赫兹而 Go2 的底层运动控制需要更频繁的指令才会平滑。如果你直接把 10 赫兹的速度发过去会发现狗在“一顿一顿”地走。解决办法是在桥接节点里做线性插值收到一个新动作后按 50 到 100 赫兹的频率拆成若干小步逐步逼近目标速度。同时还需要做限幅前向速度别超过 0.7 米每秒转向角速度别超过 1.5 弧度每秒第一次实机跑的时候数值越小越安全。这些限制不能写在训练端要写在部署端否则模型看到的动作范围和实际执行的范围会不一致。我第一版是既限幅又滤波结果训练的动作分布和部署的动作分布对不上模型输出变得很奇怪。后来把所有后处理统一放到底层 bridge适配器里只做简单缩放问题立刻消失。3. 从零到一环境搭建、适配和数据采集实录3.1 环境装好的第一件事先跑通 unitree ros 桥我的系统是 Ubuntu 22.04ROS2 用的 Humble。先把 unitree_sdk2 和 unitree_ros2 拉下来编译这两个包官方维护得比较勤但依赖项容易因为 DDS 实现的差异出问题。如果编译时碰到找不到某些 ament 包建议先确认 rosdep 是否已经把依赖解析完整再检查当前 shell 是否 source 了 ROS2 环境。这些看起来很小实际排查会花掉小半天尤其是同一台机器上装了多个 ROS 版本的时候。这里有个关键经验拿到桥接代码后不要一上来就连真实狗。先用官方提供的仿真模式启动ros2 topic list能看到机器狗状态再用ros2 topic pub发一条速度指令确认桥节点接收得到。这一步能帮你筛掉一堆网络配置和端口权限问题。等仿真的链路没有问题再把机器狗的 IP 和端口配进去。我见过不少朋友跳过这步结果不是发现 topic 名不对就是端口被防火墙挡了狗站在那里完全没反应。3.2 给 LeRobot 写一个 UnitreeGo2 适配器LeRobot 的 robot 抽象类要求实现几个方法最核心的是capture_observation和send_action。前者负责把当前的图像、里程计和姿态合成一个字典后者负责把模型输出的动作写进 ROS2 桥。一个能跑通的最小骨架大概是下面这个样子class UnitreeGo2Robot(Robot): def capture_observation(self): obs self.bridge.get_observation() return { image: obs[image], state: [ obs[vx], obs[vy], obs[vyaw], obs[roll], obs[pitch], ], } def send_action(self, action): vx action[0] * 0.6 # 归一化到实际速度 vy action[1] * 0.3 vyaw action[2] * 1.5 self.bridge.publish_velocity(vx, vy, vyaw)这里最关键的其实是“归一化到实际速度”那三行。训练时模型并不知道真实机器人的速度上限它只在一个归一化的动作空间里做预测。适配器里要定义一张映射表把 [-1, 1] 的动作映射到 Go2 能接受的速度范围。映射得太保守模型学到的动作会压缩在一个小范围里物理上跑不快映射得太激进实机一上来就会飞出去。我第一版把前向速度放大到了 1.0结果第一次部署差点撞墙后来缩到 0.6 才稳定。另外teleop_step主要用于数据采集阶段它要把人的遥控输入读出来并保存成示范动作。Go2 的手柄数据可以通过 ROS2 的 joy topic 拿也可以从 Unitree SDK 的遥控通道解析。建议直接复用官方遥控器输入因为狗自带的摇杆量程和运动控制接口是匹配的不用再额外校准。3.3 采集示范数据时真正影响质量的细节数据采集是这套流程里最耗精力的一环。LeRobot 的训练效果很大程度取决于示范数据的分布而不是单纯的数量。移动机器人比机械臂更难采因为人操控时手会抖相机画面会跟着晃。如果示范里经常出现快速转向模型学出来的动作就不平滑。我自己的做法是每段示范控制在 20 到 30 秒目标位置在场地里随机摆放光线方向也尽量变化总共采了 40 段左右而不是一次录满半小时。镜头方面Go2 头部的单目相机视野有限我又加了一个向下看的相机让模型能感知到脚边的障碍。两个相机的时间戳在保存前必须对齐否则训练时模型会把两帧错位的图像当成同一时刻的观测学出来的映射会产生明显抖动。如果没把握一次成功可以拿 SeedStudio 那套 lerobot 桌面套件先练手同样的数据格式、同样的训练脚本至少能把“采集-训练-加载”这套流程跑熟再切到 Go2 上就只剩硬件适配一个变量。这个建议不是广告是我实际对比后的体会。4. 训练、部署和实机验证中的那些“雷”4.1 ACT 还是 Diffusion Policy我为什么先选 ACTLeRobot 内置了好几种策略常见的是 ACT 和 Diffusion Policy。对移动平台这个任务来说动作维度只有 3 到 6 个示范数据量也不大ACT 更合适。它训练稳定输出动作曲线平滑推理速度也快。Diffusion Policy 对多模态分布的表达更强比如同一个场景可以有不同的成功走向但推理时有随机采样过程实机上容易表现出发抖。四足机器人对打滑很敏感动作稍微粗糙一点就会引发机身姿态抖动形成恶性循环。对比项ACTDiffusion Policy训练稳定性高参数容错好中等对数据敏感动作平滑性高中等实机易抖多模态表达较弱强推理速度快较慢适合数据量中小样本较大样本移动平台实测推荐需要额外平滑后来我还做过一次对比同样的 40 段示范Diffusion 成功率略高一点但动作明显粗糙尤其是原地转向的时候。最终部署我选的是 ACT。训练命令直接用 LeRobot 的 trainer 脚本指定unitree_go2_kit的 robot 类型数据集放在 lerobot 目录下然后指定 ACT 策略。跑之前把配置里的图像尺寸改小一点比如 224x224能显著加快训练对实机精度影响不大。4.2 策略输出要“翻译”成 Go2 能执行的动作指令LeRobot 训练器做数据归一化时会把动作压缩到某个区间。部署时如果直接把这个区间里的数值发给 Go2会出现两个问题一是动作曲线不平滑二是越过实际速度极限。所以桥接端必须做两层处理先缩放再插值。缩放把归一化动作映射到物理量插值把低频策略输出变成高频运动指令。这两件事必须放在模型外不能依赖模型自己学会。还有一个容易犯的错是把动作类型定义成“相对增量”。机械臂训练经常用相对动作但移动机器人最好用绝对速度指令。如果你用增量动作模型输出的每一步都代表“在当前速度基础上加一点”误差会累积最后狗会越走越偏。我最后统一把动作表示成目标速度训练和部署完全一致。部署时还要做安全监控如果策略连续输出某一个方向的极端值超过几秒直接触发保护停止或者把速度强制降到 0。这个逻辑要写在模型外面毕竟模型可能在 99% 的时间里都正常但只要有一次异常输出就足够撞墙。4.3 实机验证三步走和翻车现象实机验证不要直接拉满全场。第一步断开运动执行让模型只接收真实相机画面在电脑屏幕上打印出预测的动作曲线。这一步能发现 80% 的“模型根本没学对”问题狗可以完全不动。第二步在空旷场地把速度系数调到 0.3 以下让狗慢慢走重点看转向是否平滑、起步是否顿挫。第三步再切到正式目标场景手柄必须放在手边随时接管。整个过程看着繁琐但能省下后期大量的排查时间。我踩过最典型的翻车是“原地转圈”模型在训练目标位置 A 表现很好换到位置 B 就开始原地打转。原因是示范数据里目标物体始终在画面中央模型根本没在“走向目标”而是在“保持目标在画面中央”目标一旦偏移它就不停转向。解决方法是采集时把目标放在不同角度、不同距离甚至加一些临时遮挡让模型学会“目标在哪里就往哪里走”而不是“目标在中间就直走”。这个坑如果在仿真里做是不容易暴露的因为仿真环境太干净。最后提醒一句不管模型多好用急停开关和人工接管通道都不能省。LeRobot 这套东西本质上是在学一个条件分布它并不保证在没见过的输入上仍然收敛。四足机器人不比桌面机械臂稍微失控就可能造成硬件损伤。我现在的习惯是每次实验前先跑一遍观测模式再实机宁可多花十分钟也不赌一次。这套流程跑通之后我再接其他移动平台的第一反应都是先把通信层做干净训练管线直接交给 LeRobot真正拉开差距的是你愿不愿意把那些脏活累活做扎实。本文还有配套的精品资源点击获取