What to Do After Your First Robot Works

Run the robot you have until it fails in a boring way, then fix that, before starting a second robot or adopting a framework. The first robot works because you were holding it right; a second week of ordinary use reveals what you actually built, and that list decides whether ROS 2, HORUS or no framework is next. A deadline flips this: build the demo, pay the debt after. The rest of this post is for someone whose robot moved last weekend and who is now staring at a blank page wondering what the next month is for.

The robot worked on Sunday. It crossed the room, or the arm placed the block, and you filmed it and sent the clip to three people. On Monday you opened the laptop and did not know what to type.

Because the honest version is that it works when you are in the room. You start it by hand, in a specific order, from a terminal with the right directory already open. If the sensor is unplugged it does not complain, it just stops. There is one file, or two, and one of them has a function you no longer entirely understand. You have not tried it on a different floor.

Meanwhile the internet has moved on to humanoids. Every thread you read assumes you already have a stack, a simulator, a data pipeline and opinions about which framework to use. Half the advice says rewrite it properly now, before the mess sets. The other half says ship something bigger, because nobody cares about your architecture. You suspect both are right, you cannot do both, and the week is passing.

What should you do after your first robot works?

Run it again tomorrow without touching anything, and keep running it until it fails on its own — then fix exactly that failure and nothing else. A first robot that works is a hypothesis, not a result. It has been tested once, by the person who built it, in the conditions it was built in, with a human standing by to nudge the cable and restart the script. The second run tells you more than the first did. The tenth run tells you what you actually built. Most people skip this because it feels like standing still, and then spend two months adding features on top of something that only works when they are in the room. The failures that fall out of a boring week of re-running are the specific ones: the startup order you have memorised and never wrote down, the sensor that returns nothing rather than an error, the behaviour that depends on afternoon light, the battery that changes the machine's character as it drains.

What does it mean for a first robot to actually work?

Working means the robot did the job once, with you present, which is a much smaller claim than it feels like on the night. There is a ladder underneath the word, and knowing which rung you are standing on removes most of the confusion about what to do next. The first rung is that it worked once while you watched. The second is that it works every time you start it. The third is that it works when somebody else starts it, from a cold machine, without you explaining the order. The fourth is that it keeps working when something is wrong: a cable is loose, a sensor is dirty, the floor changed, the model is slower today. The fifth is that it recovers from that by itself. Almost every first robot is on rung one while its builder believes it is on rung three. The distance between rungs is not glamorous work, but it is the work that turns a demo into a machine, and each rung teaches a different lesson.

What are your actual options for the next month?

There are about seven honest options, and they are not equally sized. You can harden what you have until a stranger can start it. You can add exactly one capability — a second sensor, a behaviour, a way to stop it — and keep everything else untouched. You can rebuild the same robot on a foundation, which means either ROS 2, where drivers, mapping, visualisation and a large package ecosystem arrive together with the workspace conventions and the tooling, or something narrower such as HORUS, an open-source real-time middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers so processes on one machine exchange messages without serialising them. You can move the control loop into a simulator so you can break it cheaply. You can start a harder robot and accept that the first one is now a teaching object. You can hand the machine to someone who has never seen it and watch in silence. Or you can write it up, publish it, and deliberately stop, which is a real option and an underrated one.

How do the next-step options compare?

They compare on how much of your next month they consume and on what they leave behind when the month ends. The trap in this decision is that the most appealing option, starting a harder robot, is also the one that leaves the least behind if the first robot was never made repeatable. Read the final column first, because that is where the wrong choice announces itself.

What should you do next if you are building alone in the evenings?

