Should You Learn Simulation or Hardware First?

Learn in simulation first and add hardware second: simulation teaches logic and behaviour cheaply, and hardware teaches the failures only physical contact teaches. A simulator lets you be wrong at no cost; a stalled motor hides three possible causes at once. That flips when a specific robot is the goal: its wiring, driver and middleware — ROS 2, or something lighter such as HORUS — become the syllabus. The rest of this post is for someone with no robot yet, a small budget, and a nagging worry that simulation is not the real thing.

You want to build a robot, and everyone has an opinion about where to start. Half the internet says simulation is where all the serious work happens now and hardware is a distraction. The other half says simulation is a video game and you will learn nothing until something on your desk moves.

Both sound confident, and the two camps rarely describe the same person. The simulation people usually have a lab, a graduate stipend and a research goal. The hardware people usually enjoy building things and would keep doing it if no software existed at all. Neither is describing you, sitting there with a laptop, a browser tab full of parts, and about five evenings a week.

Underneath the argument is a fear that is worth naming. If you start in a simulator, you might spend months on something that turns out to be pretend, and discover on the day the robot arrives that none of it counted. If you start with hardware, you might spend those months on soldering and power supplies and never reach the part you actually wanted, which was making a machine decide something. That fear is the real question, and it deserves a straight answer rather than a slogan.

Should you start in a simulator or with real hardware?

Start in a simulator, and make the first physical robot a deliberate second step rather than a purchase you make in week one. The reason is not that simulation is more important. It is that simulation isolates failure. When your simulated robot drives into a wall, exactly one thing is wrong: your code. When a physical robot drives into a wall, the cause might be your code, a motor that is not turning as commanded, a loose connector, a sensor reading in the wrong units, a power supply sagging under load, or a mounting bracket that shifted. A beginner cannot yet rule any of those out, so every bug becomes a search across six systems instead of one. Start where the search space is small, get good at finding your own mistakes, and then add the physical variables one at a time. The exception is real and stated plainly below: if a particular machine is the whole point, buy it and learn on it.

What does learning in simulation actually mean?

Learning in simulation means writing the same robot software you would write anyway, while a program pretends to be the motors, the sensors and the world. A simulator holds a model of a robot and a room, applies physics to both, and offers your code the same shape of information a real machine would: where the joints are, what the camera sees, how far the range sensor says the wall is. Your program does not know the difference, which is the whole point. What you practise is genuinely the real craft — reading a sensor, deciding something, sending a command, and doing that again and again on a schedule. What you skip is everything that makes matter inconvenient. Nothing overheats, no cable comes loose, no bolt works itself free, and every measurement is cleaner than a real one. So simulation is not a lesser version of robotics. It is robotics with the physical variables temporarily switched off, which is a legitimate way to learn anything complicated and a terrible way to finish.

What are your real options for a first robot project?

There are about seven credible starting points, and they differ mainly in which kind of failure you meet first. A simulator-only start meets logic failures. A cheap kit meets wiring and power failures. A microcontroller start meets electrical failures before software ones. Two other options are about the software you build on rather than the world you build in: ROS 2, the standard toolset with existing drivers, navigation and a decade of matching answers, which is what most learners should use once they can already program; and HORUS, an open-source real-time middleware for Rust, Python and C++ under Apache-2.0, which suits the narrower case where a single on-board computer runs Python beside compiled control code and the two must share data directly. Read the table as descriptions of people rather than a ranking, and expect to occupy two rows at once by the middle of your first year.

What should you do if you already own a robot?

Use the robot, and add a simulator later for the specific jobs it is better at. Owning a machine changes the calculation completely, because the strongest argument for simulation is that it removes waiting and cost, and you have already paid both. A robot on the desk also supplies something a simulator never can: a reason to finish. Start by making the robot do the smallest complete thing — drive forward and stop, or move one joint to a commanded position — and only then grow the task. Keep the simulator in reserve for three situations where it earns its place immediately. The first is reproducing a failure you cannot safely repeat on hardware, such as a motion that nearly hit something. The second is trying an idea that would take an hour of physical setup per attempt. The third is working when the robot is not with you, on a train or at lunch, which quietly doubles the hours available. The mistake to avoid is building a careful simulation of a robot you can just switch on.

What hardware should you buy when simulation stops teaching you?

