Can You Learn ROS 2 Without Owning a Robot?

Yes, learning ROS 2 without a robot works: a simulator on an ordinary laptop teaches the concepts, and a cheap kit adds little at first. Nearly every ROS 2 idea — nodes, topics, launch files, and the message plumbing that middlewares like HORUS also provide — is visible with no hardware attached. The verdict flips only when your goal is bring-up, because wiring, drivers and calibration are not learnable on a laptop. The rest of this post is for beginners deciding whether to buy hardware now, wait, or start tonight with a simulator and an empty desk.

You have decided to learn ROS 2, and the first tutorial you opened assumes a small wheeled robot sitting on the floor next to you. The second assumes a laptop running one specific version of Ubuntu. The third assumes you already know what a workspace is and why yours will not build. None of them assume the situation you are actually in, which is a desk, a laptop, and a vague plan to build something eventually.

So you go looking for permission. One camp says you cannot learn robotics without hardware, that everything interesting happens the first time a real motor disagrees with you, and that simulation is a comfortable way of avoiding the subject. The other camp says buying a kit is the classic beginner mistake, that the kit ends up in a drawer beside the drone, and that you should not spend money until you know what you would do with it.

Meanwhile you have spent two evenings on installation. Something failed to build. A launch file referenced a package that does not exist on your machine, and the error ran to forty lines. You have not written a line of robot code yet. Before you spend a third evening, you would like to know whether any of this counts.

Can you actually learn ROS 2 with no robot on your desk?

Yes, and the parts of ROS 2 that take longest to learn are exactly the parts that never touch hardware. What makes ROS 2 difficult is not motors. It is that your program is split into pieces running at the same time, that those pieces have to find each other through a discovery layer with opinions of its own, that a message you were expecting silently fails to arrive, and that a build system stands between you and running anything at all. Every one of those is fully present on a laptop with a simulated robot. When two of your nodes disagree about a topic name and nothing happens, you have met the real subject. When your coordinate frames have a gap in them and the robot appears to be in two places at once, that is the real thing too. What a laptop cannot hand you is the failure whose cause is a connector half seated or a sensor mounted a few degrees off. Those are worth learning, and they take days with hardware present rather than the months the software side takes.

What is ROS 2, and what does it actually hand you?

ROS 2 is two things fused under one name: a way for separate programs to pass messages, and a large collection of ready-made robot software that already speaks that message system. The messaging half is what tutorials teach first. You write small programs, each publishing named streams of data and subscribing to others, and the framework arranges introductions so no program needs to know where the others live. The library half is why people stay. Someone has already written the code that turns wheel rotations into an estimate of where the robot is, that draws a map while driving through an unknown room, that plans a path around a table leg, and that talks to a few hundred specific sensors. There is also a layer of convention holding it together: how coordinate frames relate to one another, how timestamps are attached, how one file starts a dozen programs in the right order. None of that needs a physical robot to exist. It needs programs, messages, and something producing plausible sensor readings, which is precisely what a simulator does.

What are your actual options for learning ROS 2 without hardware?

You have roughly seven routes, and they differ mostly in how much of the real experience they preserve. ROS 2 with Gazebo is the standard one: a simulated robot publishes the same message types a physical one would, so your code cannot tell the difference. ROS 2 on its own is the overlooked one — you can write nodes that publish invented numbers to each other and learn the entire message system with no world loaded at all. Playing back recorded data from someone else's robot teaches you to handle sensor streams that are noisy and occasionally missing. Isaac Sim and Webots cover camera-driven work. Browser-based courses hand you a preconfigured machine so that installation stops being the lesson. You can also rehearse the shape of a multi-program robot on a different messaging layer: HORUS is an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages are not serialised between processes on one machine, and it is Apache-2.0 in the same way ROS 2 is. Or you buy one motor and one cheap board, which is hardware without being a robot.

What should you use if you are teaching yourself to get hired?

Take ROS 2 with Gazebo, finish one small project completely, and keep notes on everything that broke, because the notes are what interviews are actually about. Hiring conversations in robotics rarely test whether you can recite what a topic is. They test whether you have been stuck, what you suspected, how you narrowed it down, and what turned out to be true. A candidate who says the robot drove into the wall because the map and the odometry disagreed, and here is how that was found, is doing the job in the room. A candidate with four half-finished tutorials is not. Choose a project that is small and slightly awkward on purpose: drive to a marked spot and stop cleanly, or follow a wall around a room without clipping the corners. Then damage it deliberately. Delay the sensor readings. Drop a fraction of them. Rename a topic and watch how the failure presents. The habits that come out of that exercise are the ones a team is hiring for, and none of them require a robot.

