When Should You Stop Simulating and Build the Real Thing?

Move to hardware once the simulator stops surprising you, which for a first robot arrives earlier than the tutorials and the demo videos imply. Simulation is good at catching crashes, wrong signs and logic that was never going to work, and it is poor at friction, wiring and timing. The verdict flips when a mistake breaks a machine or a person, in which case simulate longer. The rest of this post is for someone with a working simulation, a parts list, and no idea whether next month goes into ROS 2, HORUS, or soldering.

You have had a robot driving around inside a simulator for weeks now. It navigates a room you built, avoids a chair you placed, and stops before it hits the wall. Every so often you add a feature, watch it work, and feel a small flicker of doubt, because none of it has ever touched a floor.

Meanwhile the parts you ordered are in a box. You keep not opening the box, because opening it means finding out that a motor turns the wrong way, that a connector does not fit, that the battery you chose is heavier than the frame likes. In the simulator nothing is ever wired incorrectly and nothing ever arrives late.

You have also read enough forum threads to know what usually happens next. Somebody posts a video of a perfect simulated robot, then a second video of the same robot on carpet, twitching and drifting and stopping for no reason anyone can name, followed by two hundred replies arguing about friction values.

So the question you actually have is not which simulator to use. It is whether one more week in there is preparation or avoidance, and nobody who writes tutorials seems willing to say.

When should you stop simulating and start building hardware?

Stop when the simulator has stopped teaching you things you did not already know. That is the only test that works, because it is about information rather than about a schedule. For the first week or two the simulator finds a bug every session: a wheel spinning the wrong way, a sensor pointed at the ceiling, a program that dies quietly when a message arrives before it is ready. Those are worth having found at a desk. When three sessions in a row end with the robot doing exactly what you expected, you are no longer testing, you are watching.

The second test is whether the questions you have left can be answered in there at all. Whether the planner picks a sensible route is a simulator question. Whether the wheels slip on your actual floor, whether the connector rattles loose, whether the battery sags when the arm lifts: none of those are simulator questions, and no amount of tuning turns them into simulator questions.

If both tests point the same way, open the box. If they disagree, give it one more week and keep a daily log, because that settles the argument faster than opinion does.

What is a simulator actually for in a robot project?

A simulator is a place to make cheap mistakes, and that is nearly the whole of its job. It does three things: it works out where objects end up given masses and forces, it draws what a camera would have seen, and it pretends to your software that it is a set of motors and sensors. The third job is where beginners get the most value and expect the least.

That pretending is what lets you find the ordinary bugs. A transform with a sign flipped. A program that never started. An arm that plans a path through its own base. A message nobody is listening to because two names differ by a letter. Every one of those is boring, every one costs an afternoon at a desk, and one of them costs a gearbox on hardware.

What the simulator cannot do is prove that the robot works, because it only models what somebody remembered to model. A simulator that has never surprised you is not a validated design, it is a mirror, and choosing between the main ones is a separate decision covered in which simulator fits which project.

What are the real options between a simulation and a finished robot?

There are about six moves available, and most projects need three of them in order rather than a choice between them. You can keep simulating. You can build a bench rig: one motor, one sensor, clamped to a desk, wired to the real computer. You can buy a cheap ready-made robot as a stand-in and port your code onto it. You can buy the platform you actually intend to ship. You can build custom hardware from parts. Or you can run hardware in the loop, where the real computer and the real software run against a simulated world, so the timing is real even though the floor is not.

Underneath all of those sits a separate decision about what your programs talk through. That is usually ROS 2, sometimes a vendor's own stack, and sometimes a middleware such as HORUS, 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 between programs on one machine are not serialised. That project is Apache-2.0, validated in simulation, and it is not a simulator, not a robot, and not a full replacement for ROS 2 on every project.

How do the paths out of simulation compare?

Read the last column first, because these options get eliminated rather than chosen. Your budget, the parts already in the drawer and the week you can actually spare will cross out most of this table before preference gets a vote.

Nothing in that table ranks how realistic each option is, because realism is not what decides a first build. What decides it is how quickly the option can tell you that you were wrong.

Are you a student, a hobbyist, a startup or a research group?

A student should get to hardware early, a hobbyist should get there immediately, a startup should get there as soon as the mechanism is settled, and a research group is the only one with a good reason to stay in simulation for a long time.