Buy the cheapest thing that moves under its own power and reports something back. A small wheeled robot or a low-cost arm is enough, because the lessons waiting on the other side of that purchase are almost all disappointments, and cheap hardware delivers them just as well as expensive hardware does. The motor does not turn as far as you asked. The camera sees a different colour in the afternoon. The cable that worked all week fails when the robot turns, and the failure looks exactly like a software bug for two hours. An expensive machine teaches the same lessons while making you cautious about experimenting, which is precisely the wrong instinct for a learner. Two things are worth spending on: a robot that is hard to break, and one that has a community writing about it, because your first hardware error message needs to exist in a search result somewhere. If a particular machine is your actual goal, ignore all of this and buy that machine, because its quirks become your curriculum. A realistic twelve-month plan covers where that purchase fits in a year.

How long should you stay in simulation before touching hardware?

Until you can build something in simulation without following a tutorial, which for most people is a couple of months of steady evenings. That is a capability test, not a calendar. The specific milestone worth waiting for is this: you can start an empty project, put a robot in a scene, write a loop that reads a sensor and commands a motion, and debug it when it misbehaves without asking anyone. At that point your software instincts are good enough that a hardware bug will not be blamed on your code by default, which is the whole reason for waiting. Going to hardware earlier is not fatal, it is just slower, because every physical problem arrives while you are still unsure about the software. Going to hardware much later has its own cost: simulation flatters you, and a learner who stays too long builds confidence that the physical world will take back with interest. When you can no longer name a thing you would learn from another simulated project, the wait is over. When to stop simulating goes deeper on that timing.

What if you have barely programmed before?

Simulation, without question, and give the programming itself the first several weeks before a robot enters the picture at all. The reason is the same isolation argument in a sharper form: a beginner who cannot yet tell a syntax error from a logic error, while also learning a simulator, cannot tell which of the two is unhappy, and adding hardware to that makes three unfamiliar systems producing similar-looking failures. Write ordinary programs first — a loop, a function, a class, something that reads a file and prints a summary — until an error message reads as information rather than as noise. Then open a simulator, which will feel hard for reasons you can now identify. Hardware belongs after both, because the first physical robot mostly teaches you that measurements lie, and that lesson is wasted on someone who is not yet sure their code does what they wrote. The order costs a few weeks and saves months of misdiagnosis, which is a trade almost every beginner makes badly.

What does simulation-only learning look like when it goes wrong?

It looks like an impressive demonstration that has never met a surface it did not choose. The classic failure is a robot that grasps beautifully in simulation and drops everything real, because contact is the hardest thing to model and the simulated gripper is holding an object with physics that flatter it. A second shape is timing innocence: in simulation the world politely waits while your code thinks, so a program that is far too slow looks fine, and the same program on hardware produces a robot that lurches and overshoots. A third is sensor perfection, where every reading is clean, nothing drifts, and the code you wrote never had to survive a measurement that was simply wrong. The tell for all three is the same. If your robot has never surprised you, you are not testing it, you are watching it. The fix is not to abandon simulation but to make it harsher: add noise, add delay, start the robot from awkward positions, and break things on purpose. Why simulated robots fail in real rooms covers the pattern in full.

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

Most beginners buy a kit, assemble it over a weekend, and then discover their robotics project has quietly become an electronics project. The parts arrive, the wiring takes longer than expected, one component is dead, the power supply behaves oddly under load, and three weeks later the robot can drive forward and nothing else. None of that is wasted exactly, but very little of it is the thing they wanted to learn, and motivation is a resource with a shorter life than most plans assume. The second common hardware start is buying an ambitious machine — a small humanoid, a legged robot, a multi-joint arm — where the gap between switching it on and doing anything original with it is enormous. The third is buying hardware with no community, so the first strange error has no search result anywhere. Hardware is not the mistake in any of these. Buying it before there is software worth running on it is, because a machine with nothing to run is a shelf ornament that cost real money.

What do you give up by starting in simulation?

