What Nobody Tells You About Your First Real Robot

Nobody tells you a first robot is mostly plumbing and timing, so the choice between plain code, ROS 2 and HORUS arrives early. The mechanics and the clever behaviour are the parts you can picture, and they are rarely what stalls the project; what stalls it is two of your own programs sharing one computer badly. That flips the moment your robot needs a map of a room. The rest of this post is for someone building a first machine that has to work outside a tutorial, and wondering what they have not been warned about.

You have watched the videos. Someone drives a small robot around a kitchen, an arm picks up a cup, a four-legged machine trots over gravel, and none of it looks like a software problem. So you buy a chassis, a couple of motors, a distance sensor and a small computer, and you write the loop you have been picturing for weeks. It works on the desk. Then you put it on the floor.

Now the robot drives into the chair leg it clearly saw. The wheels twitch while the camera is running and stop twitching when you turn the camera off. Something freezes after twenty minutes and nothing in the log says why. You add a print statement and the problem moves somewhere else. You search for the symptom and every answer assumes you already have a framework installed, that you know what a node is, and that the word workspace means something specific to you.

The frustrating part is that none of it is about robots. You did not sit down to learn about processes, clocks and start-up order. You sat down because you wanted the arm to stop before it hits the table.

What does nobody tell you about your first real robot?

Most of your build time goes into getting your own programs to cooperate on one computer, not into anything a video would call robotics. The mechanics are largely solved for you by whatever chassis or arm you bought. The behaviour you care about — drive forward, watch the distance reading, stop before the wall, back up, turn — is genuinely a page of code, and you will write it faster than you expect. What eats the calendar is everything around that page. Which program starts first, and what the motors are doing during the second before the decision-making program is ready. What happens when the camera program dies at midnight and nothing restarts it. How a picture taken a moment ago gets lined up with a wheel position taken now, so the robot acts on where it is rather than where it was. None of this appears in the videos, because experienced builders stopped noticing they were doing it. It is invisible work that looks like incompetence when you are the one discovering it.

What is robot middleware, in plain terms?

Middleware is the part of a robot's software that carries messages between your programs and decides who waits for whom. Picture three programs on one small computer: one talks to the camera, one decides what to do, one drives the wheels. Middleware is the corridor between those rooms, plus the rules about what happens when the corridor is full, when a room is empty, and when one occupant is slower than the others. It is not the brain, it is not the drivers, and it is not a simulator. The reason a robot ends up with separate programs at all is that some jobs take a long, unpredictable breath. Handling a camera frame is one of those. If that work shares a program with the loop commanding your motors, the motors get commanded late, and late commands look exactly like a badly tuned controller. Most first robots start with no middleware and that is the correct choice, which is why what middleware actually does only becomes interesting later.

What are your actual options for a first robot's software?

Six routes come up, and they differ mainly in how much of the robot is code somebody else already wrote. The first is a single program with no middleware: one loop, ordinary function calls, nothing to install. The second is firmware on a microcontroller, where the whole behaviour lives on the board. The third is the software that came with your kit or your bought arm. The fourth is ROS 2, the large open ecosystem, which brings drivers, mapping, navigation, a viewer and recording tools alongside its own messaging, and asks you to learn its shape in return. The fifth is a small 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 programs on one machine are not serialised; the licence is Apache-2.0, the project lives at github.com/softmata/horus and is validated in simulation, and it is not a simulator, not an inference engine and not a full replacement for ROS 2. The sixth is a network transport or message broker, for robots split across machines.

How do the options compare for a first robot?

Read the third column first, because a route you cannot debug alone at eleven at night is not really available to you whatever else it offers. Then read the last column and cross out every row that describes your situation this month. What usually survives is a pair rather than a winner: something to start on tonight and something to grow into later, which is a healthier result than a single answer you have to defend. The rows are also not exclusive, and reading them as rivals is the commonest mistake beginners make with a table like this one. Firmware on a small board talking to a program on a Linux computer is one of the most ordinary shapes a first robot takes, and a kit's own software usually sits underneath whichever route you pick rather than competing with it.

Who should build a first robot with no framework at all?

