Do You Need ROS 2 If You're Only Doing Simulation?

No: if you work only in a simulator, the simulator's Python interface is enough, and ROS 2 adds setup you do not need yet. Simulators run without middleware, and a beginner learns more from one script that moves a joint than from a week of installation. The verdict flips the moment you split the work across several programs, which is where ROS 2 and HORUS start to matter. The rest of this post is for someone learning robotics on a laptop who keeps being told to install ROS 2 before writing anything.

You wanted to see a robot arm move. The tutorial you found opens with an operating system version you do not have, then a list of commands to paste, and by the third command something has failed with a message that mentions a package you have never heard of. Two hours later you are reading a forum thread from four years ago where someone had the same error and the accepted answer is a link that no longer resolves.

Somewhere in there you learned the word "sourcing", and that forgetting to do it makes everything stop working in a way that looks like your code is broken. You still have not seen a robot move. Meanwhile a friend who is doing a robotics course sent a screenshot of an arm picking up a block, and it turned out to be a handful of lines in a notebook with no framework at all. Now you cannot tell whether you have been failing at robotics or failing at installation, and whether the thing everybody insists is mandatory is actually mandatory for what you are trying to do this month.

Do you need ROS 2 if you are only doing simulation?

No, and the simulator vendors agree, because every major simulator ships a Python interface that works on its own with nothing else installed. You can load a robot, command a joint, read a sensor, run a control loop and watch the machine succeed or fall over, all from one file, on a laptop, on any operating system that simulator supports. ROS 2 enters the picture for a different reason than beginners are told. Its job is to let separate programs talk to each other, so that a perception program, a planner and a controller written by different people can be developed apart and connected later. If your entire project is one script and one simulator, there is nothing to connect, and installing a connection framework buys you a week of setup and a vocabulary lesson instead of a moving robot. That changes later, and this post is largely about spotting the moment it changes. Until then, the honest advice is the one nobody gives: open the simulator and skip the framework.

What is a robot simulator actually doing when you press play?

A simulator does three separate jobs, and confusing them is the source of most beginner frustration. First, it computes physics: where every link of the robot is, what the joints are doing, what happens when the gripper closes on a block and whether the block slips. Second, it renders a picture, which is purely for your benefit and is the part that makes your fan spin up. Third, it pretends to be hardware, handing your code sensor values and accepting commands in roughly the shape a real robot would. That third job is why simulation teaches anything transferable. The pretence has limits worth knowing early. Friction is approximate, contact is where simulators disagree most with reality, sensors are cleaner than real ones, and time in a simulator is not the same as time on a machine that has other work to do. None of these three jobs requires a middleware. A simulator is a complete program that already knows how to talk to your script, which is why the plain script route works so well at the start.

What are your actual options for connecting your code to a simulator?

There are seven, and beginners should start with the first and ignore the rest until something forces a change. You can write one Python script against the simulator's own interface, which is the shortest path to a moving robot. You can call a physics library directly from your own program when you want to understand the maths rather than drive a scene. You can install ROS 2 and use the simulator's bridge, which makes the simulated robot behave like a real one to any ROS 2 program. You can use a reinforcement-learning training stack, which wraps the simulator in the interface learning algorithms expect. You can use a robot vendor's own simulation package, which mirrors the machine you intend to buy. You can stay in a notebook with a plotting library and simulate nothing but the numbers. Or, once your project genuinely spans several programs and more than one language on one computer, you can use HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers so messages between processes are never serialised; the licence is Apache-2.0, and this is a middleware rather than a simulator, so it computes no physics and draws no scenes.

How do the options compare for someone working only in simulation?

Read the table by finding the row that matches what you are trying to do this month, not what you hope to do next year. Beginners overwhelmingly belong in the first row, and the most common mistake in this whole subject is starting three rows further down because a tutorial did.

If two rows look equally plausible, choose the one that gets something moving on your screen sooner. Nothing you learn in the first row is wasted when you move to another, because the maths, the coordinates and the control logic all travel with you.

Are you a student, a hobbyist, or someone retraining for a robotics job?

