NikeSong/LeRobotWorkbench

如果你的团队已经在跑 LeRobot 机械臂实验，想要一个大家都能点开的统一控制台，这个项目值得看一眼；但它不是开箱即用的成品，部分模块仍是占位页，而且要求旁边已经有一套可用的 Python/ROS 环境。

解决什么问题

典型的 LeRobot 流程要在终端里层层操作：找串口、标定机械臂、遥操作、录制数据集，再启动训练和评估。每一步都有自己的参数和日志，只想围观进度的同事也得先学会这些命令。LeRobotWorkbench 把这条链路搬进浏览器：页面通过 ROS 消息总线发指令，Python 桥接层再映射成 uv run lerobot-* 调用，日志和任务进度实时回传到页面。最终得到的是一个从硬件准备到评估的统一控制台，底层命令仍然可见。

有什么不同

最关键的设计是业务通讯统一走 ROS，而不是让 Java 直接调用 LeRobot 的 Python API。后端是 Spring Boot 编排层，RosMessageBus 接口同时提供内存 mock 实现和 rosbridge websocket 实现，所以没有硬件也能把界面点通。这条 mock 路径对演示和新人上手最有用：机器人还没到位时，按钮流程可以先走一遍。代价是链路更长——浏览器到 Java、到 ROS、到 Python 桥接、再到 CLI；一旦卡住，故障可能出在任何一跳。

README 也清楚区分了现状和规划。硬件准备、数据采集、数据集、训练、评估/部署标注为“界面 + ROS 服务就绪”；数据对齐和智能标注明确写着占位、待深化。桥接目前是一个把服务调用映射成 CLI 命令的 Python 脚本，路线图打算换成正式的 rclpy ROS2 节点，并加入相机预览、时间戳校验和 VLM 自动标注。这些是方向，不是已交付能力。

谁值得试

适合：已经在跑 LeRobot、有 ROS2 加 Pixi/RoboStack 工作区的实验室或小团队，多人需要触发录制或训练并查看日志，又不想每个人都记命令。Mock 总线也让它适合在接硬件之前先把预期流程演示出来。

不适合：想要单机桌面应用控制一台机械臂的人，或者现在就需要数据对齐和自动标注的人——这两块页面虽然存在，但 README 说是占位。如果你还没准备好 LeRobot 仓库和 ROS 工作区，外围配置成本会让它成为很高的第一道门槛。

使用条件与边界

环境是分层的：需要 JDK 17+、Maven 和 uv，Python 依赖必须在仓库根目录用带 workbench extra 的方式安装。README 特别提醒，只跑 uv sync 不会装 datasets，录制会立刻报错；不过程序检测到缺失时会尝试自动补装。之后工作台会探测本机 Pixi ROS 工程（默认 ~/work/dev/ros-learn），从那里启动 rosbridge；没有本机 ROS 才退到 Docker，再没有就进 mock。这个顺序意味着 ROS 工作区缺失或路径不对时，会悄悄降级成模拟总线。

日常维护是第二项成本。你需要配置 LeRobot 仓库根目录，跟随 LeRobot CLI 变化维护桥接脚本，并保证 /lerobot 命名空间下的话题约定对桥接可用。项目没有声明许可证，组织内部采用前要先确认这一点。README 为中文，配置项在 application.yml；除 Maven 启动外，没有发布包或打包方式。

HotRepo 点评

HotRepo 从 2026-10-24 开始追踪这个仓库，2026-10-25 只记录到一次新项目榜（java 榜 #19，累计 102 星）。这是七天新项目的单日快照，不是每日增长数据，因此还无法判断热度能否持续。投入前值得先核对：Python 桥接里写的 uv run lerobot-* 命令，是否与你实际使用的 LeRobot 版本对得上——这层映射是整个集成能否成立的关键。