Which Robotics Subfield Should You Specialise In?

Specialise in perception, control, or robot software plumbing based on which failure you enjoy chasing, not on which subfield sounds most impressive. Each asks something different of you daily — data, mathematics, hardware patience, or other people's timing bugs — and each meets a foundation like ROS 2 or HORUS eventually. That flips if a team has offered you a seat: specialise in what that team is short of. The rest of this post is for someone who has finished one or two small robots and now feels pulled in six directions.

You built something. It drives across the room, or the arm picks up the block, and for about a day that felt like the whole thing. Then you went looking for what comes next and found that robotics is not one field but a dozen, each with its own vocabulary, its own conferences, and its own set of people insisting theirs is the part that actually matters.

So you started sampling. A weekend on mapping. A week on a reinforcement learning tutorial that trained something in a simulator you then could not connect to anything real. A month of intending to learn kinematics properly. Every job advert you read wants a different one of these, in depth, with years attached. Every roadmap you find lists all of them as prerequisites for each other.

Underneath sits a specific worry, and it is not about difficulty. It is that you have a limited number of evenings, that depth is what gets hired and admired, and that spreading yourself across six areas for another year will leave you slightly unqualified for all of them while the people who picked one are three years in.

Which robotics subfield should you specialise in?

Specialise in the subfield whose failures you are willing to spend a bad week on, because every subfield is mostly bad weeks with one good afternoon at the end. That sounds like a dodge and it is not. These areas differ far less in prestige or difficulty than in what an ordinary Tuesday looks like inside them. A perception Tuesday is staring at data that is nearly right and working out which part of nearly is lying. A controls Tuesday is a machine that oscillates and a page of algebra explaining why. A manipulation Tuesday is a gripper that dropped the same mug twice for two different reasons. An infrastructure Tuesday is other people's code, a log with a gap in it, and the question of which process went quiet. Each of those is genuinely absorbing to somebody and genuinely intolerable to somebody else, and you cannot tell which you are from a course description. You can tell after one weekend of doing it badly. The rest of this post is about running those weekends deliberately rather than drifting into whichever area had the best tutorial.

What does specialising in a robotics subfield actually mean?

Specialising means becoming the person a team calls when one particular kind of thing goes wrong, and it is a reputation more than a curriculum. A robot, from a distance, does four things and pretends to do a fifth. Something senses the world and turns it into numbers. Something decides what to do with those numbers. Something moves metal and keeps it steady while it moves. Something carries messages between all of those parts on time. And a simulator pretends to be the world so you can be wrong cheaply. The subfields map onto those boxes, plus the embedded layer underneath them all and the learning layer that increasingly sits across the middle two. Specialising is picking one box and accumulating the unglamorous knowledge of how that box lies to you: which sensor reports confidently when it is confused, which controller is steady in the lab and marginal on carpet, which message quietly stopped arriving an hour before the crash. Nobody is paid for the textbook version of any of these. They are paid for the lying part.

What are the actual subfields, and who is each one for?

There are roughly eight, and they sort by what you spend a Tuesday doing rather than by what the department is called. Perception turns cameras, depth sensors and lidar into a belief about what is out there, and suits people who like data that is almost right. State estimation and control keeps the machine steady, and suits people who like mathematics that pays off visibly. Manipulation is grasping and contact, the most physically stubborn area, where progress is counted in objects the gripper stopped dropping. Navigation and mobility is getting a base from here to there without hitting anything. Learning-based control trains policies and increasingly whole vision-language-action models, and suits people who already have machine learning habits. Simulation and sim-to-real is the discipline of being wrong cheaply. Embedded and firmware lives under all of it. And robot software infrastructure, the plumbing carrying messages between these parts, is the one people fall into rather than choose; it is learned on a foundation, either ROS 2, whose packages and tooling are the common language of the field, 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.

How do the subfields compare side by side?

They compare most usefully on two things: what you must already know before you can be useful, and the day you would regret the choice. Difficulty is not one of those things, because every row below is hard in a way that only shows up months in. Read the table as descriptions of people rather than as a ranking, and pay closest attention to the final column, which is where most mis-picks are visible in advance.

What should you specialise in if you are a self-taught software engineer?

