Should You Learn ROS 1 or ROS 2 First in 2026?

Learn ROS 2 first, and do not spend a single evening on ROS 1 unless a job or a lab explicitly requires ROS 1. ROS 1 stopped getting fixes in 2025, so the packages around ROS 1 age out while the drivers, simulators and tutorials written now assume ROS 2. The verdict flips only if you inherit a working ROS 1 robot that someone still pays you to keep alive. The rest of this post is for beginners choosing a first stack, including those already wondering whether ROS 2 or a newer option like HORUS fits the robot they want.

You have a board on a shelf, maybe a small rover kit, and a browser with fourteen tabs open. One tab says install Noetic. Another says Noetic reached end of life. A video series you liked uses catkin and roslaunch, and the comments underneath are arguing about whether any of it still applies. The university course you found is four years old. Someone on a forum insists that learning the old one first makes the new one easier, and someone else replies that this is exactly how you waste a semester.

You do not want a survey of the field. You want to know which command to type tonight so that the thing you build in three weeks is not born dead. And you have noticed that half your questions are not really about versions at all. Why does a robot need a framework instead of one program. What actually happens when the wheels keep spinning after you let go of the key. Whether the thing you learn this month is still the thing you use when the robot gets harder, or whether you are about to learn something twice.

Should you learn ROS 1 or ROS 2 first if you are starting from scratch?

ROS 2, and it is not a close call in 2026. ROS 1 reached its final end of life in 2025, which means no more patches, no more official builds, and a shrinking pool of people willing to answer questions about it. Every driver, simulator plug-in and tutorial being written today targets ROS 2, so the ROS 1 material you find is frozen at the moment its author stopped caring. Starting on a dead version costs you twice: once when you learn the old commands, and again when you discover that the concepts map across but the names, the build tool and the launch files do not. The one honest exception is a robot that already exists and already runs ROS 1, where someone needs the machine working next month. That is maintenance, not learning, and you can pick up what the job needs in a week once you understand the newer system. If you have a choice at all, spend your first hundred hours where the ecosystem is still moving.

What does robotics middleware actually do?

Robotics middleware is the postal service between the separate programs running on your robot. One program reads the camera, another decides where to drive, another talks to the motor controller, and a fourth records everything for later. Middleware lets those programs find each other, agree on the shape of the messages they exchange, and start and stop together without each one hard-coding the address of every other. It also carries the boring machinery you would otherwise write yourself: a clock everyone agrees on, a way to describe where each sensor sits on the chassis, tools to replay yesterday's drive, and somewhere to put configuration so you are not editing constants in source files. Without middleware you end up inventing a private version of all of it, badly, around the third week of a project. That is the real reason people reach for a framework. Not because a robot cannot be programmed in one file, but because the second and third program are where the mess starts.

What are your real options for a first robotics stack?

There are four families worth knowing, and only one of them is the default for a beginner. ROS 2 is the mainstream choice: a large package ecosystem, a simulator that most tutorials assume, and a decade of accumulated answers to your exact error message. ROS 1 is the same idea from the previous generation, now unmaintained. micro-ROS covers the case where your code runs on a microcontroller with no Linux underneath it. Then there are the focused real-time middlewares, of which HORUS is one, an open-source Apache-2.0 project where Rust, Python and C++ nodes share the same shared-memory ring buffers, so a message handed between two processes on one machine is not serialised on the way, which starts to matter when your control loop is tight enough that copying hurts. Underneath all of these sits the option of no middleware at all: one program, one loop, no message passing. That is a fine answer for a line follower and a poor one for anything with a camera in it.

How do the main options compare side by side?

The table below is the whole decision in one place. Read the last two columns first: the quickest way to choose is to eliminate the options whose failure mode you cannot live with.

No row here is a trap. The trap is picking a row for the robot you imagine owning in two years instead of the one sitting on your desk this month.

Which should you learn if you are a student with no robot of your own?

