LeRobot Alternatives: 6 Options for AI-First Robotics

There is no drop-in LeRobot replacement: the real alternatives split into training stacks like Isaac Lab and runtime stacks like HORUS or ROS 2. LeRobot covers data collection, policy training and evaluation on small arms, and was never meant to be the process layer a shipped robot runs on. The verdict flips if your robot is a research arm on a bench, where LeRobot alone is genuinely enough. This post is for someone who trains policies in Python and now has to make one of them drive real hardware without dropping frames.

The notebook is convincing and the robot is not. Your evaluation numbers look fine, the recorded rollouts look fine, and then the arm goes out to the real bench and moves like it is slightly drunk. It overshoots, corrects, overshoots again. Sometimes it freezes for a moment and then lurches, and you cannot reproduce that in evaluation because evaluation never freezes.

So you start patching. You put the camera in its own thread, and things improve a bit. You add a queue, and then a second queue with a different discard rule. You move the wrist camera into a separate process because two cameras in one Python process were fighting each other. Now you need those processes to talk, so you write a socket layer, then a small serialisation format, then a supervisor that restarts whichever one died. Somewhere in that week it becomes clear you are building message plumbing, badly, while telling yourself it is temporary.

None of this is LeRobot's fault. The demos worked, the training worked, the format worked. It is that the documentation ends where your robot starts, and nobody warned you that the second half of the problem has its own tooling and its own vocabulary.

What should you use instead of LeRobot?

In most cases you should add to LeRobot rather than replace it, because the thing people are unhappy with is the runtime half that LeRobot never claimed to cover. That reframing solves more arguments than any comparison table. Teams arrive at this question through two different doors. Some are unhappy with the training side: they want large-scale simulation, reinforcement learning rather than imitation, better domain randomisation, or a training loop they can restructure. Those people want Isaac Lab, a MuJoCo-based setup, or their own loop. Others are unhappy with the robot side: cameras, policy and motor control need to run as separate programs on one machine without stalling each other, and they need supervision and recording. Those people want middleware, and the choice there has nothing to do with machine learning. Work out which door you came through before shopping, because the two groups of tools are not substitutes for each other and picking from the wrong list is how teams end up rewriting something that was already working.

What does an AI-first robotics stack actually contain?

An AI-first stack has five layers, and most tools cover two or three of them. First, a way to collect demonstrations: a teleoperation rig, a leader arm, a controller, some human sitting there doing the task repeatedly. Second, a dataset format that stores those episodes with synchronised images, states and actions, and that other people can read. Third, a training loop producing policy weights, whether by imitation from your demonstrations or reinforcement in simulation. Fourth, an inference runtime that loads those weights and produces actions from live observations. Fifth, the process layer: the thing that gets camera frames to the policy while they are still fresh, gets actions to the motor controller before the next cycle needs them, keeps a safety check running in a program the policy cannot stall, and restarts whatever crashed. LeRobot covers the first three well and gives you a thin version of the fourth. The fifth is where most of the pain in this article lives, and what sits between the model and the motor is the layer nobody demos.

What are the six real alternatives to LeRobot?

Six options come up repeatedly, and three of them replace the training half while three replace the running half. On the training side: Isaac Lab and the surrounding NVIDIA simulation stack, for teams with GPUs training at scale before hardware exists; a MuJoCo or robosuite setup with your own loop, for researchers whose question is the environment itself; and a single-policy research repository you fork, for reproducing one paper closely. On the running side: ROS 2 with your policy wrapped in a node, which brings drivers, mapping, visualisation and a hiring pool; HORUS, an open-source real-time middleware under Apache-2.0 where Rust, Python and C++ share the same shared-memory ring buffers, so a camera frame crossing from a C++ driver to a Python policy on one machine is not serialised on the way; and the robot vendor's own SDK, which is the fastest path to a moving arm and the hardest to leave. Most teams that get a policy onto real hardware end up holding one from each side.

How do the six options compare?

The comparison only makes sense once you accept that the rows are not interchangeable, so read the second column first and find the description that matches you rather than looking for a winner. A team training locomotion in simulation and a team getting a wrist camera to a policy on time are not choosing between the same things. The last column is the one to read honestly, because every row in this table has a situation where picking it is a mistake that costs a quarter.

