The Cheapest Way to Start Building Robots in 2026

The cheapest start is a simulator on the laptop you already own, not a kit, not a single-board computer, and not a bought robot. Simulation costs only time and teaches the software half of robotics, where beginners actually stall, and open middleware such as HORUS runs on the machine you have. The verdict flips if your interest is mechanical, because no simulator teaches what a loose screw does. The rest of this post is for someone with a small budget, a working laptop, and no idea which purchase is the one that actually matters.

There is a tab open with a robot kit in it, and it has been open for two weeks. Next to it is a cheaper kit that looks worse, and a third one that looks better and costs what a month of groceries costs. Every video you watch has hardware you do not own. Every tutorial starts with a list that assumes you already bought something, and none of the lists agree with each other.

The uncomfortable part is not the money. It is that you cannot tell what the money buys. One person says get a Raspberry Pi. One says start with an Arduino. One says none of that matters and you should learn a simulator. One says simulators teach nothing until a real motor stalls in your hand. They all sound experienced and they contradict each other.

So the tab stays open, and the thing you actually want — something you built, moving, because of code you wrote — gets no closer. The longer it goes on, the more it feels like the entry fee for robotics is a purchase you are not qualified to make yet.

What is the cheapest way to start building robots in 2026?

Install a free simulator on the computer you already own and write control code against it tonight. That is the floor, and the floor is genuinely zero: the simulators worth learning on are free, the middleware worth learning is free, the languages are free, and a laptop from several years ago runs all of it. What you spend is evenings. This is the cheap answer rather than the lazy one because the part beginners get stuck on is not mechanical. It is the software: keeping a loop at a steady rhythm, deciding what to do when a reading is stale, working out why the robot turns the wrong way when the maths says otherwise. Every one of those appears in simulation exactly as it appears on a desk, and costs nothing when you get it wrong. Hardware is not optional forever; this is an argument about order. Buy hardware second, once you know which hardware your project needs, and the same money buys a better robot. There is a longer version of this case in learning robotics without buying a robot.

What does a beginner robotics setup actually consist of?

Four things, and only one of them costs money. You need a computer to write code on, which you already have. You need somewhere for the code to run, which is either a simulator or a board on a desk. You need something that carries data between the parts of your robot, which is either nothing at all for a first project or a middleware once there are several parts. And you need a way to see what happened, which means logging, plotting and replaying, because a robot that misbehaves for a tenth of a second cannot be debugged by watching it. That is the whole shape of a setup. Notice what is missing: motors, chassis, servos and sensors are the visible part of robotics and the last part to matter. A beginner with all four items and no hardware can write, run, break and fix real robot software. A beginner with a full kit and none of the four has an ornament and no way to make progress on the days it will not work.

What are the real cheap starting points?

There are about eight, and they sort by what you are trying to learn rather than by price. You can run a free simulator and write control code against a robot that does not exist. You can buy a microcontroller and a couple of motors, the cheapest hardware that teaches anything real. You can buy a single-board computer and a camera, which is where vision starts. You can buy a complete kit, the fastest route to a moving thing and the slowest route to understanding. On the software side you can learn ROS 2, which costs nothing but weekends and gives you the largest ecosystem in robotics, or you can learn a smaller middleware such as 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 on one machine are not serialised. Both are free downloads; the difference is what each one asks you to learn first.

What does a cheap start look like when it goes wrong?

It goes wrong as a box in a cupboard, not as a bad purchase. The usual sequence is recognisable. Someone buys a kit, builds it over a weekend, runs the demo that came with it, and then discovers that changing the demo means understanding a toolchain nobody explained. The instructions end exactly where the interesting work begins. A week later the parts are back in the box, and the conclusion drawn is that robotics is hard, when what was actually hard was starting at the wrong end. The second failure is subtler and costs more. Someone buys the recommended board, camera and motor driver, then spends six weekends on installation problems that have nothing to do with robots — a driver that will not build, a version mismatch, a supply that browns out under load. They learn nothing about robots and lose the enthusiasm they started with. Both failures come from one mistake: paying for capability before knowing which capability the project needs. Simulation is cheap partly because it makes that mistake reversible.

What should you buy first if you are learning alone with no mentor?

