Two algorithms, a different name on PyPI, and a licence field that says nothing

The package you install is not named after the repository

The install section opens with a command that does not contain the words you would expect.

pip install rsl-rl-lib

The repository is called one thing, the module you import is called something else again, and the distribution you install is a third. All three are documented, so nobody is hiding anything, but a reader who types the obvious name from the repository URL gets a package-not-found error and has no way to guess the right one.

The development path is the conventional one, so the discrepancy only bites people installing from a package index, which is most people.

Two smaller naming points. The short description differs between the readme and the packaging metadata, describing a fast and simple implementation of learning algorithms for robotics in one and RL algorithms implemented in PyTorch in the other. And the citation file at the repository root exists alongside a BibTeX block in the readme, so there are two citation mechanisms for the same paper.

Two files declare a licence, the readme is silent, and the metadata is empty

This project's licence signals do not agree, and the disagreement is worth knowing about because the library is otherwise carefully packaged.

The packaging metadata declares a permissive three-clause BSD licence. The build script carries the same declaration as a machine-readable licence identifier in its header. There is a licence file at the repository root, and the packaging configuration lists both that file and a directory of dependency licence texts as the files that carry licensing information.

And the repository's own licence field is empty, meaning nothing could be determined from it. The readme has no licence section at all.

So the practical position is that the terms are unambiguous in two files that any packager or scanner will read, and invisible in the one field that repository metadata tools and index listings tend to trust.

The dependency licence directory is the part that deserves credit rather than criticism. Keeping a generated snapshot of your dependencies' licence texts is a practice most libraries skip, and it is what lets someone answer the question this section is about without guessing.

Copyright is held by a university and a hardware vendor together

The build script's header carries a copyright line naming two organisations, one a university and one a hardware vendor, over a span of years that starts before either of the current maintainers was probably working on it.

That combination is unusual for a library whose pitch is minimalism, and it says something about what this code is. It is research code that came out of an academic group and out of a commercial robotics company, and it is now maintained by two people whose addresses are at the university rather than at either of the copyright holders.

Read that as governance information. There is no company behind this library to guarantee its maintenance, and no single institution that owns it either. The maintainer list and the copyright list are different people, which is normal in research code and worth knowing when you are deciding whether to depend on it.

The project's own answer to that question is the adoption list, which is the next thing worth reading.

The feature list is two algorithms wide

The key features section has four bullets, and one of them is about code size rather than capability.

The first is a minimal, readable codebase with clear extension points for rapid prototyping. The second is robotics-first methods. The third is high-throughput training with native multi-GPU support. The fourth is proven performance in numerous research publications.

Now read the second bullet closely, because it is the one people skim. It names exactly two methods: a policy optimisation algorithm, and a teacher-student distillation scheme. Two.

For a reinforcement learning library that is an unusually narrow surface, and it is consistent with the first bullet rather than in tension with it. The argument is that you will read the loop and modify it, not that you will find your algorithm in a menu.

The fourth bullet is the weakest claim in the file. Numerous publications is not a list, and none are named, so the reader has to take it on trust or go looking. The citation block does point at a specific paper, which is a better anchor than the claim deserves.

Four adopters, and they span two competing simulator ecosystems

The adoption list is four entries long, and each names what the adopter is built on. That parenthetical is the valuable part.

Two of them are built on NVIDIA's simulator stack: one on the current generation of it, and one on the older generation that the current one replaced. Two are built on MuJoCo instead, one through a WebAssembly-compiled path and one through a different acceleration path that also mentions Warp.

So this library is not tied to one physics engine. It is used on both sides of the most significant split in robot simulation, and it is one of the few libraries that spans them.

It also inherits both couplings. If you adopt it because your framework sits on one simulator, you have adopted that framework's simulation choices along with it, and the list gives no guidance on which entry to model your work on. Note that the same acceleration technology appears in both MuJoCo entries, which suggests the two projects share more than a language.

Two ONNX libraries in the runtime dependencies explain how a policy leaves Python

Two of the runtime dependencies are an export format and its compiler, and that is not an accident of convenience.

Robot policies get trained in Python and then have to run somewhere else: on a controller, in a vehicle, in a simulator running at control rate, or on hardware that has no Python at all. A tensor library cannot do that job. A serialised graph can, which is why the export path is a dependency rather than an optional extra.

So a training library carrying two export libraries in its core requirements is making a statement about its own scope: the path from a training run to something deployable is part of the library, not something you add afterwards.

The rest of the dependency list tells you the same story about the other end. A tensor-dictionary library at the core, which is how rollouts and batches are shaped, and a version-control library, which is the least predictable entry in any robotics dependency list and the one a reader is most likely to have a question about.

Dependency floors from 2017 and 2025 in the same list

The dependency list is short and mostly floors are recent, with one exception that stands out.

The deep learning framework is floored at a recent release, and the tensor-dictionary library alongside it. The array library, however, is floored at a version from the middle of the last decade, which is the kind of floor a project sets once in its first year and never revisits.

It is harmless in practice, because the deep learning framework will constrain the array library anyway. It is informative as a signal: this list was written once, and the entries that mattered then were the ones that got updated when the framework moved.

The optional extras are a better guide to intent than the core list. Experiment tracking is optional, in two flavours, while the built-in logging dependency is not. That is a deliberate split: you should not have to install a tracking service to run a training loop, but you should be able to. The test extra is a single package, which is also the smallest test surface this repository advertises.

Editorial conclusion

rsl_rl suits a robotics researcher who wants to read and modify the learning loop rather than configure someone else's, and who is already inside one of the four simulator ecosystems that use it, because that is the strongest signal of what it is good at. Three things to check before you build on it. Read the licence file rather than the metadata, since the metadata is empty while two code files declare a permissive licence and the readme says nothing. Install by the published package name, because the name you would guess from the repository does not exist. And expect the algorithm surface to be two methods, not a catalogue, so if you need something else you are writing it yourself, which is the point and also the cost.

Frequently asked questions

Official sources

1. Issues
2. leggedrobotics/rsl_rl on GitHub
3. Project website
4. README
5. Releases