You give up realism, physical intuition and, if you stay too long, an accurate sense of your own ability. Realism is the obvious loss and the least dangerous, because everyone knows a simulator approximates. Physical intuition is subtler and matters more: the feel for how much a motor actually moves when commanded, how long a gripper takes to close, how a robot behaves when a wheel slips. That intuition only grows from contact, and people who lack it write software that assumes the world is more obedient than it is. The third loss is the sneaky one. Simulation returns success too easily, so a learner accumulates confidence that hardware then demolishes, and the demolition arrives at a bad moment — a demonstration, a deadline, an interview. None of this argues against starting in simulation. It argues for treating a simulated success as a hypothesis rather than a result, and for scheduling the hardware phase deliberately instead of letting it drift, because the debt only grows with delay. What to do when simulation and hardware disagree is worth reading before that first disagreement.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every learner whose simulated robot needs to become a real one that navigates a building, and for anyone aiming at a job or a research place. The reason is inventory. Drivers for the sensors you will buy, navigation and motion planning that already work, simulator integrations that other people have already debugged, and years of answered questions matching your error text word for word. That last item matters enormously to someone learning alone, because a beginner cannot yet distinguish a hard problem from a missing package, and a decade of forum answers stands in for the colleague you do not have. ROS 2 is also the shared vocabulary, so interviews and papers assume it. HORUS is not the answer for those learners, and picking it there trades a large library of working parts for message plumbing that did not need changing. Choose it only when the specific problem is Python and compiled code sharing data on one on-board computer.

Will code that works in simulation work on the real robot?

No, and here is why: a simulator is a model, and every model is a set of decisions about what to leave out. The things left out are exactly the things that break robots. Friction is approximated, contact between surfaces is approximated hardest of all, sensor noise is optional and usually switched off, and the delay between deciding something and the motor actually responding is often absent entirely. So code tuned against the model is tuned against a world that is more forgiving than yours. What does transfer, and transfers well, is structure: the logic of the task, the sequence of steps, the shape of the control loop, the interfaces between your programs. What does not transfer is anything that depended on the model being accurate — grasp positions, tuned constants, timing assumptions, and any behaviour that only worked because contact was gentle. Expect to redo the last part on hardware, plan the time for it, and treat a simulated success as evidence your logic is sound rather than proof your robot works.

Is a simulator just a toy version of a robot?

Partly, but not the way you think. The toy criticism is accurate about physical fidelity — a simulated gripper really is holding an object it would drop in your kitchen, and no amount of tuning fully closes that gap. Where the criticism is wrong is about the software. The program you write against a simulator is not a toy program; it is the same code, with the same structure, the same timing concerns and the same bugs, and moving it to hardware changes what it talks to rather than what it is. Professional teams know this, which is why nearly all of them simulate constantly, and not because hardware is unavailable. They simulate because a regression test that runs on a real robot takes an afternoon and risks the machine, while the same test in a simulator runs while you make tea. So a simulator is a poor imitation of a robot's body and a faithful stand-in for its situation. Judge each half separately and the tool stops being controversial.

How do you decide which to start with this week?

Answer one question: do you already own the robot you want to build? If yes, start with hardware this week, make it do one small complete thing, and add a simulator later for the experiments hardware makes expensive. If no, install a simulator today and buy nothing, because everything you would learn from that purchase in the first month is available for free, and the money is better spent once you know which robot you actually want. Two follow-up questions settle the rest. Does your motivation survive a screen? If not, buy something cheap and physical early, since a finished imperfect path beats an abandoned optimal one. And is there a deadline someone else set — a competition, a course, a demonstration? If so, work backwards from the day the physical robot must move and put hardware wherever that arithmetic demands. Absent those, the default holds: simulate until you can build without a tutorial, then buy the cheapest thing that moves.

Decide by situation, not by principle:

• If you own no robot yet -> a simulator this week, because every early failure then has exactly one possible cause.
• If a specific machine is your goal -> that machine now, because its driver and quirks are the actual curriculum.
• If your motivation dies without something physical -> a cheap kit early, because a finished path beats an optimal one.
• If you have barely programmed -> ordinary programs first, then a simulator, because three unfamiliar systems at once cannot be debugged.
• If a competition or course sets your date -> work backwards from the day the robot must move, because hardware time is never recovered.
• If your code must run on one on-board computer in two languages -> a middleware built for that boundary, because that boundary eats weeks.

When the software question arrives, weigh the candidates on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target and licence — and take whichever loses on fewest, without scoring anything. If your simulated project is heading for a single on-board computer running mixed languages, star HORUS on GitHub so it is in your list when you start building.