[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f25a2wd3jop2bw":3},{"code":4,"message":5,"data":6,"timestamp":23},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":12,"hn_threads":14,"one_liner":15,"summary_md":16,"topic":17,"github_topics":20,"license":9,"homepage":9,"updated_at":21,"history":22},"NikeSong\u002FLeRobotWorkbench",17,null,"Java",109,7,14,[],"A browser workbench that puts LeRobot robot-arm recording, training and evaluation behind clickable UI instead of CLI commands.","LeRobotWorkbench is worth a look if your team runs LeRobot robot-arm experiments and wants a shared clickable console, but it is not a turnkey appliance: several modules are still placeholders and it expects a working Python\u002FROS environment nearby.\n\n## The problem\n\nA typical LeRobot workflow means juggling terminal commands: finding the serial port, calibrating arms, teleoperating, recording datasets, then launching training and evaluation runs. Each step has its own flags and logs, and colleagues who only want to watch progress must be taught the same commands. LeRobotWorkbench changes that: a browser UI sends commands over a ROS message bus to a Python bridge, which maps them to `uv run lerobot-*` calls, streaming logs and job progress back to the page. The result is a single console for the hardware-to-evaluation loop, with the [command layer documented](https:\u002F\u002Fgithub.com\u002FNikeSong\u002FLeRobotWorkbench) still visible underneath.\n\n## What's different\n\nThe design choice that matters is routing all business communication through ROS rather than having Java call the LeRobot Python API directly. The backend is a Spring Boot orchestrator; a `RosMessageBus` interface has a mock implementation and a rosbridge websocket implementation, so the UI can be exercised without hardware. That mock path is the real draw for demos and onboarding, since buttons can be clicked through before a robot is available. The trade-off is a longer chain: browser to Java to ROS to the Python bridge to the CLI. When something stalls, the failure could sit at any hop.\n\nThe [README](https:\u002F\u002Fgithub.com\u002FNikeSong\u002FLeRobotWorkbench\u002Fblob\u002Fmain\u002FREADME.md) also shows the split between what is real and what is planned. Hardware preparation, recording, datasets, training and eval\u002Frollout are listed as UI plus ROS service ready. Data alignment and automatic annotation are explicitly placeholders. The bridge is currently a Python script mapping service calls to CLI commands, and the roadmap wants to replace it with a proper `rclpy` ROS2 node, add camera previews, timestamp validation and VLM-based annotation. Treat those as direction, not delivered capability.\n\n## Who should try it\n\nGood fit: a lab or small team already running LeRobot with ROS2 and Pixi\u002FRoboStack, where several people need to trigger recording or training runs and watch logs without memorizing commands. The mock bus makes it also useful for demonstrating the intended flow before wiring hardware.\n\nPoor fit: someone who wants a standalone desktop app for a single arm, or who needs data alignment and auto-annotation today. Those screens exist but are described as placeholders. If you do not already have a LeRobot checkout and a ROS workspace, the amount of surrounding setup makes this a poor first entry point.\n\n## Requirements and limitations\n\nThe setup is layered: JDK 17+, Maven and `uv` are required, and Python dependencies must be installed with the `workbench` extra runs from the repository root. The README warns that plain `uv sync` omits `datasets` and recording fails immediately, though the app tries to re-run the extra install when it detects the gap. The workbench then probes a local Pixi ROS project (default path `~\u002Fwork\u002Fdev\u002Fros-learn`), starts rosbridge from it, falls back to Docker if no local ROS exists, and finally to mock. That order means a missing or misplaced ROS workspace silently downgrades you to a simulated bus.\n\nOngoing upkeep is the second cost. You need a LeRobot repository root configured, the bridge script kept in sync with LeRobot CLI changes, and the ROS topic conventions under `\u002Flerobot` available to the bridge. No license is declared, which matters before adopting it inside an organization. The README is written in Chinese and documents configuration in `application.yml`; there is no release or packaging story beyond running Maven.\n\n## HotRepo's take\n\nHotRepo first tracked this repository on 2026-10-24 and logged one NEW-REPOSITORY board observation on 2026-10-25 (java, #19, 102 total stars). That is a single dated snapshot of a seven-day-old project, not daily growth data, so persistence cannot yet be judged. Before investing, verify that the Python bridge's documented `uv run lerobot-*` commands match the LeRobot version you actually use, since that mapping is the load-bearing integration point.",{"slug":18,"name":19},"hardware","Hardware & IoT",[],"2026-10-25T03:19:23Z",[],1792912575]