Evo-RL packages an offline real-world RL loop for SO101 and PiPER arms

The loop the pipeline is built around

Evo-RL is described as open source real-world offline RL on the SO-101 and the AgileX PiPER, released for easier reproduction. The pipeline is broken into numbered stages in the README, and the order tells you what the project actually is.

Data collection comes first, then value function training, then value inference, then policy training, and finally a closed-loop rollout and next round. That ordering is the substantive claim of the project. The value function stage sits between the dataset and the policy, and the README describes the visualisation assets as value overlays on recorded episodes, including a success case and a failure case, plus policy rollout results and human-in-the-loop results.

The stated focus is threefold: opening real-world RL pipelines on two platforms, releasing runnable code, models and datasets so others can reproduce results, and reproducing existing real-world RL methods while proposing new ones. The repository description names the target platforms as SO101 and AgileX with the PiPER and PiPER-X variants.

This is not a general purpose RL library. It is a pipeline aimed at a specific class of robot, with the artefacts to back it: a project website, a paper on arXiv at 2610.13345, and a dataset called RW-RL published on Hugging Face.

The news entries give a sense of the order of development. The first SO101 real-world RL baseline and reproducible CLI workflow came on 2026-02-26, AgileX support for PiPER and PiPER-X was added on 2026-03-07, and a detailed Hugging Face dataset card for the RW-RL Dataset was added on 2026-06-30.

LeRobot is the base, not an optional dependency

The README states the choice plainly: LeRobot is used as the base of this codebase because its inference and data-collection logic are highly aligned with real-world RL workflows.

You can see that alignment in the package metadata rather than taking it on trust. The pyproject.toml in this repository declares the project name as lerobot at version 0.4.4, requires Python 3.10 or newer, and points its homepage, documentation, source and issue links at the LeRobot project and its Discord. The README badge also pins LeRobot 0.4.4.

That is a significant fact for anyone evaluating the project. Evo-RL is a distribution layer on top of LeRobot rather than an independent implementation, and it inherits LeRobot's configuration surface, its CLI conventions and its dataset format. The pip install command in the installation section installs this repository in editable mode, and the setup guide then directs you to the official LeRobot configuration guide for setup details and platform specific dependencies.

So the mental model for adoption is: you get LeRobot, plus a value function stage, plus offline RL training scripts, plus closed-loop rollout tooling, plus the published data and models.

The repository layout matches that description. Under src you have the package itself, examples holds twelve separate directories including backward_compatibility, dataset, lekiwi, phone_to_so100, port_datasets, rtc, so100_to_so100_EE, training, tutorial and unitree_g1, and there are also benchmarks, docker, docs, tests and website directories, with requirements-ubuntu.txt, requirements-macos.txt and requirements.in for platform specific dependencies.

Installing and verifying the hardware before any training

The installation is a short sequence that creates a conda environment and installs the package in editable mode.

git clone https://github.com/MINT-SJTU/Evo-RL.git
cd Evo-RL
conda create -y -n evo-rl python=3.10
conda activate evo-rl
pip install -e .

Hardware setup is where most of the friction is, and the README is unusually specific about device paths. For the robot serial it recommends /dev/serial/by-id/ because those paths are stable across reboots. For cameras it prefers /dev/v4l/by-id/, and falls back to /dev/v4l/by-path/ when the IDs are not unique. The examples use by-id for robot ports and by-path for camera paths.

You can list the available stable paths before configuring anything.

ls -l /dev/serial/by-id/
ls -l /dev/v4l/by-id/
ls -l /dev/v4l/by-path/

After setup, the README gives a single command to confirm the system is ready.

lerobot-teleoperate \
  --robot.type=so101_follower \
  --robot.port=/dev/serial/by-id/<SO101_FOLLOWER_PORT> \
  --robot.id=my_so101_follower \
  --teleop.type=so101_leader \
  --teleop.port=/dev/serial/by-id/<SO101_LEADER_PORT> \
  --teleop.id=my_so101_leader

Single-arm users need no major changes. For dual-arm setups, the README recommends mirroring the mechanical parts corresponding to servos 4/5/6 on the left leader and left follower arms, which it says usually gives a more natural bimanual feel. The dual-arm case needs its own calibration layout, with files for left and right under both robots and teleoperators.

calibration/
├── robots
│   └── so_follower
│       ├── bi_so101_follower_left.json
│       └── bi_so101_follower_right.json
└── teleoperators
    └── so_leader
        ├── bi_so101_leader_left.json
        └── bi_so101_leader_right.json