What computer do you need to run ROS 2 without a robot?

An ordinary laptop is enough, and the graphics card matters far less than forum arguments imply until you reach photoreal simulation. ROS 2 itself is undemanding; a machine that comfortably compiles a mid-sized project will run a dozen nodes without noticing. Memory is the constraint people underestimate, because a simulator plus an editor plus a browser full of documentation is where a small machine gives up first. The real question is not power but operating system. ROS 2 assumes Ubuntu, most instructions assume Ubuntu, and every hour you spend making a different system behave is an hour not spent on robotics. Docker and the Windows Subsystem for Linux both work well for the message side of things and get fiddly the moment a simulator wants direct access to your graphics hardware. If Linux is not currently on your machine, your options for ROS 2 on Windows and Mac is worth reading before you commit an evening to a virtual machine you may later abandon. A second-hand laptop dedicated to Ubuntu is often the cheapest fix available.

How long does this take when there is no hardware to wait for?

A weekend gets you nodes talking, a fortnight gets you a simulated robot moving under your own code, and the interesting part takes several months regardless of what you own. The early milestones arrive faster without hardware, because nothing is blocked on a delivery, a driver, or a connector. What takes months is judgement rather than knowledge. Telling a sensing problem from a control problem takes months, because both present identically as the robot doing something stupid. Learning to structure a system so a slow piece cannot disturb a fast one takes months. Learning what to record so that yesterday's failure is explainable today takes months. Building the instinct that a number looks wrong before you can prove it takes months. None of that is gated on owning a machine; it is gated on running many experiments, which is the one thing simulation makes cheap. How long learning ROS 2 really takes breaks the stages down further, and the honest summary is that the framework is a few weeks and the discipline is a year.

What if you have barely written any code yet?

Learn Python properly first, because your obstacle for the next two months will be programming rather than robotics, and it helps enormously to know which one is defeating you. Someone new to code who starts with ROS 2 typically spends a fortnight losing to workspaces, build tools and launch files, then concludes they are bad at robotics without having attempted any. Four things carry most of the weight: loops, functions, dictionaries, and reading a stack trace to the line that actually matters. Add the command line, because everything here happens there. Then meet the robotics ideas one at a time, each with something moving on screen: where the robot believes it is, where it wants to be, and how the gap between those drives the wheels. A useful intermediate step is writing two plain Python programs that pass messages between themselves without any framework, so that when ROS 2 does it for you, you know what has been done on your behalf. Beginners who skip that step tend to treat the framework as magic and get stuck the first time the magic fails.

What does learning ROS 2 without a robot look like when it goes wrong?

It goes wrong when you become fluent in a tutorial rather than in robotics, and the symptom is that nothing survives a change of scenery. The pattern is recognisable from the outside. You can recite the commands to build a workspace but cannot say what happens when a subscriber starts after a publisher. You have copied a launch file you cannot read. Your robot works because the simulated wheels never slip and every reading arrives on time and in order, so your code has never had an opinion about a reading that never came. Worse, you start simplifying the world until your algorithm looks good rather than hardening the algorithm against a world that misbehaves. The second failure mode is quieter: months of setup with no project. Installation, distribution choices, editor plugins, a fresh operating system, a new simulator, and no robot ever driving anywhere. Both cures are the same. Pick one small behaviour, get it working, then degrade your own simulation deliberately — delay, noise, dropped messages — until the code has to earn the result.

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

Almost everyone starts by following the tutorial where a simulated robot drives around a room, and that stops working the moment they change one thing in it. Following it first is correct; it proves the installation and gives you something moving. The collapse comes when you swap the robot for a different one, or add a sensor, and everything breaks in ways no tutorial mentions, because you were reproducing steps rather than building a model of the system in your head. Two habits usually follow, both unhelpful. The first is reinstalling: a new distribution, a new machine, a fresh operating system, on the theory that the next environment will be less confusing. That converts learning time into packaging time. The second is asking an assistant to generate the whole project, which produces confident code you cannot debug, because debugging a robot means having a theory about what the robot currently believes and checking it. What breaks the cycle is unglamorous. Take one working example, change exactly one thing, predict the outcome before running it, and pay close attention on the occasions you are wrong.

What do you give up by never plugging anything in?

