Can You Build a Robot Without ROS at All?

Yes, you can build a robot with no ROS at all: plain code, firmware, a vendor SDK or a middleware such as HORUS all work. What decides it is not skill but how much of the robot you intend to write yourself, because ROS is mostly other people's finished code rather than a way to make code run. The answer flips the day you need a map of a room. The rest of this post is for a first or second robot builder who wants to leave ROS out on purpose and know exactly what that costs.

The robot in your head is simple. A sensor sees something, some code decides, a motor moves. The robot in your terminal is a package, a workspace, a build step, a launch file, and an argument with the network about whether two programs on the same computer can see each other. Nothing about that argument is about robots.

You have probably also noticed the tone of the advice. Ask whether you need all of it and someone tells you that you will regret skipping it, without saying what you will regret. Ask what a specific piece does and the answer arrives containing four more words you now have to go and look up. Meanwhile the behaviour you actually care about — drive forward, stop the wheel before it touches the wall, back up, try again — is a page of code you could write tonight.

So the question turns practical rather than philosophical. What happens if you simply do not install any of it? Not as a protest, and not because you think you know better than a decade of robotics work, but because you want to see the bill before you sign: what would you be committing to write yourself, and is it the kind of thing you can carry?

Can you build a robot without ROS at all?

Yes, and plenty of shipping robots do. ROS is not a requirement for a machine to sense, decide and move; it is a large collection of already-written parts plus an agreed way for programs to exchange messages. Vacuum robots, drones, industrial arms and most factory automation run on stacks with no ROS anywhere in them, built by people who wanted to own every layer. The real question is not permission, it is arithmetic. What proportion of your robot would be code somebody else already wrote, and are you willing to write that proportion yourself? A robot that drives forward, watches a distance sensor and stops before it touches the wall is a page of code that needs nothing underneath it. A robot that builds a map of a building and finds a path across it is an entire research field, and you will either borrow that work or spend years reproducing it badly. Every project that ever asked this question sits somewhere between those two, which is why the answer is yes with a bill attached.

What does ROS actually provide beyond message passing?

ROS provides five things and only one of them is message passing. First, drivers: working code for cameras, laser scanners, depth sensors, motor controllers and inertial units, written by people who already met that hardware's quirks so you do not have to. Second, algorithms you would not sensibly write yourself: mapping, localisation, path planning, arm motion planning. Third, bookkeeping that sounds dull and is not — a standard way to say where each part of the robot sits relative to every other part, and a standard way to say when a measurement was taken, so a sensor reading and a wheel position can be lined up honestly. Fourth, tooling: a viewer that draws what the robot believes about the room, plus recording and replay so that yesterday's failure can be examined at your desk today. Fifth, the message passing itself. When somebody leaves ROS out, they plan for the fifth, budget a little for the first, and get ambushed by the third.

What do people build on instead of ROS?

Seven routes come up in practice and they are not equivalents. The commonest is a single program with no middleware at all: one loop, ordinary function calls, threads you own. Second is microcontroller firmware, where the robot's whole behaviour lives on the board and there is nothing to install. Third is the SDK that arrived with a bought arm or wheeled base. Fourth is a small middleware such as HORUS, an open-source real-time middleware for Rust, Python and C++ in which 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 is validated in simulation, and it deliberately does not try to be everything ROS 2 is. Fifth is a network transport such as Zenoh, for robots and workstations spread across machines and links that drop. Sixth is a general message broker of the kind web teams already run, which suits telemetry and remote commands. Seventh is speaking DDS directly, which is the layer ROS 2 itself stands on.

How do the options without ROS compare?

Two columns matter more than the rest, and the first is not one of them. Start with what each row assumes you know, because a route you cannot debug at eleven at night is not really available to you whatever its merits. Then read the last column and cross out every row that describes your situation today. What usually survives is a pair rather than a winner: something small to start on and something to grow into, which is a healthier outcome than a single answer. Notice too that the rows are not exclusive. Firmware on a board talking to a program on a small Linux computer is one of the most common shapes a robot without ROS takes, and a vendor SDK normally sits underneath whichever route you pick.