Those files live under ~/.cache/huggingface/lerobot/calibration/, and the README notes this layout is slightly different from the single-arm setup.

What the value function stage adds

The value function is the part that distinguishes this pipeline from a plain behaviour cloning workflow, and the README gives it its own stage with its own visualisation assets.

The stages are listed as value function training, then value inference, then policy training. Value inference being a separate stage means the trained value function is applied to something after training, and the accompanying assets show the value overlaid on recorded episodes with separate success and failure examples. The overlays make the value function inspectable: you can see where the model believed a task was going well and where it did not, rather than only seeing the action it chose.

The human-in-the-loop results are also given their own visual results section, separate from the plain policy rollout results. That suggests the pipeline includes a mode where a person intervenes during rollout, which is a normal requirement in real-world robot learning because the physical platform can fail in ways a dataset does not anticipate.

What the README does not give is a metric, a benchmark number, or a comparison against another method. The benchmark directory exists in the repository and the focus section mentions publishing data and benchmarks to grow a collaborative community, but no performance claim is stated in the documentation, so the honest way to judge the method is to read the paper and to run the pipeline yourself rather than to expect a leaderboard in the README.

The project explicitly says it reproduces existing real-world RL methods and proposes new ones, so treat the code as a research platform with a baseline in it rather than as a settled method.

Where this pipeline is the wrong tool

The clearest limitation is hardware. Every stage of this pipeline assumes a physical low-cost arm, cameras, and a teleoperation setup with calibration files. There is no simulator path in the documented stages, so if your goal is to iterate on an offline RL algorithm without hardware, this is not the project to start from.

The second limitation is the dependency chain. The README requires you to complete the SO-series setup tutorial in detail, including all installation and configuration steps, before continuing, and it sends you to the official LeRobot configuration guide for platform specific dependencies. The examples directory also shows that this is a young and moving target, with a backward_compatibility directory and a unitree_g1 directory suggesting that adapting the pipeline to other platforms is ongoing work rather than a settled feature.

The third is that the documentation contains no comparison. The README describes what the pipeline does and what has been released, and it lists a benchmarks directory in the repository, but it states no metric, no baseline number and no comparison against another method. So you cannot judge the approach from the README alone. The paper on arXiv and the RW-RL Dataset are where the evidence lives, and running the pipeline yourself is the only way to check that a release reproduces.

Fourth, the repository publishes no GitHub releases. Pinning a working state means pinning a commit, and the last push was on 2026-10-16.

How it compares with working inside LeRobot directly

The alternative is to use LeRobot on its own. LeRobot already provides the data collection, the policy training and the evaluation loops, so the honest comparison is not feature by feature but about the one stage Evo-RL adds.

If your goal is imitation learning from demonstrations, LeRobot gives you that today, and Evo-RL adds machinery you would not use: the value function training and inference stages, the value overlays, and the human-in-the-loop rollout mode. If your goal is to push on offline RL for real arms, where you want a learned value signal and an inspectable per-episode value estimate, then that added stage is the reason to take this repository rather than the upstream one.

There is a cost to that choice, and it is the dependency chain described above. Working inside Evo-RL means tracking a repository built on top of a pinned LeRobot version, 0.4.4, whose own upstream is moving. The examples directory covers ten platform and workflow variants, and each one is a place where the two projects can drift apart.

The other alternative is not a software choice at all. For reproducing published results, the RW-RL Dataset on Hugging Face and the paper on arXiv are the primary artefacts, and the code is how you check that you can reproduce them. If you only want the data, you do not need to install this repository at all.

Editorial conclusion

Evo-RL fits a robotics group that already has SO100 or SO101 hardware, or an AgileX PiPER, and wants an offline real-world RL pipeline with published data, models and a value function step rather than a policy trained only in simulation. It does not fit someone starting from scratch on hardware, since the setup depends on completing the LeRobot configuration guide and the SO series tutorial first, and it does not fit a simulation-only project, since the examples include real arms. Before running anything, follow the official LeRobot installation and platform setup steps, confirm your robot and camera paths under /dev/serial/by-id/ and /dev/v4l/by-id/ rather than raw device names, and check that your calibration files exist under ~/.cache/huggingface/lerobot/calibration/ with the dual-arm layout before starting a bimanual run.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MINT-SJTU/Evo-RL on GitHub
4. README