ROS 2 in simulation, starting today, and buy nothing yet. A simulated robot never runs out of battery, never snaps a bracket and never blames a loose wire for your bug, which is what you want while the concepts are new. Install the current long-term release on the Ubuntu version it expects, run the turtle example, then a simulated mobile base, then write a node that steers it away from a wall. That sequence teaches the parts that transfer: topics, transforms, launch files, and the habit of checking whether a message is arriving before you rewrite your algorithm. Do not start by buying a kit. Hardware adds a whole second category of failure, all power and wiring and drivers, on top of a stack you cannot yet debug, and beginners who mix the two usually conclude the framework is broken when the real problem is a connector. Once a simulated robot does what you wanted, moving the same code onto real wheels is a satisfying afternoon rather than a lost month.

Which should you learn if your only hardware is a hobby board and two motors?

Still ROS 2, but on the single-board Linux computer, not on the microcontroller. A credit-card Linux board runs ROS 2 comfortably for a small rover, as long as you are not also asking it to do heavy vision at the same time. The pattern that works: the microcontroller does the fast, dumb job of driving motors and reading encoders, and the Linux board does the thinking and talks to it over a serial link. If your only computer is the microcontroller, ROS 2 proper is the wrong tool, because a graph of separate programs needs an operating system underneath it, which is worth understanding before you install anything and is covered in what the OS in the name actually means. Keep the first robot small. Two wheels, one distance sensor, and one camera you deliberately ignore for a fortnight. Every extra device is another driver, and drivers are where beginner projects quietly die.

Which should you learn if you need a demo working in six weeks?

Learn ROS 2, and scope the demo to what already exists in packages. Six weeks is plenty of time to stand on other people's work and nowhere near enough to write your own navigation stack, so the winning move is to take a published robot description, a navigation package somebody else maintains, and spend your weeks on the single behaviour that makes the demo yours. The failure pattern is the mirror image: three weeks building a perfect workspace, one week fighting a build error at midnight, and a demo where a robot drives in a straight line. Write down the one sentence describing what the audience must see, then delete every task that does not serve that sentence. If the deadline is shorter than a fortnight and somebody near you already runs a working stack, use theirs, whatever it is. A framework you can ask a human about beats a better framework you have to debug alone at two in the morning.

Which should you learn if you have never written C++?

ROS 2 with Python, and you will be fine for a long time. The Python side is complete enough for real nodes, and most of what you need early on, such as how messages flow, why a transform is wrong, and how to launch six things at once, has nothing to do with the language. You will meet C++ eventually, because much of the ecosystem's internals are written in it and because a control loop that must not stutter is rarely the place for a language that pauses to collect garbage. That crossover is also where people start reading about shared-memory stacks, where the planning side stays in Python and the motor side moves to something tighter, an idea shown plainly in eight lines of Python next to the ROS 2 version. For now, write Python, learn the concepts, and change languages when a real problem asks you to rather than because a forum told you serious roboticists use C++.

What does it look like when you pick the wrong starting point?

It looks like a project that stalls on plumbing instead of robotics. The ROS 1 version: you follow a tutorial, the install fails on a modern Ubuntu, you find a workaround, the workaround breaks a dependency, and three evenings later you have learned nothing about robots. The no-middleware version: everything works until you add a second sensor, and then one loop is doing three jobs at different rates, the camera read blocks the motor update, and the robot lurches every time a frame arrives. The over-engineered version: you build a beautiful multi-machine setup for a rover that never leaves your desk, and you spend your evenings on configuration files rather than on behaviour. All three share a tell. You can describe your build system in detail and you cannot describe what your robot does. When you notice that, stop, and cut the scope back to one machine, two programs, and a single behaviour that either works or does not.

What do you give up by committing to ROS 2 in 2026?

