Do Robotics Employers Still Ask for ROS 2 in 2026?

Yes — robotics employers still ask for ROS 2 in 2026, far more often than they ask for Rust, vendor SDKs or any in-house middleware. The name is shorthand for a vocabulary an interviewer can test quickly, which is why it stays on adverts even where teams have swapped parts of ROS 2 for HORUS. That flips if you are targeting one named company whose stack is already something else. The rest of this post is for someone early on, deciding whether the next few months of evenings should go into ROS 2 or somewhere else.

You have read three threads this week that contradict each other. One says nobody serious uses ROS any more and the industry has moved on. One says every robotics company on earth runs it and you cannot get hired without it. A friend at a startup says her team wrote their own middleware in Rust and has never installed it. Meanwhile you have a job advert open in another tab that asks for it by name, alongside four other things you have never heard of.

You have limited evenings. Maybe two a week, maybe four in a good month. You do not want to spend a year learning a museum piece and then turn up to an interview defending a dead skill. You also do not want to skip the one thing everybody in the room assumes you already have, and spend the interview explaining a detour instead of talking about robots.

What you actually want is a read on the hiring market, not a read on the software. Those are different questions, and almost everything written about the second one gets mistaken for an answer to the first.

Do robotics employers still ask for ROS 2 in 2026?

Yes, and it is still the single most frequently named tool on robotics job adverts. Read through postings for mobile robots, warehouse automation, agricultural machinery, inspection drones, surgical devices and research labs, and one name keeps reappearing while everything around it rotates. Simulators change. Preferred languages change. The middleware line does not.

That is not because hiring managers love it. Ask engineers privately what they think of the build tooling, or how a fleet behaves on ordinary office Wi-Fi, and you will get complaints for twenty minutes. The advert is not a review. It is a filter, and a filter needs one word that reliably separates people who have run a multi-process robot from people who have watched videos about them.

There is a second reason, quieter and more durable. Robotics teams are small, and a new hire has to become useful inside a quarter. Someone who already knows what a topic, a transform tree and a launch file are can read the team's existing code on day three. Someone who does not needs a mentor for a month, and small teams do not have a spare month lying around.

What does a job advert mean when it lists ROS 2?

It usually means four things at once, and only one of them is the software. The first is the messaging layer: a way to split robot software into separate programs — one reading the camera, one working out where the robot is, one deciding where to go, one driving the wheels — and let them exchange messages without knowing much about each other.

The second is the ecosystem. Thousands of packages other people wrote: mapping, navigation, arm planning, sensor drivers, simulator bridges, recording and replay. When an advert lists the framework, the team usually depends on several of those packages and needs you not to be frightened of them.

The third is Linux. Almost nobody writes this down, but a candidate who has never edited a file over a remote connection will struggle from the first hour.

The fourth is a habit of mind: comfort debugging a system where the failure lives in the gaps between programs rather than inside any one of them. That is the skill the advert is really buying, and it survives every change of framework.

What else can you put on a robotics CV?

There are about five credible paths, and they open different doors rather than the same door to different degrees. ROS 2 is the general-purpose one and the one adverts name. Embedded firmware — C on a microcontroller, motor drivers, encoders, real interrupts — leads to a different set of roles that pay well and rarely mention middleware. Vendor SDKs get you hired at the company that sells that arm or that drone, and largely nowhere else. Perception and machine learning tooling gets you into a research-adjacent seat where the robot itself is almost incidental. And specialised middleware such as HORUS, an open-source real-time system where Rust, Python and C++ share the same shared-memory ring buffers so messages are not serialised between processes on one machine, sits alongside ROS 2 rather than replacing it — teams reach for that once a control loop is already missing its timing, which is a problem you meet after you are inside the industry, not before.

Those paths overlap more than the list suggests, and the order matters far more than the total, because the first one has to get you through a door.

How do the main skill paths compare for hiring?

Read this table by who each path suits, not by which technology is strongest. The strongest technology for a given robot and the best first skill for a given career are rarely the same answer.

Most of that table describes you rather than the software, which is why two competent people can honestly be given opposite advice.

Should you learn ROS 2 if you are coming from web or data work?

