How to Learn Robotics in 2026 Without Buying a Robot

Yes, you can learn robotics without buying a robot: a simulator above ROS 2 or a lighter middleware teaches everything except the final physical mile. A simulator hands you the control loop and the message plumbing, and code written against ROS 2 or HORUS carries over to real hardware later. The verdict flips only if you want a hardware job, where employers want proof you have fought a real motor. The rest of this post is for a beginner with a laptop, no budget for hardware, and no wish to waste the first six months.

Every roadmap you have found starts the same way: first, get a TurtleBot. You priced one, then priced the arm, then priced the depth camera, and closed the tab. Maybe you are a student, maybe you are moving out of web work, maybe you are fifteen and the budget is zero. Either way the advice assumes a purchase you cannot make, and the free alternative everyone waves at — just use a simulator — arrives as one line with no instructions attached. So you install something, lose a weekend to driver errors and a robot that falls through the floor, and conclude the real learning must be happening elsewhere, on hardware, among people who could afford it. Underneath all of that sits a worry you have not said out loud: that simulator work is fake, that an interviewer will smell it, and that you will spend a year building something that does not count. And a quieter second worry, which is that even if you did save up, you would not know what to buy, because you have never built anything that would tell you.

Should I start in a simulator or wait until I can afford hardware?

Start in the simulator today and buy hardware later with a far better idea of what to buy. Waiting has a cost people underestimate: the months spent not learning are months you do not get back, and nearly everything difficult about robot software is difficult in simulation too. The parts that transfer completely are exactly the parts beginners struggle with — how a control loop keeps time, why two programs disagree about what the camera saw, what a coordinate frame is and why yours is upside down, how to read a log after the robot did something baffling. The parts that do not transfer are real: friction unlike the model, a motor that behaves differently once warm, a cable that unplugs itself, a sensor returning a plausible wrong number. Those are worth learning, and they are worth learning second, because each is far easier to diagnose when everything above it is already familiar. Buying first is not wrong. It is an expensive way to discover which questions you actually have.

What does learning robotics actually consist of?

Learning robotics is four separate skills that one word bundles together, and only one of them needs a physical machine. The first is control: the loop that reads where something is, compares it with where it should be, and corrects, over and over, at a rhythm it has to keep. The second is perception: turning camera images, distance readings and wheel counts into a belief about where the robot is and what surrounds it. The third is plumbing: getting several programs on one computer to share that belief without disagreeing about time, which is the part that quietly consumes most of a project. The fourth is mechanical and electrical reality — motors, gears, power, wiring — and that is the one a simulator cannot teach. Three of the four are software you can learn on the laptop you already own. The fourth is a few weekends once you have hardware in your hands, and it is much less mysterious when you already understand what the software was trying to do.

What are my actual options for learning without hardware?

Six routes cover it, and they differ mostly in how close to a working robot stack you want to be while you learn. Gazebo with ROS 2 is the traditional path: a physics world, simulated sensors and the same messages a real robot would send, so what you learn is what teams actually run. Webots is the same idea with less installation pain. MuJoCo with Python suits you if the interesting part is motion and contact rather than a whole robot stack. Isaac Sim is the photoreal end, worth it if you care about vision and own the graphics card it expects. Then there is the light route: a physics loop you drive yourself with a real middleware underneath, which is where HORUS sits — an Apache-2.0 middleware for Rust, Python and C++ in which all three share the same shared-memory ring buffers, so a Python perception script and a compiled loop are not serialised between processes on one machine, and that project is validated in simulation rather than across shipped fleets. The sixth route is writing your own toy simulator, which teaches more than it sounds like it should.

How do those routes compare side by side?

Choose by what you want to be true in six months, not by which simulator looks best in a screenshot. Read the last two columns first and treat the middle column as a warning about the week you will lose before anything moves. These routes are not exclusive and most people end up using two: a heavy simulator for the full robot and something small for the afternoon when a question needs answering quickly. Also remember that the simulator is not the skill. The skill is what you build inside it, and a modest tool with a finished project inside beats a photoreal one with a half-installed tutorial.

What does a first month without a robot actually look like?