The three should make different choices, and copying the wrong one costs months. A student with a course and a deadline should use whatever the course uses, without argument, because marks come from the assignment and not from the toolchain, and the demonstrator can only help with the setup they know. A hobbyist building for pleasure should take the shortest path to a moving robot, because motivation is the actual scarce resource and a week of installation errors ends more robotics hobbies than any technical difficulty. Someone retraining for a job has the one situation where the answer changes: job adverts name ROS 2 constantly, interviewers ask about it, and a candidate who has never seen a launch file is at a disadvantage against one who has. Even then the sequence matters more than the choice. Learn to make a simulated robot do something first, because a person who understands coordinate frames and control loops learns a framework in weeks, while a person who learned the framework first often cannot say what any of it is for.

What computer do you need to run a robot simulation?

The laptop you already own is almost certainly enough for learning. A simulated arm, a wheeled robot driving around a room, and a scene with a few objects in it will run at a speed comfortable for watching and debugging on ordinary hardware, including machines several years old. Three things change that. Cameras in the scene are expensive to render, so a robot that looks at the world costs more than one that only moves. Photorealistic scenes are a different activity altogether and want dedicated graphics hardware. And reinforcement learning, which runs many copies of a world at once to train a policy, is where people genuinely need a serious machine or a rented one. Notice that none of those three has anything to do with middleware. Installing ROS 2 does not make a simulation run better and adds background processes to a laptop that may be short of memory. If your machine is struggling, the fixes are turning off rendering while a long run happens, shrinking the scene, or removing cameras you are not using.

What can you get working this weekend, and what takes months?

This weekend you can have a simulated arm reaching for a point, or a wheeled robot driving to a target and stopping. That is a genuine milestone rather than a toy: it means you have met coordinate frames, understood the difference between where a robot is told to go and where it ends up, and written a loop that reacts to what it observes. Next weekend you can add a gripper and discover that grasping is much harder than reaching. Within a month, with steady evenings, you can have a robot that senses something in the scene and changes what it does. What takes months is the part nobody photographs: behaviour that survives being repeated a hundred times without human intervention, tuning that holds when the object starts in a different place, and diagnosing why the machine works in one corner of the room and not another. Setting up a middleware, on the same timescale, buys none of that. It is a step you take when a project outgrows one program, not a step that makes any of the hard parts easier.

What if you have only written a little Python?

Then you are in a better position than you think, because simulation is unusually kind to beginners. The feedback is visual and immediate: a wrong sign sends the arm the wrong way, a missing conversion makes it spin absurdly, and a loop that runs too slowly makes the motion jerky in a way you can see rather than infer. Compare that to installing a framework, where an error message about a package you have never heard of teaches nothing at all and cannot be debugged by looking at anything. What you need is the ability to write a loop, define a function, and read a stack trace without giving up. Everything specific to robotics you can learn on the way. The parts that genuinely require more programming maturity arrive later: several programs running at once, values arriving out of order, and reasoning about what happens when one part falls behind another. That is exactly the point at which a middleware becomes worth the trouble, and it is a fine place to be six months from now rather than today.

What do beginners try first in simulation, and why does it stop working?

They put everything in one file, and it works far longer than anyone expects. One loop reads the simulated sensors, decides what to do, and commands the joints, and for a single robot doing a single task this is not a compromise but the right design. The trouble starts when one part of the loop becomes slow. Add object detection on a camera image and the whole loop now waits for it, so the robot's control gets ragged and the arm starts overshooting the point it used to reach cleanly. The instinct is to make the detection faster, and that helps a little. The real cause is structural: fast work and slow work are sharing one loop, and the fast work is being held hostage. The standard fix is to split them into separate programs, and that is the moment your project acquires a middleware whether you wanted one or not, because two programs must now exchange values without one stalling the other. Recognising that moment is more useful than choosing a framework in advance of it.

What do you give up by skipping ROS 2 while you learn?

You give up the ready-made pieces, and how much that costs depends entirely on what you are building. You give up navigation that already works, so a wheeled robot that maps a room and plans a path around obstacles becomes a project rather than a package. You give up the visualisation tool that shows every coordinate frame moving in real time, which is genuinely the best debugging aid in robotics and has no equivalent elsewhere. You give up recorded runs you can replay later, standard message shapes that let other people's code plug into yours, and the ability to search for your exact error in the words a thousand strangers already used. You also give up a line on a CV that recruiters filter for. Against that you get to see a robot move today, keep your laptop uncluttered, and learn the concepts underneath rather than the vocabulary on top. For a first month that trade is clearly right. For a second year aimed at hardware it clearly is not, and the good news is that nothing stops you making the trade twice.