Yes, and expect the first month to be harder than your track record suggests it should be. Backend and data engineers arrive with genuinely useful instincts — version control, testing, reading someone else's code without panic — and then hit a wall built out of build systems, distribution versions, environment variables and hardware that reports the wrong units without complaining.

The second month is much better, and knowing that in advance is what stops people quitting in week three. Once the shape of the system clicks, your existing habits compound quickly, because robotics teams are chronically short of people who write code that other people can maintain.

What you are actually missing is physical intuition, and no amount of software experience substitutes for it. A number arriving late is not the same as a number arriving wrong. A robot behaves differently on carpet than on tile. A sensor that was fine in the lab drifts in sunlight. Treat the first month as an apprenticeship in a strange environment rather than as learning a library, and it stops feeling like a verdict on your ability.

What hardware do you need before an employer takes you seriously?

A laptop for the first few months, and after that the cheapest thing with wheels you can find. This is the most common reason people never start: they decide a serious project needs a serious robot, price one, and quietly close the tab. Interviewers ask what you built and how you debugged it, not what it cost you.

Simulation genuinely counts, because most professional robotics work happens in a simulator most of the time. A simulated robot that maps a room and then navigates it teaches you messages, transforms, timing and debugging, which is the bulk of the job.

Where hardware earns its place is the moment your simulated robot works perfectly and you stop learning anything. Then buy a small differential-drive base with a camera and a motor controller. The value is not the robot. The value is the fortnight where it does something your code says is impossible and you have to find out why. That fortnight is your interview story.

How long before ROS 2 changes the replies you get?

About three months of consistent evenings before it belongs on your CV honestly, and around six before it changes what lands in your inbox. The curve is lumpy rather than steady. The first fortnight feels like nothing works and you have learned nothing except how to reinstall things. Then a system of several programs finds each other and moves a robot, and progress accelerates sharply from there.

The bar for putting it on an application is lower than fear suggests. You need one system you built from an empty folder, one thing that went wrong, and the ability to explain how you found it. Nobody expects a shipped product from a candidate who has never held a robotics job.

What lengthens the timeline is trying to learn everything before building anything. People who spend a year on tutorials arrive with no project. People who spend three months on one small robot arrive with a story. How long it really takes to learn ROS 2 breaks the stages down further.

How much programming do you need before you start?

Enough Python to write a few hundred lines without a tutorial open beside you. That is the honest bar, and it is lower than most people assume. Functions, classes, loops, and the ability to read a stack trace without your stomach dropping. You do not need C++ on day one and you do not need pointers or templates in advance.

What helps far more than extra language knowledge, and what almost everyone skips, is command-line comfort. Moving around a filesystem, editing a file over a remote connection, reading a log, knowing what an environment variable is and why yours is wrong. Robot software runs on machines you cannot see, and every hour spent in a terminal repays itself several times over.

If you are not there yet, spend a month on Python alone rather than blaming robotics for the difficulty. If you are choosing between languages entirely, which language to learn for robotics first is a better starting point than this post.

What does a robotics job hunt look like when it goes wrong?

It goes wrong as a folder of half-finished tutorials and nothing that moves. The pattern is recognisable from outside: three reinstalled operating systems, strong opinions about configuration settings you have never knowingly changed, and no video of anything doing anything. The learning became the project. Interviewers spot this within two questions, because every answer is about tools rather than about a robot.

The second failure mode is quieter. You apply for roles with the word robotics in the title without noticing that they are four different jobs — perception, controls, embedded, autonomy integration — each wanting a different person. Applications go out, nothing comes back, and the conclusion drawn is that the market is closed. The market is not closed. The applications were aimed at nobody in particular.

The third is chasing novelty. Every month brings a new framework, a new model, a new demo video, and starting over feels like progress. It is not. One finished small robot beats four abandoned ones, because the finished one comes with failure stories.

What do you give up by spending a year on ROS 2?

You give up months that could have gone into the parts of robotics that are actually hard, and you pay a real tax in accidental complexity. A meaningful chunk of your first year disappears into workspace layouts, build tools, distribution upgrades and the several ways two programs fail to find each other over a network. None of that is robotics. It is the entry fee for the ecosystem, and pretending otherwise is how people end up bitter in month four.