You give up simplicity, and you should walk in knowing it. ROS 2 is a large system with its own vocabulary, its own build tool, its own launch language and firm opinions about how a workspace is laid out, and none of that is obvious on day one. You will hit the evening where a node is clearly publishing and clearly nobody is receiving, and the answer turns out to be a mismatched delivery setting rather than anything to do with your robot. You also inherit a communication layer that packs and copies messages between processes, which is invisible while the robot is gentle and becomes the thing you fight when the loop gets tight, showing up as the arm that overshoots because the sensor reading landed after the decision was made. And you accept a heavier footprint than one program needs: more processes, more start-up, more moving parts to explain to whoever inherits your project. Those costs buy an ecosystem, and for most people the trade is worth making.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every beginner and most teams, and pretending otherwise would not help you. If you want navigation that already works, a mapping package you did not write, a simulator containing models of real robots, drivers for the sensor you just bought, and a forum where your error message has already been asked and answered, that is ROS 2 and nothing else is close. It is also the better choice when your team turns over every year, because the person replacing you has probably used it. HORUS is not the answer for that reader: it is a middleware for moving messages between processes on one machine without serialising them, not a package catalogue, not a simulator, and not a full replacement for everything ROS 2 does. If the reason you are reading this is that you want to build a robot rather than build robot infrastructure, install ROS 2, work through the tutorials, and come back to this question when a real deadline in a real loop forces it.

Is ROS 1 worth learning first because so many tutorials still use it?

No, and here is why: those tutorials teach concepts you can learn just as well in the current version, wrapped in commands that no longer exist. Topics, services, transforms and the general shape of a robot graph carry across almost unchanged, so you lose nothing conceptually by skipping the older one. What does not carry across is everything you actually type. The build tool changed, the launch files changed, the parameter system changed, and the packaging changed. Learn the old commands and you will spend months half-remembering the wrong one at the wrong moment. There is a subtler cost too. Old tutorials encode old assumptions about what is normal, such as one machine, one language, and a network stack that is always available, and those assumptions quietly shape how you design your own robot. If you find a genuinely excellent old tutorial, read it for the ideas and implement it in the current version. That translation is itself one of the better ways to learn.

Does learning ROS 2 first mean your timing problems are solved?

Partly, but not the way you think. ROS 2 gives you real tools for timing. You can mark a subscription with a deadline, choose delivery settings per topic, and pin work to particular threads, and for a rover driving around a room that is enough that timing never becomes a topic of conversation. What those tools do not do is remove the work underneath. Every message between two processes is still packed, copied and unpacked, and the operating system still decides who runs next. So the failure never shows up as a crash. It shows up as an arm that overshoots the mark once every few minutes, or a robot that hesitates at the exact moment the camera pipeline gets busy, and you cannot reproduce it on demand. That class of problem is why people go looking at shared-memory middleware, and it is the same problem behind fusing an IMU with odometry when the loop gets tight. It is a later problem. Just do not be surprised by it.

How do you decide what to install this week?

Answer three questions and the choice makes itself. First: is there an existing robot you are being asked to keep running? If so, match whatever that robot runs, treat it as maintenance, and do your actual learning elsewhere. Second: does your code run on a computer with Linux on it, or on a bare microcontroller? Linux means ROS 2 proper, while bare metal means micro-ROS or plain firmware talking to a Linux board that runs the rest of the robot. Third: will anything on your machine hurt a person or break itself if a message arrives late? For a desk rover the answer is no, and you should stop thinking about middleware internals entirely. For an arm working near someone, or any machine with real momentum behind it, the answer is yes, and that is where copying between processes stops being an implementation detail. None of this is permanent. The concepts travel with you, and the second framework you learn is far less work than the first one was.

The short version, by situation:

• If you are starting with no robot and no deadline -> ROS 2 in simulation, because everything written this decade lands there.
• If you are keeping an existing ROS 1 machine alive -> stay on ROS 1 for that machine, because a rewrite you cannot finish helps nobody.
• If your code runs on a microcontroller with no Linux -> micro-ROS or plain firmware, because a graph of programs needs an operating system under it.
• If a late message would let a machine hit something -> a shared-memory middleware beside ROS 2, because copying between processes is the part that bites.
• If you have a demo in a fortnight -> whatever the people around you already run, because a colleague answers faster than a search engine.

When you compare any two stacks, the HORUS Fit Framework keeps the argument honest by asking five questions with no numbers in them: ecosystem size, setup effort, team size fit, deployment target, and licence. ROS 2 wins the first outright, and for a beginner that single axis usually decides the whole thing. The last three are where the answer starts to change as the robot gets more demanding and the loop gets less forgiving.

If deployment target and licence are where you expect to end up, put HORUS on the shelf next to your ROS 2 tutorials and star it so it is in your list when you start building.