Should Students Learn ROS 2 or Modern Alternatives?

Learn ROS 2 first, and add a modern alternative later — ROS 2 is still what labs, job adverts and borrowed robot code assume you know. The vocabulary transfers even when the tools change, and a student who has fought ROS 2 once can read almost any robot codebase afterwards. That flips if you have one term and a machine that must move, where a smaller foundation like HORUS finishes the project. The rest of this post is for a student choosing what to spend a term on, worried the choice will date before graduation.

You have read the same forum thread four times. One reply says that every robotics job advert names the same framework and that skipping it is career suicide. The next reply says that framework is bloated, that nobody at a serious company writes new code against it, and that the smart move is to learn something lighter and be ahead of the curve. Both replies have upvotes. Neither person is a student.

Meanwhile the course you are actually enrolled on has a lab exercise due, and the lab machine has an install from two years ago that half the class cannot get running. You lost a weekend to a build error and learned nothing about robots. Your friend on the same course gave up and wrote the whole assignment as one Python file, and it works, and you cannot tell whether that friend is cheating themselves or being sensible.

Underneath is a fear that is really about time, not technology. You get one degree. If you spend it learning the wrong foundation, you graduate fluent in something the industry has quietly moved past, and everyone who chose differently starts ahead of you.

Should students learn ROS 2 or a modern alternative?

Learn ROS 2 first, and treat the modern alternatives as a second step taken when a specific project asks for one. The reason is not that ROS 2 is technically superior to everything newer. The reason is that ROS 2 is the shared language of the field: the lab you want to join speaks it, the sensor you borrow ships a driver for it, the paper you want to reproduce released its code against it, and the interviewer has it on their screening list. A student who cannot read a ROS 2 repository is locked out of most of the free work other people have already done. Learning it also teaches a set of ideas that outlive it — nodes, topics, message types, transforms between coordinate frames, recorded logs you can replay — and those ideas appear in every alternative under different names. The honest cost is that ROS 2 is unpleasant in the first fortnight, and a meaningful number of students quit there. That is a tooling problem, not a talent problem, and it is survivable if you know it is coming.

What is robotics middleware, and why does a student have to care?

Middleware is the postal service between the separate programs running on a robot. A robot is not one program. It is a camera program, a program deciding where to drive, a program talking to the motors, and a handful of others, all running at once and all needing each other's data. Middleware is what carries a message from the camera program to the decision program without either one knowing where the other lives or what language it was written in. Students meet this concept late, usually after writing one enormous script that does everything, watching it become impossible to change, and slowly reinventing a worse version of message passing. That is why the topic matters to a learner rather than only to a professional: the moment your project has two things happening at once, you either adopt a middleware or write one accidentally. If the whole idea is still fuzzy, a plain-English guide to what middleware actually is is worth twenty minutes before you pick anything.

What are the actual options a student can pick from?

There are about six real options, and two of them are not frameworks at all. You can learn ROS 2, which buys you the ecosystem and the hiring signal. You can write plain Python with no framework, which is genuinely correct for a small robot and teaches you why frameworks exist. You can use whatever SDK came with your kit, which is the fastest route to a machine that moves. You can learn a simulator deeply and postpone hardware. You can work through the machine-learning robotics toolkits if your interest is models rather than mechanisms. And you can pick a lighter middleware: HORUS is 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, while ROS 2 assumes a network in the middle and gives you the enormous package library that comes with that assumption. Read the table as descriptions of students, not as a ranking.

What should you learn if you are on a university robotics course?

Learn ROS 2, because your marks, your lab partners and your supervisor already depend on it. This is the least ambiguous situation in the whole post. A university course gives you the three things that make ROS 2 bearable and that self-taught learners lack completely: a machine with it already installed, a demonstrator who has seen your exact error before, and peers hitting the same wall in the same week. Those supports collapse the painful part from months to days, and you will never have that combination again for free. There is a second, less obvious reason. Undergraduate projects are usually judged on how much the robot does, and doing a lot in one term almost always means borrowing mapping, navigation or planning code rather than writing it. That borrowing is the ecosystem, and the ecosystem is ROS 2. The exception worth naming: if your course is a general computer science degree and robotics is a single module or a club, you are effectively a self-taught learner and should read the next few sections instead. Choosing a stack for a final-year build has its own answer in picking a stack for a university capstone.

What should you learn if all you own is a laptop and a small board?