Harden what you have, because the failure mode of solo building is not lack of ambition, it is losing the thread. Alone, the expensive thing is context: you get four hours on a Wednesday and half of it goes on remembering how to start the robot and where you left the wiring. Making the machine start with one command, log what it did, and complain loudly when a sensor is missing buys that half-hour back every session for the rest of the project. It also converts your robot from something you demonstrate into something you can leave alone for two weeks and come back to. After that, add one capability at a time and stop after each until the machine is repeatable again. The pattern that kills solo projects is a half-finished second capability layered on a half-repeatable first, at which point every debugging session has two unknowns and neither can be isolated. Many stalled projects look exactly like that, and why robotics projects stall after the prototype is the same story told from further along.

What should you do next if the robot runs on a small single-board computer?

Find out what the board is actually spending itself on before you add anything, because that is where your next surprise is coming from. On a small computer, a first robot usually works because it is doing one thing at a time. The moment you add a camera pipeline beside the control loop, the two compete, and the symptom is not an error message: the robot simply becomes hesitant, then jerky, and you blame the motor or your own code. So the useful next step on constrained hardware is to separate what must keep time from what merely has to finish, and to know which of your processes are which. That is also the point at which the way your parts talk to each other stops being free, because copying data between processes is work the board can no longer hide. A sensible order is to make the thing repeatable, then watch what happens when both parts run together, then move the part that must not hesitate into its own process before you add anything around it.

What should you do next if you have a demo in a month?

Build the demo and pay the debt afterwards, deliberately and with a written list. A month is not enough time to re-found a project, and a half-migrated robot demos worse than a scruffy one that works. So freeze the architecture, spend the first week making the existing machine start dependably and fail visibly, and spend the rest on the specific thing the audience will look at. Two habits save demos: a rehearsed way to restart everything quickly, and a fallback behaviour for the moment a sensor gives you nothing, because in a strange room with strange lighting it eventually will. Write down every ugly thing you do to get through the month, as you do it, in one file, with the reason attached. That file is the actual plan for the month afterwards, and it is far more accurate than any plan you would write today. Demos that go well and then rot do so because the list existed only in someone's head and was gone by the following week.

What should you do next if you have never used a robotics framework?

Try one on a copy of the robot you already have, rather than on a new project, because you already know what correct behaviour looks like. This is the most useful learning exercise available to you right now. You have a working machine, so you have a reference: when the framework version misbehaves, you know the problem is the framework or your use of it, not the underlying idea. Give it a bounded stretch, a couple of weekends, and rebuild only the parts that move data around, keeping your existing logic intact underneath. What you learn is not the tutorial material. It is whether the framework's assumptions match the robot in front of you: whether the tooling helps or gets in the way, whether the concepts fit or you keep translating, whether the setup cost feels like an investment or a tax. If the copy is worse than the original after two weekends, that is information rather than failure, and you kept the original the whole time.

What usually breaks first when a working robot runs for a second week?

Startup order breaks first, and then data stops arriving without anyone saying so. Almost every first robot has an undocumented ritual — start this, wait, then that, make sure the window is in the right directory — and the ritual lives in the builder's hands rather than in a file. It breaks the first time you are tired or somebody else tries. Second is silent absence: a sensor that returns nothing instead of an error, a process that exited while the rest carried on, a stream nobody is publishing to any more. The robot does not crash. It behaves as though the world were empty, which is often worse than crashing. Third is the environment: the light changed, the floor is different, the battery is lower, the room is warmer. Fourth, on anything with a computer of its own, is the day two things want the machine at once. None of these are exotic, and what nobody tells you about a first real robot covers the same ground from the other side.

What do you give up by moving onto a framework now?

You give up speed and the shape of the thing you understand, and for a few weeks you will be slower at everything you could already do. That cost is real and people under-report it. A framework replaces code you wrote with conventions you have to learn, and during the transition your robot is worse: it does less, it breaks in unfamiliar ways, and the error messages point into a codebase you did not write. In exchange you get tooling that shows you what the machine believes, a recording format, a way to run parts on different computers, and other people's drivers. That trade is excellent later and poor early. The specific mistake is adopting a framework to solve a problem you have not had yet — you are not fighting your architecture, you are fighting a loose connector — and then blaming the resulting slowdown on your own inexperience. If you cannot name the problem the framework solves for you in one sentence, the month is better spent elsewhere.