Perception or robot software infrastructure, because both convert the skills you already have into robotics skills without asking for a lab. If you can write code, read a log, and stay calm while something is intermittently wrong, you already have most of what infrastructure work demands, and the rest is vocabulary you can pick up on a real project in a couple of months. Perception is the other natural door: much of it is data handling, and serious work happens on recorded logs and public datasets from a desk. The two areas that punish self-taught entry hardest are control theory and manipulation, not because the material is closed, but because control rewards a structured mathematics background and manipulation genuinely needs hardware you can break repeatedly. Neither is off-limits; both are slower alone. A pattern worth noticing: many self-taught engineers arrive at infrastructure by accident, because they were the one who got everything talking on the first team project, and then discover that the accident was a preference.

What should you specialise in if all you own is a laptop?

Perception, learning-based control, or simulation, because all three are real work on a machine with no robot attached. Recorded datasets are not a toy substitute; a great deal of production perception work happens on logs collected months ago by somebody else. Simulation is the same story: you can build, break and rebuild a machine that does not exist, and the discipline of noticing where the simulator is lying to you is a specialisation in its own right. Learning-based control trains in simulation by default. What a laptop cannot teach you is the part only hardware teaches: that the connector was loose, that the floor is not flat, that the motor gets warm and behaves differently after twenty minutes, that the sensor sees the sun. So treat the laptop years as genuine but incomplete, and plan the moment you get access to a real machine — a shared lab, a cheap arm, a robot vacuum you are allowed to ruin — rather than assuming access will arrive on its own.

What should you specialise in if you want work within a year?

Choose the area where you can put a running artefact in front of an interviewer, which for most people means perception or infrastructure. Hiring in robotics is unusually evidence-driven: a video of your thing working, a repository someone can read, and a clear account of what went wrong and how you found it will beat a list of courses in almost every conversation. Perception and infrastructure both produce that evidence cheaply. Control and manipulation produce excellent evidence too, but usually require hardware access you may not have inside a year. Learning-based roles compete on machine learning credentials in a way the others do not, so arriving there from a standing start in twelve months is realistic mainly if you already have the machine learning half. Beyond the choice itself, the boring advice holds: build something that runs continuously rather than a demo, and be able to explain one failure in detail. A survey of which robotics skills are actually getting hired is worth reading against your own list before you commit a year.

What should you specialise in if you have never finished a robot project?

Nothing yet — finish one small robot end to end, then let the part you disliked least make the choice for you. This is not a delaying tactic. Specialising before you have built anything means choosing from descriptions, and descriptions are written by people who love their subject, so all of them sound compelling. Building one whole small machine — a sensor, a decision, a motor, a loop that keeps running — forces you to touch every layer badly. That experience is the instrument that measures your taste, and it takes weeks rather than years. Watch for two signals as you go: which failure made you curious rather than tired, and which part you kept improving after it was already good enough. Those two answers predict more than any career guide. Once one robot works and you are wondering what the next month is for, the question of what to do after your first robot works is the one to answer before this one.

What does it look like when you specialise in the wrong thing?

It looks like competence with no pull: you can do the work, you do it adequately, and you never once open it on a Saturday. The pattern is quiet, which is what makes it dangerous. You find yourself reading about a different area during the work day. You volunteer for the integration tasks nobody wanted because they are more interesting than your own remit. Your notes are full of the other subject. Meanwhile the work itself is fine, which removes the obvious signal to stop. There is a second version that hurts more: specialising in an area you love reading about but dislike doing. Control theory collects these people, because the papers are elegant and the reality is a machine that oscillates for reasons the paper did not cover. Learning-based control collects them too, because the demos are thrilling and the daily work is data cleaning and training runs that fail overnight. The test in both cases is not whether the idea excites you. It is whether the debugging does.

What do you give up by specialising at all?