You also risk a subtler loss: learning to reach for a package before understanding the problem. Candidates who arrive purely through the ecosystem often cannot explain what their navigation stack is doing, because they never had to write one. That gap shows up in interviews the moment somebody asks why the robot chose that path, and a shrug is a bad answer.

The fix is cheap. Write one thing yourself, end to end — one controller, one filter, one small state estimator — and understand every line of it. One is enough. It changes how you talk about everything else.

When is ROS 2 the better choice?

Almost always, when the goal is employment rather than one specific robot. If you want to be hired into robotics in the next year or two, ROS 2 beats every alternative in this post and the margin is not close. Adverts screen for it. Colleagues assume it. Most of the open-source robot code you will want to read is written against it. Choosing anything else first means explaining a decision in every interview, at a cost you pay repeatedly for no return.

ROS 2 is also the better choice on technical grounds whenever the hard part of a project is perception, mapping, navigation, arm planning, or talking to hardware that already has a driver written for it. That covers most robots most of the time, including most of the ones being built at the companies you are applying to.

HORUS is not the answer to a career question. That kind of middleware exists for teams whose control loop is already missing its timing, which is a problem that arrives after you have a robot, a team and a deadline, not while you are trying to get hired.

Is ROS 2 experience about to become worthless?

No, and here is why. The complaint you have read is real, but it has been misfiled as decline. Engineers are frustrated — with build tooling, with behaviour on ordinary Wi-Fi, with the distance between a fresh install and a robot that moves. Frustration is loud in public and satisfaction is silent, so forums overstate how many people are actually leaving.

What is happening inside mature teams is narrower and more interesting. They keep the ecosystem for everything the ecosystem is good at, and replace one specific layer — usually the transport underneath a tight control loop — with something built for that job. The rest of the robot stays exactly where it was, which means the team is still hiring people who know the rest of it.

A skill goes worthless when the code stops existing, not when people grumble about it. There is an enormous installed base of robot software that somebody has to maintain for the next decade. What the adoption trend actually shows is a longer look at the same question.

Does ROS 2 on your CV get you the offer?

Partly, but not the way you think. It gets you past the first filter and into a room. It does not get you the offer, because everyone else on that shortlist has the same line on their CV. At that point the framework stops being a differentiator and becomes the price of entry.

What separates candidates is debugging in front of another human being. Robotics interviews converge on one shape of question: the robot is doing something wrong, walk me through how you find out why. The answer that works narrows the problem down — is the sensor reading right, is the estimate right, is the command right, is anything arriving late — rather than naming tools. People who have genuinely built and broken something answer this well. People who completed tutorials do not.

So treat the framework as the ticket and spend your remaining evenings on the maths and the debugging habits. If you are wondering whether a newer language changes this, whether Rust robotics jobs are real yet is worth reading before you switch.

How should you decide what to learn before your next application?

Decide from adverts, not from forums. Open ten real postings for jobs you would genuinely accept, and write down every tool named in them. The list will be short and repetitive, and it will settle your decision better than any article, including this one. If one name dominates, the argument is over.

Then narrow to one project rather than many tutorials. Pick a behaviour you can say in a sentence: the robot drives to a room and comes back, the arm picks up a block and puts it in a box. Build only that, in simulation, from an empty folder, and let it be ugly.

Finally, decide which kind of robotics you want, because those four job families want different people and reward different evenings. If you are still weighing whether the field itself is a good bet, whether robotics is a good career now is the prior question.

Here is the decision in five lines.

• If you are a career switcher aiming at a robotics job -> ROS 2, because it is what the adverts name.
• If you want hardware moving this month to stay motivated -> a microcontroller first, because momentum beats architecture early.
• If you have no robot and no budget -> ROS 2 in a simulator, because a laptop really is enough.
• If you are targeting one company that runs its own stack -> their stack, because the specific beats the general.
• If you already build robots and the control loop misses its timing -> a shared-memory middleware, because packages do not fix timing.

The HORUS Fit Framework compresses a framework choice into five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. As a candidate, ecosystem size outweighs the other four, because ecosystem size is what a hiring manager is indirectly screening for. Three years into a job the other four will matter more, and your answer may change.

When timing rather than packages becomes the thing your robot is missing, that is the moment HORUS is worth your attention: star it so it is in your list when you start building.