Start with plain Python on the board, and add ROS 2 on the laptop once something already moves. A single-board computer with a couple of motors and one sensor does not need a distributed message system, and installing one before anything spins is how students end up with a fully configured workspace and a robot that has never left the desk. Write the smallest program that reads the sensor, decides one thing, and drives the motor. That takes an evening and teaches you more about robots than a week of tooling. Then, deliberately, split it: move the sensor reading into its own program and make the two talk. The moment that split becomes annoying is the moment middleware means something to you, and you will learn it in an afternoon because you now know what it is for. There is one hardware caveat. Some small boards struggle to run a full ROS 2 install comfortably alongside your own code, so if your only computer is a very modest board, plan to run the heavy tooling on your laptop and keep the board's job simple.

What should you learn if the project is graded at the end of one term?

Learn whatever gets a machine moving in the first three weeks, and that is usually not a new framework. A graded deadline changes the question entirely, because you are no longer optimising for what you know in five years. You are optimising for a demonstration that happens on a fixed date, and demonstrations are won by robots that do one thing convincingly. The failure pattern is predictable and common: a team spends the first half of the term on installation, environment setup and a networking problem, then discovers in the second half that the actual robot behaviour has not been started. If your team already knows ROS 2, use it, because familiarity beats everything under time pressure. If nobody does, be honest about that and choose the smallest foundation that carries your project. You can learn the ecosystem next term, when nobody is marking you. A useful sanity check before committing: read how long it really takes to learn ROS 2 and compare that honestly against the weeks you actually have.

What should you learn if you have never used Linux or the terminal?

Learn Linux and the terminal first, on their own, before any robotics framework touches your machine. This sounds like a detour and it is the opposite of one. Almost every horror story about a beginner's first week is not about robotics at all: it is a path variable, a permission error, a package manager conflict, or a file that exists but cannot be found. A learner who does not yet know what a shell is cannot tell the difference between "my robot code is wrong" and "my computer is not set up", and that inability turns every problem into a coin flip. Spend a week with a Linux install doing ordinary things — moving files, editing text, installing software, reading what an error is actually telling you — until the terminal feels boring. Then start on robotics, where you will meet errors that are genuinely about robots. Students who take this detour report that the notoriously brutal first fortnight becomes merely tedious, which is a large improvement.

What does it look like when a student picks the wrong starting point?

It looks like weeks of activity with nothing that moves at the end of them. The specific symptoms are recognisable. Your commit history is full of configuration files and empty of behaviour. You can describe your build setup in detail and cannot describe what your robot does. Every session starts by fixing the thing that worked last time. You have a folder of half-finished tutorials and a robot chassis still in its box. The mirror-image failure is just as real and less discussed: a student who avoided all tooling now has one gigantic script that works beautifully, cannot be split into parts, cannot borrow anyone else's code, and cannot be explained to a teammate. Both failures come from the same root, which is choosing a foundation before knowing what the project needs. The reliable tell is to ask what you learned this week. If the answer is a fact about a build system rather than a fact about your robot, you have drifted, and drifting for a term is how a degree turns into tooling experience.

What changes as a student project gets more demanding?

The problems stop being about code being wrong and start being about code being late. Early on, every bug is a logic bug: the wheel turns the wrong way, the reading is in the wrong units, the loop never exits. You fix those by reading. Then the project grows a camera, a planner and a controller all running at once, and a new category appears. The robot works, and then occasionally does not, and nothing in your code changed. The arm overshoots the cup once in ten tries. The rover holds a straight line and briefly veers when the vision program is busy. Adding a print statement changes the behaviour, which should feel alarming. This is the point where the middleware question becomes real rather than academic, because what you are watching is a message arriving after the moment it was needed, and a correction that arrives late is not a smaller correction — it is the wrong one. Most students meet this in their final year, and it is the single most valuable thing an undergraduate project can teach you.

What do you give up by learning a modern alternative first?

You give up the borrowed work, and for a student that is the expensive part. Choosing a lighter foundation means that when your project needs a map of a building, a path around an obstacle, or a driver for the specific depth camera the lab lent you, there may be no package waiting and you write it yourself. Writing a navigation stack is a career, not a term project. You also give up the shared vocabulary: when you ask for help, the person answering will assume the common framework, and your question needs translating before anyone can engage with it. And you give up a slice of the screening process, because a keyword filter does not read your reasoning. The counterweight is honest. A lighter foundation means fewer moving parts, fewer failures that belong to the tooling rather than to you, and a much better chance that something exists at the end of the term. Whether that trade is worth it depends entirely on whether your project needs the borrowed work or only the plumbing.

