# LeIsaac: teleoperating SO101 hardware inside IsaacLab for imitation learning > A bridge between LeRobot leader arms and NVIDIA IsaacLab, covering teleoperation, HDF5 to LeRobot Dataset conversion, and policy training on simulation collected data. It grew into a general imitation learning playground, and its release cadence slowed in 2026. **LightwheelAI/leisaac** — LeIsaac provides teleoperation functionality in IsaacLab using the SO101Leader (LeRobot), including data collection, data conversion, and subsequent policy training. - Repository: https://github.com/LightwheelAI/leisaac - Website: https://lightwheelai.github.io/leisaac/ - Stars: 750 · Forks: 142 - Language: Python - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/lightwheelai-leisaac ## The gap between a leader arm and a simulated robot The problem this addresses is a broken link in the imitation learning pipeline. Collecting robot demonstrations by hand is slow and expensive, so people collect them in simulation. But a simulator gives you a robot, not a human interface, so the human ends up driving the simulated robot with a keyboard, which produces demonstrations that do not resemble how a real operator behaves. LeIsaac is the piece that connects the two. It provides teleoperation functionality in IsaacLab using the SO101Leader from LeRobot, and the robot in the simulation is the SO101Follower, along with other related robots. A physical leader arm drives the simulated follower, so the demonstration carries the natural motion of a human hand. The scope of the repository is wider than the teleoperation itself, and the project description says so plainly: teleoperation, data collection, data conversion, and subsequent policy training. Those four stages are the workflow the tooling is organised around, and the news entries show each of them gaining support over time. The intended audience is robotics engineers and researchers who already work in IsaacLab and already work with LeRobot datasets. The project is a plug-in to two larger systems rather than a standalone framework, and it acknowledges the borrowing: the acknowledgements thank IsaacLab and LeRobot for their work, from which some code was borrowed. ## Data conversion is the step that makes the data reusable Simulation data is not useful until it is in a format a training pipeline can read, and that is what the conversion scripts handle. The project offers scripts to convert data from HDF5 format to the LeRobot Dataset. HDF5 is the natural output of a simulation rollout, and it is close to unusable for a policy training stack that expects a dataset format with episodes, frames and task metadata. Converting between the two is unglamorous work, and doing it inside the project means the format assumptions live next to the code that produced the files. The more recent development is that recording can skip the conversion step entirely. The lerobot recorder integration means you can now record data directly in LeRobot Dataset format during teleoperation, so the intermediate HDF5 files are no longer required in the common path. That is a meaningful change for anyone with an existing pipeline, since the conversion step was previously mandatory. The other direction of reuse is the project being a consumer of the same dataset format rather than only a producer. The datagen module, added in March 2026, goes the other way entirely and generates motion trajectories programmatically rather than by teleoperation. The project documents it as state machine data generation, and it means a policy can be trained on synthetic trajectories without a human in the loop at all. ## Fine tuning GR00T on data that never touched a robot The end goal is stated in the project description: simulation collected data is used to fine-tune GR00T N1.5 and deploy it on real hardware, and more policies will be supported. The important word in that sentence is fine-tune. LeIsaac is not proposing to train a general policy from scratch. It is a way to produce extra demonstration data, in simulation, using a real human's motor behaviour, and add it to the training mix of an existing foundation model. The policy support has been growing. The January 2026 entry records that inference support for GR00T N1.6 was added, with details in the available policy inference documentation. The Cosmos tutorial from the same month describes a video to action data generation pipeline, which is a different input modality reaching the same training stage. The Marble tutorial from December 2025 goes the other way and is about building and evaluating diverse embodied tasks across large scale generalized environments, which is the evaluation side of the same loop. For a team, the pitch is a closed loop. Collect in simulation with a leader arm, convert or record directly to LeRobot format, fine tune a policy, evaluate in IsaacLab, and deploy to hardware. Each stage has a script or a documented path in this repository. ## LeRobot EnvHub status, and a device list you should read first As of late November 2025, LeIsaac is the official imitation learning simulation playground integrated into LeRobot's EnvHub. The project describes what that means in its own terms: fast, scalable Isaac-based environments designed for imitation learning, control and policy evaluation. It is featured in LeRobot as LeIsaac x LeRobot EnvHub, with the documentation hosted on the Hugging Face site. That integration cuts both ways. It means the environments are discoverable through an existing tool rather than only through this repository, which lowers the barrier for someone already inside the LeRobot ecosystem. It also means the environments are shaped by what EnvHub expects, so the local documentation and the hosted documentation can drift apart. The other prerequisite is the hardware. The project supports a set of teleoperation devices, and the device guide is where you confirm yours is covered. The November 2025 entry records expanded device support including an enhanced keyboard and gamepad, and the December 2025 entry records lekiwi based teleoperation support, which comes with a Loft scene provided for the community. So the honest order of operations is: check the device list, then the available robots list, then the available environments list, then the available policy list. All four are separate resources in the documentation, and all four constrain what you can do. ## Remote teleoperation and the fact that the project is moving slower The most recent feature listed is remote teleoperation, available from April 2026, with a dedicated section in the getting started documentation. That is the feature that would matter most for collecting data at scale, since the operator no longer has to sit at the machine running the simulation. The news entries are dated and they tell a story about pace. Between November 2025 and January 2026 there are six entries across four months, covering more teleoperation devices, lekiwi support, the EnvHub integration, the Lerobot recorder integration, the Cosmos tutorial, the Marble tutorial and GR00T N1.6 inference support. Then the list goes quiet after April 2026. The repository is not archived, but the last push was on 2026-04-15, which is more than six months before now. The releases line shows the same slowdown: v0.2.0 on 2025-09-10, v0.3.0 on 2025-12-19, and v0.4.0 on 2026-04-15. So the project moved quickly through 2025 and stopped moving after April 2026. That is not a criticism, and robotics simulation stacks often pause between hardware generations. But it is a fact you should plan around, particularly if you are about to build a data collection pipeline on top of it. Version 0.4.0 is the last thing anyone has published, and the citation metadata in the project names 0.4.0 as the version to cite. ## Where this approach breaks down The clearest limitation is the physical leader arm in the loop. Teleoperation with an SO101Leader requires owning the hardware, and the alternative devices on the list, a keyboard or a gamepad, produce demonstrations with different characteristics. The naturalness of the data is a property of the human interface, and a keyboard cannot provide it. The second limitation is the simulation to reality gap, and LeIsaac does not claim to close it. The project says simulation collected data is used to fine-tune a policy and then deploy it on real hardware, which is a workflow, not a guarantee about performance. The Marble tutorial is about building and evaluating tasks across generalized environments, which is exactly the machinery for measuring how far a policy generalises. If your question is how well a policy will behave on a specific real task, no amount of LeIsaac tooling answers it for you. The third is the dependency stack. IsaacLab, Isaac Sim, LeRobot and a foundation policy framework have to be installed and version matched, and the project is explicit that some code is borrowed from IsaacLab and LeRobot rather than independently maintained, which means upstream changes can ripple in. And the fourth is the pause. A pipeline built on a project whose last push was on 2026-04-15 has no upstream fixes arriving, so any IsaacLab or LeRobot update you make becomes your own compatibility work. ## Against collecting demonstrations on real hardware directly The alternative is the obvious one, and the difference is worth being concrete about. Collecting on real hardware means the demonstrations are real by construction. There is no simulation to reality gap to argue about, the robot is the robot, and the data reflects whatever friction, noise and failure modes your actual setup has. The cost is time and hardware. Every demonstration needs the robot, the space, the operator, and a reset between attempts, which is why real datasets are small and precious. Collecting in simulation inverts the cost curve. You can generate more data than you can physically record, you can reset instantly, you can vary environments programmatically, and you can tag the data with exactly the state information a trainer needs. The state machine data generation module takes this further, producing trajectories with no human involved at all. The trade is fidelity, and it is a real trade rather than a rhetorical one. A simulated demonstration contains the assumptions of whoever built the simulation: the dynamics model, the contact model, the rendering, the noise model. A policy trained on that data inherits them. That is why LeIsaac pairs teleoperation with real leader hardware instead of relying on keyboard drive. It is an attempt to keep the human motor behaviour real while keeping the rest virtual. If your problem is coverage and scale, that is the right side of the trade. If your problem is the last few percent of performance on a specific physical task, real demonstrations on the real robot remain the ground truth, and LeIsaac is a complement rather than a replacement. ## Conclusion Adopt LeIsaac if your robot fleet already speaks LeRobot, if you want to collect demonstrations in simulation without physical hardware, and if you plan to fine-tune a policy on that data. Skip it if you need a maintained project you can pin to a version, because the last push was on 2026-04-15 and the release train has slowed. Verify first that the teleoperation device you own is on the supported device list, and that the policy you want to fine-tune is on the available policy list, since both are enumerated in the project documentation rather than assumed. ## FAQ ### What is LeIsaac and what does it connect together? LeIsaac provides teleoperation in IsaacLab using the SO101Leader from LeRobot, with the SO101Follower and other robots as the simulated agents. It covers data collection, data conversion to the LeRobot Dataset, and subsequent policy training. ### Which teleoperation devices does LeIsaac support? The project supports the SO101Leader and expanded its device support in November 2025 to include an enhanced keyboard and a gamepad. It also supports lekiwi based teleoperation. The current device list is in the device guide in the project documentation. ### How do I convert simulation data into a LeRobot Dataset? The project provides scripts to convert data from HDF5 format to the LeRobot Dataset. There is also a lerobot recorder integration, released in January 2026, that lets you record directly in LeRobot Dataset format during teleoperation and skip the conversion step. ### Which policies can I fine tune with LeIsaac collected data? The project uses simulation collected data to fine tune GR00T N1.5 and deploy it on real hardware, and inference support for GR00T N1.6 was added in January 2026. The list of supported policies is maintained in the available policy documentation. ### Can LeIsaac generate training data without a person teleoperating? Yes. The datagen module, added in March 2026, generates motion trajectories programmatically and is documented as state machine data generation, which allows policy training without a human in the loop. ### How do I install LeIsaac? The project does not put installation commands in its readme, it points you at the installation and setup page of its documentation at lightwheelai.github.io/leisaac. The repository also carries a Dockerfile and a dependencies directory, and the installation page covers the required IsaacLab and LeRobot components. ## Sources - [License: Apache-2.0](https://github.com/LightwheelAI/leisaac/blob/main/LICENSE) - [LightwheelAI/leisaac on GitHub](https://github.com/LightwheelAI/leisaac) - [Project website](https://lightwheelai.github.io/leisaac/) - [README](https://github.com/LightwheelAI/leisaac/blob/main/README.md) - [Releases](https://github.com/LightwheelAI/leisaac/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lightwheelai-leisaac