Week one is a simulated robot driving in a straight line and stopping where you told it, and that is an achievement rather than a warm-up. Most beginners skip it and start with a mapping demonstration copied from a tutorial, which runs, teaches nothing, and collapses the moment a parameter changes. A better first month goes in four steps. Get one simulated wheeled robot moving forward and stopping short of a wall, because that is a control loop and a sensor and the whole shape of the field in miniature. Then make it turn to face something the camera sees. Then break it deliberately: slow your own code down and watch the robot overshoot the wall, and work out exactly why it did. Then add a second program that logs what the first is doing, and discover that the two disagree about time. By the end of the month you will have met the four problems everybody meets, with no delivery arriving. Which simulator you used matters far less than having done this at all.

Does this route work if I am changing careers rather than studying?

It works better for a career changer than for a student, because you already own the skill that takes longest to acquire. If you write software for a living you can read documentation, debug something that refuses to work, and use version control, which is most of what stops a beginner from making progress at all. What you have to unlearn is the assumption that a program is fine as long as it eventually returns: robot code is judged on whether it did its work in time, every time. A student has more hours and a lab that might lend hardware, so that calculation tilts a little further towards borrowing a real machine. Someone changing careers usually has evenings, a decent laptop and a deadline of their own making. Simulation fits that shape exactly, because a session can be twenty minutes long and does not start with charging a battery or end with a stripped gear. Build in public, write down what broke, and the portfolio assembles itself as a side effect.

What computer do I need to run a simulator?

An ordinary laptop from the last few years runs the simulators a beginner should be using, and the requirement only climbs if you choose the photoreal ones. A machine with integrated graphics handles a wheeled robot, a room and simulated distance sensors without complaint. Ask for a camera producing convincing images with lighting and reflections and you are now asking for a dedicated graphics card, which is where people wrongly conclude that learning robotics demands an expensive computer. It does not. It demands choosing a simulator that matches your machine, and there is a good one at every level; the comparison of Isaac Sim, Gazebo and MuJoCo is largely a conversation about that trade. Linux is the practical choice because most robotics tooling assumes it, and a spare machine, a second boot option or a virtual machine all work. What your computer mostly needs is room for several programs at once, since the interesting problems only appear when a perception program, a control program and a logger are all running and disagreeing.

How long until I have something worth showing someone?

A month of evenings gets a simulated robot doing something intentional, and roughly six months gets a project somebody will want to talk to you about. The first month buys a robot that drives to a place and stops. The next two usually go into perception, because turning a camera image into a decision is where the genuine difficulty starts and where most people stall. Around then, stop following tutorials and pick a task nobody has written a tutorial for — a robot that patrols a simulated warehouse and reports what has moved, for instance — because an unsolved task is the only thing that produces the stories you will tell later. Do not expect a straight line. Expect two weeks lost to a coordinate frame that was rotated the wrong way, and another to a message nobody was receiving because two programs held different ideas about a name. Those weeks are the actual education, and they are the same weeks you would have lost with hardware, minus the shipping.

How much programming do I need before I start?

Enough to write a loop, a function and a class in one language, and that is the entire prerequisite. Python is the sensible starting point because nearly every robotics tool speaks it and because your first months should go on ideas rather than memory management; the comparison of first languages for robotics explains why the standard advice to begin with C++ is aimed at a different reader. Maths is less of a barrier than the internet implies. You need to be comfortable with a position being a few numbers and an orientation being a few more, and you can learn what you need about rotations at the moment you need it, which is when your robot faces the wrong way. What cannot be substituted is patience with things that do not work, because that describes most of the job on any given day. If you can debug a web application at midnight without giving up, you already have the temperament this asks for.

What do I give up by learning only in simulation?