You give up the ability to build a whole robot by yourself, at least for a while, and that is a real loss rather than a trade everyone should accept. A deep perception specialist without a team has a beautiful pipeline and no machine. A control specialist alone has a steady loop attached to nothing. Specialisation pays back only when other people cover the layers you dropped, which means it quietly assumes a team, a lab or a company. If you are building alone and intend to keep building alone, broad working knowledge with one area of depth will serve you better than depth by itself. You give up optionality more slowly than people fear: the layers share more than they appear to, and someone with a year of perception behind them can move into infrastructure faster than a newcomer. What you cannot recover cheaply is the mathematics background that control and estimation assume, which is why that particular door is the one to walk through early if you want it left open.

When is ROS 2 the better choice?

ROS 2 is the better choice for most subfields, because most of them are built on code other people already wrote, and that code is ROS 2 code. If you want to specialise in navigation, the mapping and planning packages you would otherwise spend years reproducing already exist and are already integrated. Manipulation is the same story for motion planning and collision checking. Perception work leans heavily on drivers, message types, recording tools and the visualiser that lets you see what the robot believes. If your robot spans more than one machine, or you are heading for a lab or a company, ROS 2 is also the shared vocabulary, and knowing it is career currency independent of any technical argument. HORUS is not the answer for those readers, and choosing it there means rebuilding plumbing that already exists in order to lose the packages that were the point. The honest exception is narrow: a single machine, several languages inside one robot, and a loop that must not hesitate.

Do you have to pick a subfield before you can start?

No, and here is why: nobody hires or admits people on the strength of a declared intention, and the declaration costs you the exploration that would have made it accurate. These areas are not university tracks with entry requirements; they are descriptions of where people ended up spending their hours. Almost every roboticist you can name arrived at their speciality by finishing something, noticing which part they kept fiddling with, and doing more of that. The practical version is to run short, deliberate experiments instead of long, vague ones: two weeks on a perception problem with a real dataset, two weeks making two processes talk to each other dependably, two weeks getting a simulated arm to hold a position under load. Each ends with something that runs and an opinion you did not have before. Six weeks of that produces a better decision than six months of reading roadmaps, and it also leaves three small artefacts behind, which is three more than the reading produced.

Will foundation models make the classic subfields obsolete?

Partly, but not the way you think. Learned models are absorbing parts of perception and parts of low-level control, and a policy trained end to end can replace hand-written pipelines that took teams years to tune. What is not being absorbed is everything around them. A model still needs data collected by a working machine, calibrated sensors, a loop that runs on time, a safety layer that stops the arm before it hits the table, and someone who can tell whether a failure came from the model, the timing or the hardware. Those are the classic subfields, and demand for them rises with the models rather than falling. The area most changed is neither perception nor control; it is the boundary between them, where deciding what the learned part should and should not own has become the interesting design question. The realistic advice is to specialise in a classic layer and stay fluent in the learning side, rather than betting your evenings on either extreme.

How do you decide which subfield to commit to?

Decide from evidence you generated rather than from a description someone else wrote, and give yourself a deadline for deciding. Take three areas that appeal, spend a bounded uninterrupted stretch on each — long enough to get past the tutorial and into a real failure — and write down two things at the end of each: what you were doing when you lost track of time, and what you were doing when you wanted to close the laptop. Then pick the one with the best ratio, not the one with the best prospects, because prospects change and stamina does not. Add one filter afterwards: does this area fit the hardware, the time and the people you actually have this year? A manipulation speciality with no arm is a reading habit. Finally, hold the decision loosely for the first year and tightly after that. Sequencing the surrounding learning matters as much as the choice itself, and an ordered roadmap of what to learn will stop you studying the right subject in the wrong order.

Decide by situation rather than by ambition:

• If you have not yet finished a robot end to end -> no speciality yet, because the finished robot is the instrument that measures your taste.
• If you own a laptop and no hardware -> perception or simulation, because both are real work on recorded data.
• If you want to be hired within a year -> the area where you can show something running, usually perception or infrastructure.
• If you already work in machine learning -> learning-based control, because you keep your existing habits and add the physical half.
• If you enjoy the moment everything finally talks to everything -> robot software infrastructure, because that taste is rarer than it sounds.

When the foundation question arrives, and it arrives in every subfield eventually, 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 speciality is drifting towards the plumbing, and your robot has a Python layer, a C++ layer and a growing suspicion that the boundary between them is where your evenings go, star HORUS on GitHub so it is in your list when you start building.