For a student the point of the exercise is usually to learn what the real world does to a clean idea, and that lesson does not exist inside a simulator. A hobbyist has the smallest downside of anyone: the robot is light, it costs a weekend to repair, and the motivation that keeps the project alive comes from a machine moving on a table rather than from a window on a laptop.

A startup has one dangerous failure mode, which is a beautiful simulation hiding a mechanism nobody has built. Get a rough version of the real machine moving badly, early, because assumptions compound faster than parts arrive.

A research group with an expensive platform and a paper to write is the genuine exception, and even there the handover is where the trouble sits, which is why projects stall after the prototype.

What hardware do you already have on the bench?

What you already own decides your first move more than any preference does. A drawer with a hobby servo, a small microcontroller board and a single-board computer in it is enough to start a bench rig this evening, and a bench rig answers more questions than another simulated room will.

If the robot you intend to ship already exists as a product you can buy, buying it early is almost always right, because your software gets to grow up against the real thing rather than against a description of it. If the robot is your own design and the frame is still being drawn, the honest answer is that you cannot leave simulation yet, and the correct move is to shrink the gap: build one subassembly, one arm, one leg, one drive wheel, and get real motion out of it while the rest is still on a screen.

Watch out for the mismatched stand-in. Testing on a small wheeled robot teaches you plenty about your code and almost nothing about a much heavier machine, so treat those results as a check on your logic rather than on your design.

How much time do you have before something has to move?

If a demonstration is weeks away, stop simulating now, and if the deadline is quarters away, a longer simulation phase can pay for itself. The reason is that the hardware phase has a floor under it that no amount of preparation removes. Parts arrive late. A connector is the wrong gender. The motor driver needs a firmware update that needs a cable you do not own and a computer running an operating system you do not have.

Teams routinely lose weeks to that floor and are shocked by it, because the simulation phase felt like progress and had no shipping delays in it. Budget for the floor by hitting it early, when it costs a week, rather than late, when it costs the demonstration.

A longer runway changes the calculation honestly. With months to spend, building an accurate model of a robot that does not exist yet can save a redesign, and the modelling work itself, the masses, the joint limits, the sensor placement, forces design conversations that otherwise happen after the metal has been cut and the invoice paid.

How much do you need to know before you touch real hardware?

Less than you think for a small robot, and considerably more than you think for anything heavy. For a desk-sized machine the entry requirements are short and honest: how to power something without releasing the smoke, how to read a wiring diagram, how to notice a motor that is getting hot, and enough restraint to test with the wheels off the ground first.

The skill that separates people is not electronics, it is method. Change one thing at a time. Write down what you changed. Keep a stand or a clamp so the robot cannot run away from you. Have a physical switch you can reach without thinking about it. Everybody learns these eventually, and the ones who learn them by reading keep more fingers than the ones who learn them by experiment.

The software side needs less preparation than the forums imply. You do not need to understand the whole of a middleware to make one wheel turn, and the quickest way to find out which parts you actually need is to make one wheel turn.

What do you give up by moving off the simulator?

You give up the ability to repeat a test exactly, and that costs more than beginners expect. In simulation a failure can be replayed until you understand it. On hardware the battery is a little lower, the floor is a little dustier, the room is a little warmer, and the failure that happened twice this morning refuses to happen again while you are watching it.

You also give up speed of iteration. A change that took a keystroke now takes a rebuild, a flash, a walk across the room and a robot picked up off the floor. Teams that move to hardware and abandon simulation entirely come to regret it, because the simulator stays the cheapest place to test everything that has nothing to do with physics.

And you give up a certain kind of nerve. The first time a real machine lunges is genuinely alarming, and people respond by testing less, which is exactly backwards. The fix is mechanical rather than emotional: a stand, a clamp, a strap, a low speed limit, and the freedom to be wrong safely.

When is ROS 2 the better choice?

ROS 2 is the better choice for a first real robot in almost every case, and HORUS is not the answer for someone whose actual problem is that nothing has drivers yet. The moment you move to hardware you need code for a motor controller, a depth camera, a laser scanner, an inertial sensor and a battery monitor, and ROS 2 has that code already, written by people who owned the same parts and hit the same firmware quirks you are about to hit.

ROS 2 also wins on being able to see what happened. Recording a run and replaying it at a desk afterwards is the single habit that most changes how quickly a team understands its own machine, and on hardware, where nothing repeats, that recording is often the only evidence you get.