When is ROS 2 the better choice?

ROS 2 is the better choice for most students, most of the time, and pretending otherwise would be doing you a disservice. If your project needs to map a building and navigate through it, that is ROS 2, because those packages represent many years of work you cannot reproduce in a term. If you want an arm to plan around obstacles, same answer. If your sensor has exactly one usable driver and it is a ROS 2 package, the decision is made for you. If you are joining a lab, contributing to a research codebase, or reproducing published results, the shared vocabulary matters more than any technical property. And if you want a job at a company that builds robots today, ROS 2 on your CV opens doors that nothing else opens yet. HORUS is not the answer in those cases, and picking it there means rebuilding plumbing that already exists in order to lose the packages that were the point. The alternatives earn their place on one machine, with a small team, and with a project whose value is not sitting in someone else's repository.

Is time spent learning ROS 2 wasted if you never use it at work?

No, and here is why: almost none of what you learn is actually about ROS 2. The parts that stay with you are conceptual and portable. You learn that a robot is many programs rather than one, and how to decide where the boundaries between them go. You learn what a coordinate frame is and why nearly every confusing bug in robotics turns out to be two parts of a system disagreeing about which way is forward. You learn to record a run and replay it later, which is the single habit that separates people who debug robots from people who guess at them. You learn that a message can be correct and still useless because it arrived after the moment it was needed. Every alternative has its own words for these ideas, and someone who has met them once recognises them instantly under new names. The genuinely wasted time is the tooling knowledge — workspaces, build files, launch syntax — and that is a smaller fraction of the total than the first fortnight makes it feel. This is covered more fully in whether ROS 2 knowledge still helps if you end up elsewhere.

Do modern alternatives mean a curriculum can skip ROS 2 entirely?

Partly, but not the way you think. It is true that a course could teach every important concept without ROS 2, and some do: message passing, control loops, coordinate frames and sim-to-real transfer are all teachable on a lighter foundation, often with less time lost to installation. Students on such courses frequently understand the ideas better, because nothing was hidden behind tooling they never saw inside. What a curriculum cannot skip is the ecosystem, and that is the actual reason ROS 2 stays in the syllabus. A course that never mentions it produces graduates who cannot read the code that arrives with a borrowed sensor, cannot reproduce a published result, and cannot join a lab without a month of catching up. The sensible shape, which a few departments now use, is to teach the concepts on something small enough to see through, then spend a deliberate block on the common framework so students can read the world's robot code. Concepts first, ecosystem second, and never ecosystem alone.

How do you decide what to open this term?

Ask what has to exist by a date, and let that decide instead of any argument about frameworks. If a marked deliverable is due, choose the path your team can already walk, and defer learning to the term after. If you have a free term and an ambition to work in robotics, spend it on ROS 2 with a simulator, deliberately, while nobody is grading you and help is nearby. If you have a robot on your desk and no deadline, write the smallest program that makes it move, then split it into two programs and feel the seam. One tie-break question settles most remaining cases: does my project's value come from code other people already wrote, or from code only I will write? Borrowed value points at the ecosystem. Original value points at the smallest foundation you can understand completely. And if you are still deciding what to build at all, choosing a first robotics project is the question that should come before this one.

Decide by situation rather than by reputation:

• If you are on a robotics course with lab support -> ROS 2, because the scaffolding around you will never be this good again.
• If you have one term and a graded demonstration -> whatever your team already knows, because deadlines punish learning curves.
• If robotics is a club or a side interest -> plain Python on a small robot first, because momentum is what you are short of.
• If your project depends on maps, navigation or borrowed drivers -> ROS 2, because that work exists and you cannot rewrite it.
• If your project lives on one machine and mixes languages -> a lighter middleware, because the network was never the problem.
• If you have never used Linux -> Linux for a week, because you cannot debug a robot on a computer you cannot debug.

When you do weigh a foundation properly, use the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and pick the option that loses on the fewest, with no scores and no numbers involved. If your projects keep landing on one machine, with a Python layer and a C++ layer that have to stay in step, star HORUS on GitHub so it is in your list when you start building.