You give up the intuitions that only arrive through mass, heat, vibration and time, and they matter later even though they cost weeks rather than months to acquire. Real machines shake, and the shaking enters your sensor readings as noise you did not simulate. Cables tug on joints and quietly change what an arm can reach. Motors warm up and behave differently after an hour than they did in the first minute. A gripper that closes on the same object thirty times will fail once for a reason nobody logged. A battery sags under load and the whole computer misbehaves in a way that reads exactly like a software bug, which is how people lose a weekend. You also give up bring-up as a skill: reading a wiring diagram, checking whether a device is even present, working out which of two identical-looking ports the sensor actually enumerated on, and the discipline of a machine that can hurt you and therefore keeps an off switch within reach. That competence is genuinely valuable and genuinely quick. It is a matter of weeks with hardware present, not years.

When is ROS 2 the better choice?

ROS 2 is the better choice for essentially every beginner learning without hardware, and that is not a hedge to be polite. The tutorials assume it. The simulator integration is written for it. The sensor drivers you will want six months from now already exist for it. The navigation and mapping packages represent years of work you are not going to reproduce while also learning what a coordinate frame is. If your goal is a robotics job, the vocabulary of ROS 2 is the vocabulary of the interview, and the open code you will learn most from is written against it. Community answers matter more than anything else at this stage, because a beginner's real bottleneck is being stuck alone, and ROS 2 has the largest pool of people who have been stuck the same way. HORUS is not the answer for someone whose goal is a portfolio, a first job, or a mapping demo. The narrower case for a shared-memory middleware arrives later, when several programs on one computer must look at the same camera frames without copies passing between them.

Is a simulated robot too easy to count as real practice?

No, and here is why: most professional robotics work already happens in simulation, including at companies whose machines you have watched walking. Policies are trained there because no physical robot survives the number of attempts required. Controllers are tested there precisely because the failure being tested is the one that breaks hardware. Perception work runs against recorded and synthetic data long before anything is mounted on a frame. Building a scene that genuinely poses the question you are asking is itself a skill people are paid for. The accusation lands in a narrower place than it sounds. Simulators make easy the two things hardware makes hard, which are contact and timing, so a result obtained there is optimistic by default. That is an argument for treating simulated success as a hypothesis rather than a conclusion, and for deliberately making your own world less flattering. It is not an argument for sitting out the next six months waiting until you can afford a machine. Whether robotics can be learned entirely in simulation covers where that boundary actually sits.

Will everything you learn without hardware transfer to a real robot?

Partly, but not the way you think. The structure transfers almost completely: how your programs are divided, what publishes to what, how data flows from sensing through decision to command, and the debugging habits you built along the way. What does not transfer is tuning. Friction, mass, sensor delay and motor response all differ from whatever the simulator assumed, so the numbers you carefully found will need finding again. That is a far better outcome than the phrase suggests, because code surviving while constants change is normal engineering. The surprises cluster in three places. Contact, because simulated grippers hold what real ones drop. Timing, because a simulator can pause the world while your program thinks and a real robot cannot. And sensing, because simulated readings are clean and punctual while real ones arrive late, out of order, or not at all. All three can be rehearsed in advance by making your simulation worse deliberately, which is the single highest-value habit available to someone learning without hardware.

How do you decide whether it is time to buy something?

Buy hardware when simulation stops answering your questions, not when you feel guilty about not owning a robot. The signal is specific: you have a behaviour that works, you have already degraded your own world until it is unflattering and the behaviour still holds, and the next thing you want to know is something no simulator can tell you. Whether your loop keeps its rhythm on a small on-board computer is that kind of question. Whether a gripper design holds a real object is another. Before you reach that point, hardware mostly buys a stalled project and the particular sourness of an unopened box. Two other triggers are legitimate. If your motivation is dying and something physical would revive it, that is a real engineering consideration, and a cheap wheeled kit is a perfectly good purchase. And if you intend to sell something, buy early, because the problems that kill products are physical and you want to meet them while the design is still soft.

Decide by situation rather than by guilt:

• If you are learning ROS 2 with no budget for hardware -> a simulator and a laptop, because the software half is most of the field and all of it is open to you.
• If you want a robotics job within a year -> ROS 2 with Gazebo plus one small physical project, because interviewers ask about both halves.
• If you keep failing before anything runs -> a browser-based course, because the lesson should be robotics rather than packaging.
• If your simulated robot works and you cannot explain why -> stay in simulation and make it harder, because hardware will not explain it either.
• If you are building something to sell -> buy hardware now, because product problems live in the physical world.

When two routes stay close, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Pick whichever loses on fewest — five plain questions about your situation rather than about the software, with no scores attached. And if your eventual plan puts a model and a controller on the same on-board computer, star HORUS on GitHub so it is in your list when you start building.