What breaks first when a trained policy meets a real robot?

Timing breaks first, and it breaks quietly. The policy still produces sensible actions, but the frames arriving at it are older than they should be, so the arm is reacting to a world that has already moved. Nothing in the logs says this. The symptom is a policy that scored well in evaluation and now overshoots, hunts around the target and occasionally stalls. The usual causes are ordinary: image decoding sharing a process with inference, a queue that grew unbounded and now hands over stale frames, a logger writing to disk in the same thread as the control path, two cameras competing inside one Python process, or a garbage collection pause landing exactly when a gripper needed to close. Second to break is supervision. In evaluation, a crash ends the run. On hardware, a crash leaves a heavy arm mid-motion with nothing holding it, which is why the safety check belongs in a program the policy cannot take down with it. Third is reproducibility: without recorded messages, yesterday's failure is gone.

Which option fits the kind of team you are?

A solo researcher should stay on LeRobot and add only what actually hurts, because every extra layer is upkeep nobody else will do. That advice inverts fast as the team grows. Two people building a demo for a funding round want the vendor SDK plus LeRobot and nothing else, because the arm moving next month is worth more than any architecture. A four-person startup heading towards a product needs the runtime half settled early, since retrofitting process boundaries into a codebase where everything lives in one Python file is genuinely painful. A lab with a fleet of identical arms wants the ecosystem route, because tooling and hiring dominate. And a team whose actual product is the model, not the robot, should keep the robot side as boring and standard as possible, buy the platform, use its SDK, and put every hour into data. Middleware for robots that run an AI model on board works through the runtime decision for that last group.

What hardware are you running the policy on?

The hardware settles more of this than the software preference does, and the first question is how many computers are involved. A single machine holding cameras, policy and motor control is the situation where a shared-memory message layer earns its place, because frames cross between programs without being copied out and back. A robot with inference on a desktop and the arm on a tether is two computers with a network between them, and no shared-memory arrangement crosses that gap, so plan for a network transport and the delays it brings. A module with an onboard GPU changes the arithmetic again: the model dominates everything, and the transport matters mainly because it decides how much of the board is left for inference. A cheap board with no accelerator will not run a large policy at a useful rate no matter what carries the messages, and that is a hardware answer, not a software one. Settle the computer count before comparing frameworks.

How soon does the robot have to work?

If the deadline is weeks, keep LeRobot, use the vendor SDK for the arm, and change nothing else, because architecture work does not fit inside a month. Deadlines reorder this list more than preferences do. A demo in a fortnight means one process, one language, mains power and a human near the stop button. A term or a quarter means it is worth splitting the camera path from the policy path properly, since that is the change that pays back within the same project. A year to a product means the ordering flips entirely: settle the runtime layer first, because the training side can be swapped later without touching the robot, and the robot side cannot be swapped later without touching everything. The trap is the team that takes the fast path for a demo, wins the funding, and then discovers the demo has become the product with a socket layer holding it together. When is it too late to change middleware is the version of this problem that arrives eighteen months later.

What do you need to know before each option makes sense?

Each option assumes a different background, and the mismatch is usually the reason an adoption fails rather than any property of the tool. LeRobot assumes Python, PyTorch and comfort with the idea that a policy is trained rather than programmed. The simulation stacks assume you can set up physics, tune a reward and debug a training run that silently learned the wrong thing, which is a distinct skill from writing robot code. The middleware options assume something the machine learning path never teaches: processes, message shapes, what happens when one program dies, and why a queue with no discard rule eventually hands you old data. That gap is the real barrier for an AI-first team, and it is a week of learning rather than a year. The vendor SDK assumes only that you can read documentation, which is why it is the right answer so often at the start. From a Hugging Face model to a working robot walks the steps that sit in that gap.

What do you give up when you move off LeRobot?

You give up the dataset gravity, and that is the loss to weigh most carefully. The LeRobot format is what lets you pull public demonstration sets, compare against published results, and hand your own data to a collaborator who can read it immediately. You give up pretrained checkpoints that already match your arm. You give up teleoperation rigs that work out of the box on the cheap arms, which is more engineering than it looks. You give up the community of people running exactly your setup, so when something breaks there is no forum thread waiting. And you give up the pleasant property that everything is Python in one repository, which is genuinely faster for experiments. The good news is that most of this is only lost if you choose to lose it. Keeping the dataset format and the training code while changing what runs on the robot costs you nothing from this list, and that combination is what most teams actually end up with. LeRobot explained covers what the project is aiming at in its own terms.