You give up the entire physical half of the field, and it is worth being clear-eyed about what that includes. A simulator will not teach you that a cheap servo has slack in its gearbox, so the arm arrives somewhere slightly different each time you ask for the same position. It will not teach you that motors run hot and behave differently ten minutes in, that a connector works loose from vibration, or that a distance sensor reads confidently wrong on a shiny floor. It will not teach you to solder, to crimp a connector properly, or to recognise the smell that means stop now. You also miss the calibration work that eats real projects, where two sensors have to agree about where they sit on the same machine. None of that argues against starting in simulation. It argues for knowing that when you finally buy something, a whole category of problems you have never met arrives at once, and that they are mechanical rather than conceptual.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every beginner learning without hardware, and this is not a close call. Evenings spent learning are only worth it if the skills travel with you, and ROS 2 is what the jobs, the university courses, the open repositories and the tutorials all use, so every hour there is transferable currency. It also hands you the things you cannot yet write yourself: a working simulator bridge, navigation, mapping, and a visualiser that shows what the robot believes about the world. Even the installation struggle earns its keep, because the same struggle waits for you on the real machine. HORUS is not the answer for this reader: no navigation, no mapping, no drivers and no course to follow, and picking it first means learning robotics and building infrastructure at the same time. That layer gets interesting later, when you have a specific machine, several programs on it and a timing problem you can describe in one sentence.

Will employers dismiss a portfolio built entirely in simulation?

No, and here is why: nobody in robotics believes hardware experience and software judgement are the same thing, because they have watched each fail without the other. An interviewer is looking for evidence that you understand why a robot behaves differently on two identical runs, that you can explain what your control loop does when a sensor reading arrives late, and that you have debugged something you did not fully understand at the time. A simulated project demonstrates all three. What does get dismissed is a tutorial reproduced verbatim, and that applies equally to hardware projects, which are usually the same tutorials with a delivery charge attached. One caveat, stated plainly: teams hiring for bring-up and integration do want somebody who has met real motors, and no amount of simulation replaces that on their list. For perception, planning, controls and tooling roles, the evidence that counts is a project you can explain, and where it ran matters less than what broke inside it.

Does everything I build in simulation transfer to a real robot?

Partly, but not the way you think. The instinct is that the code transfers and the tuning does not, and the truth is closer to the opposite. Your architecture, your message shapes, your logging and your understanding transfer completely, and so does a surprising amount of the code, because a driver replaces the simulator underneath and the programs above it never notice. What does not transfer is everything downstream of the assumption that a number is correct. In simulation a wheel count is right, a distance reading is right, and time is exactly what the clock says. On a real machine readings arrive late, occasionally absurd and sometimes not at all, and code that never considered that possibility gets quietly confused instead of crashing. The habit to build now is not tuning; it is writing programs that decide what to do with a value that is old or nonsensical. That same question governs why a model can plan a task it cannot perform.

How do I decide what to start with this week?

Decide by saying your goal out loud, because an honest goal points at a different starting simulator. If the goal is a job in robotics, install ROS 2 with its default simulator and accept the first difficult week, because that combination is what the postings name. If the goal is a specific machine you already have in mind — a drone, an arm, a rover — find the simulator that machine's community uses, because your questions will then have answers waiting. If the goal is understanding rather than employment, a physics library and Python is a shorter path to insight and skips a stack you do not need yet. If you genuinely cannot tell, take the first option, since it is the least regrettable of the three. Then choose a task small enough to finish this month and boring enough that you will not be tempted to copy someone's solution. The ranked list of beginner simulators narrows the field further if you would rather compare before installing anything.

Take the line that matches your situation:

• If you want a robotics job -> ROS 2 with its default simulator, because that is the stack the postings name and the courses teach.
• If you want to understand motion and contact -> a physics library and Python, because a whole robot stack sits in the way of that question.
• If you have a graphics card and care about cameras -> a photoreal simulator, because vision is the skill that suffers most from unconvincing images.
• If you want to learn what a middleware really is -> write a small physics loop and put a real middleware underneath it, because building the wiring teaches what installing it hides.
• If you already have a specific robot in mind -> whatever its community uses, because your questions need to have answers.

The HORUS Fit Framework is the checklist behind those lines, and none of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target, and licence. As a beginner, weight ecosystem size heaviest, and revisit the other four the week you finally buy a machine.

Later, when your project has several programs on one computer and timing starts to matter, HORUS is open source under Apache-2.0 at github.com/softmata/horus. Star it so it is in your list when you start building.