Can one person maintain a robot that has no ROS underneath it?

Yes for one robot, and the difficulty that arrives later has nothing to do with cleverness. A single builder can own the transport, the driver code and the start-up sequence for one machine, and many do exactly that for years with less trouble than the internet predicts. What changes is not the difficulty of any one task but the fact that every problem becomes yours alone. When the camera stops delivering pictures after an hour, nobody else has filed a bug report about it and the answer will not be on a forum. When a new sensor turns up with a datasheet and no library, that is your weekend. The real cost is the long tail rather than the first version: an operating system update that renames a device, a board revision that moves a pin, a library that quietly stops being maintained. One person can hold that for one robot. Two robots and a second contributor is where builders discover they have written a small framework by accident and now have to document it for somebody else.

Does skipping ROS work on the hardware most beginners own?

Yes, and on the smallest hardware it is the only thing that works. A microcontroller cannot run ROS in the ordinary sense, so a robot built on one is already a robot without ROS and nobody considers that controversial. A small Linux computer is where the question actually lives, and there the answer is still yes with a caveat about shape. Without a framework you own what happens at power-on: the order programs start in, what happens when one of them dies, and how a program knows the others are ready all become your code rather than a launch file. The caveat that surprises people is the camera. As soon as pictures are involved, one program stops being enough, because handling a frame takes long enough that a control loop sharing that program starts to hesitate where you can see it. That hesitation is the moment the no-middleware route stops being free, and it shows up on the same modest hardware everybody starts with.

Can you skip ROS if you have to demo in a month?

Yes, and for a month-long deadline skipping it is usually the right call. Writing a loop that reads a sensor and drives a motor is an evening's work. Learning a package layout, a build tool, a launch system and a message-definition language while simultaneously debugging your own control logic for the first time is a month on its own, and at the end of that month you still have to build the robot. The exception is sharp and you will know whether it applies: if the demo needs a map, a path planned around obstacles, or a sensor whose only working driver ships as a ROS 2 package, then leaving ROS out means writing or porting that piece yourself, and that does not fit in a month. Check it before you commit rather than after. The specific trap is the sensor driver — builders assume a driver will be easy to replace, find the device speaks an undocumented protocol, and lose the deadline to a protocol instead of to a robot.

Do you need to be an experienced programmer to skip ROS?

No for the first robot, and yes for the version that runs while nobody is watching. Reading a sensor and driving a motor without a framework is genuinely beginner work, and it teaches more per hour than most tutorials because nothing between you and the hardware is hidden from you. The requirement climbs when the machine has to keep working unattended. Deciding what happens when a reading never arrives, what the motors do if the decision-making program stops, and how a crashed part restarts without leaving the robot in a strange state is systems work, and it is the same work whether or not a framework is present. A framework does not do it for you; it gives you conventional places to put it and sensible defaults while you learn. So the honest answer is that skipping ROS is easy for the demo and demanding for the deployment, and those two moments are months apart, which is why the route feels effortless right until it does not.

What breaks first on a robot built without ROS?

Time and coordinates break first, in that order, and both disguise themselves as something else. Time breaks when a sensor reading and a wheel position get combined without anyone agreeing about when either was measured, so the robot acts on where it was a moment ago and drives into things it thought it had cleared. That looks like a tuning problem for weeks. Coordinates break the day a second sensor is added: the camera sits slightly forward and a little higher than the sensor everything was calibrated against, and an obstacle now appears in a place that no individual piece of code is wrong about. ROS supplies a standard answer to both, which is exactly why leaving it out feels free for the first month. After those come start-up order, where nothing connects unless programs are launched in a particular sequence, and missing recordings, where a failure that happened once cannot be reproduced because nobody kept the data. What middleware actually does is mostly this list.

What do you give up by leaving ROS out entirely?