When is ROS 2 the better choice?

ROS 2 is the better choice as soon as your robot is more than an arm on a bench. A mobile manipulator that must navigate a building needs mapping and planning, and those are years of other people's work sitting inside the ROS ecosystem. A depth camera or a force sensor whose only maintained driver is a ROS package points the same way. A team that plans to hire robotics engineers should take the stack candidates already know, because familiarity outlasts every technical property. A robot spread across several computers gets real value from discovery and network transports. A university project with a marker, a collaboration with a partner running ROS, and any project that needs the visualiser and the recording tool on day one all land there too. HORUS is not the answer in those cases and does not claim to be, since a single-machine message layer gives you no drivers, no mapping and no catalogue. Choosing the smaller tool when you needed the ecosystem is the more expensive mistake of the two.

Is LeRobot too limited for a serious robot?

No, and here is why: the limits people hit are boundaries the project drew deliberately, not gaps left by accident. LeRobot set out to make data collection, training and evaluation on affordable arms approachable, and inside that boundary the work is careful. A project that tells you plainly what it is for is doing you a favour. The mistake is reading a training library as a robot operating system and then blaming the library when the robot needs process supervision it never offered. Plenty of serious work ships on LeRobot: published research, teaching, dataset collection at scale, and prototypes that prove a task is learnable before anyone spends money on an industrial arm. What LeRobot will not do is manage six programs on one machine with a safety check that survives a crash in the policy. That is a different job with different tools, and needing those tools says nothing bad about the ones you already have.

Will a different stack make your policy work on hardware?

Partly, but not the way you think. If the policy is failing because it never saw your lighting, your table height or your object, no message layer will rescue it, and the honest fix is more and better demonstrations. What a different runtime changes is subtler and matters more than it sounds: it stops your evaluation from lying to you. When frames arrive fresh and actions land before the next cycle needs them, a failure is genuinely the policy's failure, and you can debug the model instead of debugging the plumbing wearing the model's clothes. Teams routinely spend weeks retraining to fix a problem that was a stale queue. The second thing it changes is what you can attempt at all. A stack that leaves the board with room lets you run a second camera, a safety check and a recorder alongside the policy, and recorded runs are how you find out what your policy actually did rather than what you remember it doing.

How do you decide which alternative to take?

Answer three questions in order and the choice usually falls out. First: is your unhappiness on the training side or the robot side? Write down the last three things that went wrong and label each one. If they are about the policy learning the wrong thing, look at simulation and training stacks. If they are about frames, crashes, processes and timing, look at middleware, and keep your training setup exactly as it is. Second: how many computers will your robot have when it works, counting anything with its own processor? One means a shared-memory layer is available to you, more than one means a network transport regardless of anything else. Third: what will you refuse to write yourself — drivers, mapping, navigation, a visualiser, a recording tool? A long list means the ecosystem answer, whatever else you prefer. A short list with one computer means take the lean option and put the saved time into data collection, which is where the outcome actually gets decided.

A short version, by situation:

• If you are a researcher training a policy on a bench arm -> stay on LeRobot, because the tool matches the job and switching costs weeks you would rather spend on data.
• If your arm reacts to a world that has already moved -> a single-machine message layer, because the problem is stale frames, not the model.
• If the robot must navigate a building or use a ROS-only sensor -> ROS 2, because mapping, planning and drivers are years of other people's work.
• If you are training locomotion in simulation before the hardware exists -> Isaac Lab or a MuJoCo setup, because those loops are what large-scale training needs.
• If the demo is in a fortnight -> the vendor SDK and nothing else, because architecture does not fit inside a fortnight.
• If the policy is the product and the robot is a detail -> buy the platform, keep the robot side boring, and spend every hour on data.

When you want to compare candidates rather than symptoms, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. For an AI-first team the deciding axes are usually deployment target and setup effort, with licence mattering the moment a research prototype starts turning into something you intend to sell.

If your unhappiness is on the robot side and everything runs on one machine, HORUS is open source under Apache-2.0 and the repository is linked below. Star it so it is in your list when you start building.