Buy nothing for the first month, then buy a microcontroller and two motors. Learning alone changes the calculation, because nobody is looking over your shoulder to say the wire is in backwards. Every purchase you cannot debug can stop you completely, and a beginner alone with a silent robot cannot tell a dead motor from a dead line of code. Simulation removes that ambiguity: when the simulated robot does the wrong thing, the fault is yours and it is in the code, which is a better place for a beginner's fault to be. After a month you will have opinions, and opinions are what make hardware worth buying. Then buy the smallest physical thing that can disappoint you: a microcontroller, two motors, a distance sensor. It is cheap enough that a mistake is not a setback, and it teaches the one lesson simulation genuinely cannot, which is that physical things are late, noisy and slightly different from each other. Beginner projects that teach the software side are a good source of first targets.

Which hardware is worth buying first when you do spend money?

A microcontroller and the cheapest motors that can move something, in that order, before anything else. The reason is that a microcontroller does one job at a steady rhythm and fails in ways a beginner can actually understand: nothing moves, or something moves wrongly, and there are ten lines of code between you and the answer. Add a distance sensor and you have the complete robotics loop — sense, decide, act — for the price of a couple of takeaways. The second purchase, much later, is a single-board computer with a camera, and it should wait until you have a specific reason. Vision turns the project from a loop into a system: several programs, running at different rhythms, that must agree with each other while the robot moves. That is a bigger problem and it is worth arriving at deliberately rather than by accident. If and when you get there, setting up a single-board computer properly saves a weekend of configuration you would otherwise donate to it.

What is the cheapest way to get something moving within a month?

A microcontroller, two motors, a battery pack and a chassis made of whatever is in the house. A month is enough time to go from nothing to a robot that drives across a room and stops before it hits a wall, provided you resist every temptation to make it more than that. The order matters more than the parts. Write the loop in simulation in week one, so you already know what the code should say. Buy in week two, because the parts arrive slower than you expect. Wire it and get one motor turning in week three, ignoring everything except that. Put the two together in week four. What ruins a one-month timeline is scope, not budget: a camera adds two weeks, a map adds a month, and a chassis you design yourself adds whatever the printer takes plus two revisions you did not plan. Cheap and fast are the same choice here, because every expensive part can arrive late, refuse to work, and take your month with it.

What if you have never written any code at all?

Start with Python on the laptop, not with a robot, and give it two weeks before anything is bought. This is the one case where buying hardware first is actively harmful, because a physical robot adds a whole second category of failure to a situation where you cannot yet tell why the first category is failing. When both the wiring and the code are unfamiliar, a robot that sits still teaches you nothing except discouragement. Two weeks of Python — loops, conditions, functions, reading a value, printing a value — is enough to make a simulator answer you, and a simulator that answers you is the fastest teacher available at any price. There is one honest exception. Some people learn nothing from a screen and everything from their hands, and if that is you, buy a microcontroller kit with a printed guide and accept that month one is about following instructions rather than understanding them. Both routes work. Which language to learn first settles the question that usually stalls people at this point.

What do you give up by starting in simulation instead of buying hardware?

You give up the physical lessons, and they are real lessons. A simulator will not teach you that a connector works loose, that a motor runs warm and behaves differently once it does, that a battery sags under load and browns out the board, or that two supposedly identical servos are not identical. It will not teach you the discipline of a robot that can hurt itself or you. And it flatters your code: control logic that works in simulation often meets the real world and discovers that its sensor readings arrive late, jitter, and occasionally lie. That gap is why nobody serious stays in simulation forever. What simulation gives back is the ability to be wrong all evening at no cost, which is what learning consists of. The mature position is not to choose but to sequence: write it in simulation, then port it and expect the port to be humbling. Why a robot that works in simulation fails in your kitchen is worth reading before the port rather than after.

When is ROS 2 the better choice?

ROS 2 is the better choice the moment your goal is a job, a lab, or a robot built mostly from other people's code. If you want to be employable in robotics, ROS 2 is on the job description and no amount of elegant alternative experience substitutes for it, so learn ROS 2 first and treat the weekends as tuition. At a university, everyone around you speaks ROS 2, and shared vocabulary is worth more than any technical property. If your robot must map a building and navigate to a goal, the mapping and navigation packages exist, they are free, and rewriting them is not a beginner project or even a small-team one. If the sensor you bought has exactly one driver and it is a ROS 2 package, the decision is made for you. HORUS is not the answer in those cases, and picking it there means paying in unwritten code for a saving you will not notice on a first robot. The cost of ROS 2 is genuinely time rather than money, and for these goals the time is well spent.