Anyone whose robot is one sensor, one decision and one motor should start with no framework, and that covers most first machines honestly described. If you can state the behaviour in a sentence — it drives until something is close, then stops — there is nothing for a messaging layer to carry, and installing one buys you concepts to learn instead of a robot to watch. The people who should not take this route are recognisable by their sentence needing an "and at the same time" in it. It follows a line and at the same time watches for a hand. It records video and at the same time holds a wheel at a set speed. That conjunction is the tell, because it means two rhythms, and two rhythms in one loop means one of them is being starved. The other group who should skip the plain route is anyone whose robot must build a map, since that is not a thing you will write on a first project and should not try to.

What hardware should a first real robot run on?

The smallest computer that can run the language you can already debug, which for most beginners is a microcontroller or a small single-board Linux computer. A microcontroller is the honest choice when the robot's whole job is reading a few sensors and driving motors: nothing to install, nothing to start in the right order, and behaviour that begins the instant power arrives. A small Linux board becomes necessary the moment a camera is involved, because handling pictures wants a real filesystem, real libraries and more memory than a board offers. That camera is the fork in the road for almost every first project. Before it, one program is plenty and the whole robot fits in your head. After it, you have a slow job and a fast job on the same computer, and the fast job starts losing. Buy the board that matches which side of that fork you are on, not the most capable one you can afford, because a larger computer solves none of the timing questions and adds a longer boot to every test.

How much time should a first real robot take?

Expect an evening for the first motion on a bench, a few weekends for something that survives the floor, and months before it runs while you are out of the room. Those three milestones feel like one job when you plan, and they are three different jobs. The first is wiring plus a dozen lines. The second is where the surprises live: a motor that draws more current under load, a sensor that reads differently in sunlight, a loop that was fine until the battery sagged. The third is a category change, because unattended operation means deciding what happens when a reading never arrives and what the motors do when the program that commands them stops existing. Beginners routinely quote the first milestone to friends and then feel like they are failing for the next two months, when in fact they are exactly on schedule. If you want that broken down properly, how long it takes to get a robot moving walks through each stage.

What skills do you need before you start one?

Enough of one programming language to read an error message and find the line that caused it, without help. That is the whole entry requirement, and it is lower than the internet implies. What matters more than fluency is a habit: changing one thing at a time when the machine behaves differently on two consecutive runs. Robots punish the instinct to fix three things at once, because the hardware is genuinely non-deterministic and you will convince yourself a change worked when the robot merely got lucky. The skills you will pick up on the way are ordinary ones. Reading a datasheet far enough to find which pin does what. Using a multimeter before blaming your code. Noticing that a problem which appears only after twenty minutes is probably heat, memory or a battery rather than logic. None of that requires a degree, and none of it is taught in a robotics tutorial, which is part of why the first project feels harder than the second one ever will.

What does it look like when a first robot goes wrong?

It rarely fails loudly. It hesitates, drifts, and does the right thing slightly too late, which is far harder to diagnose than a crash. The arm stops a hand's width past where you told it to, but only sometimes. The robot drives into a chair leg that its sensor definitely saw, because the reading that mattered arrived after the wheels had already been told to keep going. Wheel speed wobbles whenever the camera is capturing and settles when it is not. A run that worked ten times fails the eleventh with no change to anything. Something stops responding after twenty minutes and the log ends mid-sentence. Every one of those reads as a tuning problem, so beginners tune, and tuning makes it better on the bench and no better on the floor. The giveaway is that the symptom moves when you add a print statement or plug in a laptop, since both change the timing. When a fix is that sensitive to being observed, the problem is not the numbers in your controller.

What do you give up by keeping your first robot small?