You give up other people's finished work, which is the single largest asset in robotics. That means mapping and localisation you did not write, drivers for sensors you have not bought yet, motion planning for arms, a viewer showing what the robot believes about the room, recording and replay for debugging last week's failure, and a decade of forum answers written by people who hit your problem before you did. You also give up help and hiring: somebody who knows ROS can read a ROS robot on their first day and cannot read your private architecture at all, so every new contributor starts with a tour only you can give. And you give up shared vocabulary, which matters more than it sounds the moment you need to ask a stranger a question and have to explain your entire design before the question makes sense. In exchange you get a machine you can hold in your head, a start-up sequence you can describe in one sentence, and no build system you did not choose.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the parts you would otherwise have to write 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 navigation are years of work by 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 your sensor's only usable driver ships as a ROS 2 package, that settles the matter, since reverse-engineering a device protocol is not the project you meant to start. If the robot is one of several machines that must coordinate over a network, ROS 2 has lived in that world for years and the failure modes are documented, including what goes wrong on ordinary Wi-Fi. And if you want a robotics job, the vocabulary in the adverts is ROS 2 vocabulary. HORUS is not the answer in any of those cases, because a messaging layer does not fill a parts cupboard.

Will skipping ROS hurt your chances of working in robotics?

No, and here is why: what gets people hired is a robot that works and a clear account of why it works. Nobody senior is impressed by the ability to install a framework. They are interested in whether you understood the timing problem, what you did when a sensor lied to you, and how you decided the machine was safe to leave running. A builder who wrote their own transport and can explain the trade-offs inside it usually interviews better than one who copied a tutorial stack and never asked what the pieces do. That said, the vocabulary is worth owning. Job adverts name ROS 2 because teams need somebody useful on an existing codebase in week one, so learn the words and the shape even if your own robot never uses either. The strongest position is having built something without ROS and being able to say precisely which of its problems ROS 2 would have solved, which is a better answer than either half on its own.

Is building without ROS just rewriting ROS badly?

Partly, but not the way you think. You will rewrite a small piece of ROS — the part that moves messages between programs and the part that starts them — and that piece is genuinely smaller than it looks when it only has to serve one robot that one person understands. What you will not rewrite is the enormous half: mapping, planning, drivers, the viewer, the recording tools. Nobody reproduces those by accident; they either borrow them or go without. The failure people are gesturing at is real but more specific than reinventing the wheel. It is the slow accretion where a script grows a queue, then a background thread, then a rule about stale data, then a start-up script, then a configuration file, until the robot carries a private framework nobody documented and only one person can debug. That outcome is avoidable, but only on purpose: either keep the plumbing deliberately small and write down its rules, or adopt something that already made those decisions for you.

How do you decide whether to skip ROS?

List the parts of your robot you would be unhappy to write yourself, then count how many of them ROS already contains. If the list is empty — a sensor, a decision, a motor, and behaviour that exists only in your head — skip ROS and enjoy a machine you can explain in a sentence. If a map or a planner is on the list, use ROS 2 and stop deliberating, because the alternative is measured in years. If the list holds exactly one item, usually a sensor driver, go looking for that driver outside ROS before you decide anything; often it exists as an ordinary library and the whole question dissolves. Then ask the shape questions. How many computers is this robot? How many languages will it speak? Does anything have to hold a steady rhythm while another part waits on a camera or a disk? One computer, one language and no rhythm requirement means you can defer this decision for a long time, and the ranked list of beginner frameworks is the next thing to read.

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 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 code is years of work you cannot get anywhere else.
• If one machine runs Python, C++ and Rust parts that must share data -> a shared-memory middleware, because the language boundary is what costs you.
• If the robot is several machines on a patchy network -> a network transport, because that is a different problem from this one.
• If a bought arm or base already does most of the job -> the vendor SDK, because anything else would only wrap it.

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 the option that loses on the fewest. No score 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 whether you need ROS 2 at all before you decide anything permanent.