When is ROS 2 the better choice?

ROS 2 is the better choice for a next robot whenever the thing you want has already been written, which is most of the time. If the second machine must build a map and navigate to a goal, that is a ROS 2 project, and reproducing that work yourself would cost years for no gain. If you need an arm to plan around obstacles, the answer is the same. If the sensor you just bought has one usable driver and it is a ROS 2 package, the decision has been made for you. If your project will span a robot and a workstation, or several robots, ROS 2 was designed for exactly that. And if you want to work in the field, learning ROS 2 is a career asset independent of any technical merit. HORUS is not the answer for those readers, and picking it there means rebuilding plumbing that already exists in order to lose the packages that were the point. The narrow case is one machine, several languages, and a loop that must not hesitate.

Should you rewrite it properly before doing anything else?

No, and here is why: the rewrite you would do today rests on a guess about what the robot needs to become, and you do not have that information yet. Rewrites feel responsible. They are usually a way of doing familiar work while avoiding the unfamiliar work of making an unpredictable machine dependable. The tidiest possible reimplementation of a robot that still needs you standing beside it is a robot that still needs you standing beside it. There is also a specific trap: your first robot's mess is not evenly bad. Some of it is genuinely tangled and some of it is merely unfamiliar because you wrote it quickly at midnight. Fix the parts that made the robot fail this week, in place, and leave the rest ugly. Rewrite when the code stops you doing something you have actually tried to do, such as adding a second sensor taking three days, or nobody else being able to follow the flow. Until then, rewriting is expensive procrastination in a respectable costume.

Was the code in your first robot wasted work?

Partly, but not the way you think. The code itself probably will not survive, and that is fine, because most first-robot code is replaced within a year whether or not anyone plans it. What survives is the map in your head: which sensor lies and when, what your motors do once they are warm, how long the machine takes to notice something, why that one function has a strange sleep in it. That knowledge transfers to every robot you build afterwards and cannot be read from a book. The genuinely wasted work is different and worth naming: time spent on a framework you did not need, hardware bought for a robot you did not build, and weeks of tutorial-following that produced no machine. None of that is what you did. The other thing that survives is the habit of finishing, which is rarer than skill. Most people who start robots never get one working, and you have already crossed the line that most projects never reach.

How do you decide what your next month is for?

Write down the last three things that went wrong and let that list choose, because the list is more honest than your ambition. If all three were physical — a cable, a connector, a sensor covered in dust — your next month is hardening and probably a soldering iron rather than software. If all three were behavioural, where the robot did the wrong thing confidently, your next month is about what the machine believes and where that belief comes from. If all three were structural, where the fix was obvious but touching one part broke another, that is the signal for a foundation. And if nothing has gone wrong because you have only run it twice, run it more before deciding anything. Then set a smaller goal than you want to. The most common failure after a first success is choosing a second project three times too large, running out of momentum in week five, and concluding you are not cut out for this. Choosing what to be good at can wait: which subfield to specialise in is a better question once a second machine exists.

Decide by situation rather than by appetite:

• If the robot only works with you in the room -> harden it, because everything else you might build sits on top of that.
• If a stranger can already start it -> add exactly one capability, because the base will hold while you do.
• If you need mapping, navigation or a particular driver -> ROS 2, because that work already exists and is already integrated.
• If your robot is one computer with Python and C++ parts fighting over the same data -> a foundation built for that case, because the boundary is where your evenings go.
• If you have a demo in a month -> build the demo, keep the ugly list, and pay it back afterwards.
• If the project taught you what you came for -> write it up and start the next thing on purpose.

When the foundation question does arrive, 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 the one that loses on the fewest, with no scores and no numbers involved. If your second robot is heading towards one machine, several languages and a control loop that must not hesitate, star HORUS on GitHub so it is in your list when you start building.