Is the cheap path just a slower path to the same place?

No, and here is why: the cheap path is faster, not slower, for the first several months. Speed in early robotics is measured in attempts, not purchases, and the cheap path maximises attempts. A simulator lets you try an idea, watch it fail, change one thing and try again before the kettle boils. A physical robot makes every attempt cost a battery charge, a re-wire and a walk across the room, and it adds a second question — is this the code or the hardware? — to every single failure. The expensive path only wins once your questions are physical, and beginners do not start with physical questions. They start with questions about logic, timing and structure. Buying hardware early does not answer those; it hides them behind a layer of doubt. Spend the money later, when you know the exact shape of what you need, and the same budget buys a machine you are ready to use.

Does starting cheap mean you only learn a toy version of robotics?

Partly, but not the way you think. The toy part is not the software — control code, state machines, sensor handling and coordinate frames are the same ideas in a simulator and on a factory floor, and the code you write against a good simulator is real code that would run on real hardware. The toy part is the physical envelope: a simulator will not teach you what a heavy arm does to its own mounting, or how a machine behaves in its fifth hour rather than its first, or what safety means when something can actually hurt someone. That is a genuine gap and it does not close by itself. What it does not mean is that the cheap start teaches bad habits. The habits that transfer badly come from elsewhere — a single file that does everything, control logic tangled with the code that talks to hardware, never writing down what a message contains. Those are avoidable in simulation for free and expensive to unlearn later. Whether robotics can be learned entirely in simulation sets out where the line actually falls.

What starts costing money once the robot has to do something real?

Sensors, power, and the second computer, in that order, and none of them are the ones beginners budget for. A robot that drives around a room costs very little. A robot that knows where it is costs meaningfully more, because knowing where you are means a better sensor and often a camera that sees depth. Power is the quiet expense: motors that can move a load want a battery and a supply that will not collapse when all of them start at once, and everyone learns this by having their board reboot mid-turn. The second computer arrives when one board is asked to run vision, a model and a control loop at once and starts choosing between them. That is also where the software question stops being cosmetic, because several programs on one machine are now trading pictures and none can afford to wait. Notice this progression before you are in it, so each purchase answers a problem you already have.

How do you decide what to spend money on first?

Write down the one thing you want your robot to do, then buy only what that sentence requires. If the sentence is "drive across the room and stop before the wall", the sentence requires a microcontroller, two motors and a distance sensor, and everything else on your shopping list is for a different sentence. If the sentence is "recognise my cat and follow it", the sentence requires a camera and a board that can carry a model, which is a larger purchase and a much later project. If the sentence has the word "eventually" in it, delete the word and buy nothing yet, because eventually is not a specification. Two rules keep the budget honest. Buy what you can afford to break, because you will break it, and a part you are frightened of is a part you will not experiment with. And buy late rather than early: parts get cheaper, requirements get clearer, and the money you did not spend in week one buys a better decision in week six.

Decide by situation rather than preference:

• If you have a laptop and no budget -> a free simulator tonight, because the software half is where beginners actually stall.
• If you want something physical this month -> a microcontroller and two motors, because it is cheap enough to break and real enough to teach.
• If you are aiming at a robotics job -> ROS 2 on your laptop, because the ecosystem is the thing employers are asking about.
• If your robot must see or map -> a single-board computer and a camera, because vision is the first thing a microcontroller cannot do.
• If you have never written code -> two weeks of Python before any purchase, because a silent robot cannot tell you which half is broken.
• If you are near a club or a lab -> borrowed hardware, because someone else already paid for the expensive mistake.

When two options look equally affordable, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the one that loses on the fewest. No scores and no numbers: five honest questions about your situation rather than about the software. Cost is not one of the axes, because almost everything worth learning on is already free, and what you are really budgeting is weekends. If your first real project lands on one computer with more than one language in it, HORUS is Apache-2.0 and developed in the open at github.com/softmata/horus — star it so it is in your list when you start building.