When is ROS 2 the better choice?

ROS 2 is the better choice as soon as your simulation stops being the whole project, and the cases are worth stating plainly. If a real robot is arriving in the post and it speaks ROS 2, start now rather than later, because you will want the framework debugged before the hardware arrives. If you want navigation, mapping or arm motion planning without writing them, the packages are the reason to be there and nothing else comes close. If you are on a team where people must work on separate pieces, the framework is a shared vocabulary as much as a technology. If a job advert lists it, learning it is the job. And if you want to replay a run and inspect every value afterwards, the tooling is mature and free. HORUS is not the answer to any of those, and reaching for it while you are still learning to make one arm move would add a layer to a project that does not yet have parts to connect. Whether the ecosystem holds up for a real product is a separate question, and it is answered in its favour.

Is simulation-only work just avoiding the hard part?

No, and here is why: the hard parts of robotics that beginners actually fail at are all present in simulation. Coordinate frames confuse everyone equally in a simulated world. Control loops that oscillate, overshoot or fight themselves behave the same way on your screen. Planning a motion that avoids an obstacle is exactly as hard when the obstacle is drawn. Deciding what a robot should do when it cannot see what it expected is the same design problem regardless of where the robot lives. What simulation genuinely lets you skip is the physical layer: wiring, motor drivers, mechanical looseness, a sensor that reads differently when the room warms up, and the day you lose because a connector was loose. Those are real skills and they are learned faster once the software makes sense. There is a caveat worth accepting honestly, which is that a policy tuned only in simulation usually needs adjusting on hardware, sometimes substantially. Working out how realistic your simulation needs to be is the sensible next question rather than a reason to avoid simulation.

Will the code you wrote against a simulator run on a real robot?

Partly, but not the way you think. The logic survives almost entirely: your planner, your controller, your state machine, the maths that turns a target into joint commands. The wiring does not, and neither do your assumptions. A real sensor arrives with noise, occasional missing values, and a delay between the world changing and your program hearing about it. A real motor has a limit it will not exceed and heats up when pushed. Real timing wobbles, because your program shares a computer with everything else, and the loop that ran evenly in a simulator can arrive late on hardware in a way that shows up as motion you can watch. This is why the transition is a phase of work rather than a copy operation, and why people who simulated carefully still spend weeks on the first real machine. The parts most likely to need rewriting are exactly the parts a middleware handles, which is the practical reason to add one when hardware is genuinely close and not before.

How do you decide when to add ROS 2 to your simulation work?

Add ROS 2 when your project acquires a second program, a second person, or a delivery date for real hardware, and not one week earlier. Those three triggers cover almost every genuine case. A second program means values have to cross a boundary, which is the actual problem middleware solves. A second person means you need shared vocabulary and message shapes so two people can work without constant coordination. Real hardware arriving means you want the drivers and the framework working before the machine is on your desk, because debugging both at once is miserable. If none of the three applies, adding a framework now costs you setup time and gives you nothing you can point at. There is a fourth trigger worth naming: a course or an employer requires it, which is a perfectly good reason and needs no technical justification. The free simulators that run on an ordinary laptop are where to spend this weekend instead.

Decide by situation rather than by what a tutorial assumed:

• If you have never made a robot move -> the simulator's own Python interface, because a moving robot beats a finished installation.
• If a course or an employer requires it -> ROS 2, because the requirement is the reason and it needs no defending.
• If real hardware arrives next month -> ROS 2 now, because debugging a framework and a machine together is miserable.
• If you are training a policy rather than writing one -> a reinforcement-learning stack, because the interface it expects is already standard.
• If your project has grown into several programs sharing one computer -> a shared-memory middleware, because that is the boundary that got slow.

When two of these fit, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. No scores and no numbers, just five questions about your situation rather than about the software, and you keep whichever option loses on fewer of them. If your projects keep growing into several programs on one computer, in more than one language, star HORUS on GitHub so it is in your list when you start building.