And it wins on help. When a real robot behaves oddly at eleven at night, the value of a large community is that somebody has already posted your exact symptom, which is the strongest argument in whether you actually need ROS 2 at all.

Does a robot that works in simulation work on the first day of hardware?

No, and here is why: a simulator models the parts of the world somebody remembered to model, and the first day is dominated by the parts nobody did. The floor in the simulator has one friction value. The real floor has dust, a threshold strip, a patch a cleaner made slippery, and a slope you never noticed until a robot rolled down it.

The pattern repeats everywhere. The simulated gearbox transmits motion exactly and the real one has play in it, so the arm stops in a slightly different place each time. The simulated camera returns a clean image immediately, and the real one adjusts its exposure as the robot turns towards a window, hands you a blurred frame, and hands it over later than the code expected.

Then there is the clock. In a simulator, time waits for your program. On a robot, time does not, and code that was never late in simulation starts being late, which is why a machine can behave differently on every run.

Will another month in the simulator make the first hardware day go smoothly?

Partly, but not the way you think: another month removes more of your logic bugs and does not touch the category of problem that eats the first day, which is everything physical and everything about timing. Simulation is genuinely good at finding the arm that plans through its own base and the state machine that gets stuck waiting for a message. It has nothing at all to say about a screw that works loose.

The useful version of that month has a different shape. Spend it making the software easier to move: keep the parts that talk to hardware separate from the parts that decide things, so swapping a simulated motor for a real one is a configuration change rather than a rewrite. Spend it on recording and replay, so the first hardware failure leaves evidence behind. Spend it building a way to stop the robot instantly from across the room.

That work pays for itself on hardware. Another week of tuning friction values for a floor you have never measured does not, and it is the most common way a month quietly disappears.

What actually goes wrong on the first day the real robot moves?

Power, wiring and units, in roughly that order, and almost never the algorithm you were worried about. The battery cannot supply what the motors ask for when they all start at once, so the computer resets in the middle of a manoeuvre and you spend an hour blaming your code. A connector looks seated and is not. A motor is wired backwards, so the robot corrects a drift by driving further into it.

Units are the quiet one. Somewhere between your code, a driver and a motor controller, one side is working in degrees and the other in radians, or one is counting encoder ticks where the other expects metres. The symptom is a robot that moves confidently in roughly the right direction and stops in the wrong place, which reads like a tuning problem and is not one.

Then there is heat, which nobody simulates. Motors that were fine for a minute get hot over an afternoon, their behaviour changes as they do, and a machine tuned when cold behaves differently after lunch. Write down what you change, because you will need the list.

How do you decide that you have simulated enough?

Write down the three questions you still want answered, then mark each one as answerable in a simulator or not. That list is the decision and it takes about ten minutes. Questions about logic, sequencing, geometry and whether a plan is sensible belong in the simulator. Questions containing the words friction, wiring, heat, battery, vibration, timing or "in a real room" do not, and no amount of tuning moves them across.

If two of your three questions sit on the hardware side, the simulator has finished its shift.

The second test is emotional and more accurate than people like to admit. If you find yourself adding features to the simulation that the robot does not need, building a nicer world, modelling a room you will never drive through, then the simulator has stopped being a tool and started being a hobby inside a hobby. That is a good thing to notice rather than a shameful one, and the cure is a bench rig on a desk by Saturday and a robot that fails at something by Sunday.

Here is the decision in five lines.

• If you are a hobbyist with a small robot -> build it now, because the downside of a mistake is a weekend and the upside is motivation.
• If you are a startup whose mechanism does not exist -> build a rough version badly and early, because assumptions compound faster than parts arrive.
• If your remaining questions are about friction, wiring or heat -> stop simulating, because those answers do not exist in there.
• If your remaining questions are about logic and sequencing -> stay in simulation, because a mistake there costs an afternoon rather than a gearbox.
• If the robot is heavy or moves near people -> keep simulating and build a stand, because the first real motion should be one you can survive being wrong about.

The HORUS Fit Framework reduces the software half of this to five axes you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. On the day the box gets opened, ecosystem size and deployment target usually decide it, and licence matters the first time a client asks who owns the result. The same axes decide again later, which is where a beginner's map of humanoid programming picks the thread up.

The week the simulated robot works and the real one does not is a bad week to start reading about middleware. Put HORUS on the shelf before then: star it so it is in your list when you start building.