You give up other people's finished work, which is the largest single asset in robotics and the hardest to reproduce. That means mapping and localisation you did not write, path planning around obstacles, drivers for sensors you have not bought yet, a viewer that draws what the robot believes about the room, and recording tools that let you examine yesterday's failure at your desk today. You also give up shared vocabulary, which sounds abstract until you try to ask a stranger a question and have to explain your whole design before the question makes sense. And you give up a certain kind of help: nobody has filed a bug report about your private architecture, so every problem is yours alone and the answer is not on a forum. In exchange you get a machine you can hold in your head, a start-up sequence you can describe in one sentence, and the understanding that comes from having no layer between you and the hardware that you did not put there yourself.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the parts you would otherwise write yourself already exist and are hard. A robot that must build a map of a building and drive to a point on it should be a ROS 2 robot, because mapping and localisation are the life's work of people who do nothing else. An arm that must plan a path around obstacles should be a ROS 2 robot for the same reason. If the only working driver for your sensor ships as a ROS 2 package, that settles it, because reverse-engineering a device protocol is not the project you meant to start. If the robot is one of several machines coordinating over a network, ROS 2 has lived there for years and the failure modes are written down. And if this first robot is meant to lead somewhere professional, the vocabulary in job adverts is ROS 2 vocabulary, so learning the shape has value beyond the machine. HORUS is not the answer in any of those cases, because a messaging layer does not fill a cupboard with algorithms.

Is a first robot supposed to be this hard?

No, and here is why: most of the difficulty you are feeling is accidental rather than necessary. You are almost certainly solving three unfamiliar problems at once — new hardware, new software layer, and behaviour nobody has written before — and each one makes the other two undiagnosable. A stalled first robot is usually a scoping failure wearing a technical costume. The fix is unglamorous. Get one thing moving badly, with no framework, no camera and no autonomy, and keep it working while you add exactly one new thing at a time. Builders who do this reach a working machine in weeks. Builders who assemble the full design first spend those weeks unable to tell whether a wire, a library or their own logic is at fault, and that ambiguity is what actually ends projects. Difficulty is not evidence that you chose wrong, but persistent ambiguity is, and why beginner projects stall is mostly a catalogue of that same mistake.

Does buying a more expensive kit fix the software part?

Partly, but not the way you think. A good kit genuinely removes a class of problems a beginner cannot yet solve: whether the motor is sized for the robot, whether the power supply sags when both wheels start, whether the sensor is wired correctly. That is real value and worth paying for, especially first time out. What a kit does not remove is the part of the work that is specific to what you want the robot to do, and that is where the months go. The moment you add a sensor the kit did not plan for, or want behaviour the examples do not cover, you are back to writing your own program, deciding how it talks to the kit's software, and discovering the kit assumed it owned the main loop. The realistic reading is that a kit buys you a reliable starting point and a shorter first evening, not a shorter project, and whether to start with a kit is worth settling before you spend anything.

How do you decide what to build your first robot on?

Write down the parts of the robot you would be unhappy to write yourself, then count how many of them already exist in ROS 2. If that list is empty, use plain code and enjoy a machine you can explain in a sentence. If a map or a planner is on it, stop deliberating and take the ecosystem, because the alternative is measured in years rather than weekends. If the list holds exactly one item, usually a sensor driver, go looking for that driver as an ordinary library before you decide anything at all, since the whole question often dissolves. Then ask the shape questions, which matter more than any feature comparison. How many computers is this robot, honestly? How many programs must run at once? Does anything need to hold a steady rhythm while another part waits on a camera or a disk? One computer, one program and no rhythm requirement means you can defer this decision for months, and deferring it is a legitimate answer rather than a failure to choose.

Decide by situation rather than by principle:

• If your robot is one sensor, one decision and one motor -> plain code, because there is nothing for a framework to carry.
• If the whole behaviour fits on a board -> microcontroller firmware, because there is no computer to install anything on.
• If you need a map of a room or a planned path -> ROS 2, because that work is years old and freely available.
• If one machine runs a camera program and a control loop together -> a shared-memory middleware, because the boundary between them is what costs you.
• If the robot has not arrived yet -> a simulator, because waiting is worse than approximating.
• If you are learning on a bought platform -> the kit's own software, because fighting it teaches you nothing about robots.

When two of those lines describe you, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and keep whichever option loses on the fewest. No scores and no numbers: five honest questions about your situation rather than about the software. If your answers keep landing on one machine, more than one language, and behaviour nobody else has written, star HORUS on GitHub so it is in your list when you start building, and read the ranked beginner frameworks before you commit to anything permanent.