Robotics Roadmap 2026: What to Learn, In Order

Learn Python and a simulator first, then one control loop, then ROS 2 or HORUS, and leave C++ and electronics until something forces them. That order works because every later topic is easier once you can already see a robot move and change one thing at a time. The order flips if you have a hardware deadline, where the machine on your desk decides what you learn next. The rest of this post is for someone starting from ordinary programming who wants a year of study that does not double back on itself.

You have watched the videos. A robot dog trots up some stairs, an arm folds a shirt, someone speaks a sentence and a machine does the thing. You want to build that, so you search for how to start, and the internet hands you eleven answers at once.

One person says learn C++ properly first. Another says nobody writes C++ any more, learn Python. A third says none of it matters until you can solder. A fourth insists you begin with ROS 2, and a fifth replies that ROS 2 is bloated and you should write your own. Somebody mentions kinematics and somebody else mentions reinforcement learning, and the comments underneath are arguing about a distro you have never heard of.

So you pick one and start. Three weeks later you are still fighting an installation, you have not seen anything move, and you cannot tell whether you are behind or whether this is simply what the first three weeks feel like. That not knowing is the real problem. It is not the material being hard, it is having no map, so every difficulty might be a normal difficulty or might be a sign you chose wrong, and there is no way to tell from inside.

What should you learn first if you want to build robots?

Learn to make something move on a screen before you learn anything else. Specifically: Python well enough to write a loop and a class, then a simulator with a robot model already in it, then a small program that reads a sensor value and sends a command back, over and over. That single exercise contains the whole of robotics in miniature, and everything you study later is a better answer to a question that exercise raises. Why does the robot wobble? Control theory. Why does it not know where it is? State estimation and localisation. Why does the camera code slow everything down? Concurrency and message passing. Learning in that direction means every new topic arrives attached to a problem you have personally suffered, which is the difference between remembering something and merely having read it. Learning in the other direction, starting with theory or with wiring, means months of study before anything connects to a robot, and most people quietly stop somewhere in month two. Motion first. Understanding follows motion far more easily than motion follows understanding.

What does learning robotics actually cover?

Robotics is four separate crafts wearing one name, which is why the advice you find contradicts itself so cheerfully. The first craft is making a machine move at all: motors, drivers, wiring and the code that talks to them. The second is knowing where things are: cameras, depth sensors, coordinate frames, and the constant business of turning noisy measurements into a usable belief about the world. The third is deciding what to do: planning a path, sequencing a task, handling the case where the shelf is empty. The fourth is holding it all together: processes, messages, timing, logging, and the unglamorous plumbing that decides whether the other three ever run at the same time. Nobody is strong in all four, and job adverts rarely admit that. When one person tells you to learn electronics and another tells you to learn machine learning, both are describing their own craft honestly. Your first task is not choosing the correct one. It is knowing that four exist, so you can tell which one is currently blocking you.

What are the real routes into robotics, and which suits you?

There are about eight genuine routes, and they differ mainly in what you touch first and what you are willing to postpone. The Python-and-simulator route gets a robot moving fastest and postpones hardware. The ROS 2 route front-loads the standard toolset that most labs and companies actually use, which is slower to start and pays off directly if employment is the goal, and there is a lighter option beside it: HORUS, an open-source real-time middleware for Rust, Python and C++, which suits a learner whose robot is one computer running Python beside compiled control code, while ROS 2 remains the route to take if you want the drivers, navigation and motion planning that already exist and the shared vocabulary of the teams hiring. The electronics route builds the machine before programming it, and suits people who wanted a physical hobby all along. Read the table as descriptions of people rather than a ranking, and expect to move between rows as your goal sharpens.

What should you do if you are already a working software developer?

Skip the beginner programming material entirely and spend your first month on the three things your job never taught you. The first is Linux at the level of living in a terminal without irritation, because nearly every robotics tool assumes it and beginners routinely blame robotics for what were operating-system problems. The second is coordinate frames, which is the genuinely new idea: the camera sees a mug at one position, the arm needs that position in its own terms, and the transformation between them is the source of a startling share of all robot bugs. The third is the habit of treating time as a first-class concern, since your web work let you be late occasionally and a robot does not offer that. What transfers beautifully is everything else: version control, debugging, testing, reading unfamiliar code, and the instinct that a system doing something odd has a cause you can find. If you are weighing which language to invest in, the first-language question has a clearer answer than the arguments suggest.

What hardware do you need, and when should you buy it?

Buy nothing for the first two or three months, then buy the cheapest thing that moves. A simulator covers more of the early curriculum than beginners expect, and it removes the two worst obstacles to learning: waiting for parts, and breaking something you cannot afford to replace. When you do buy, resist the impressive machine. A small wheeled robot or a low-cost arm teaches the lessons that matter, and those lessons are all about disappointment: the motor that does not turn as far as you asked, the camera that sees a different colour in the afternoon, the cable that works until the robot turns. An expensive machine teaches the same lessons while making you afraid to experiment, which is the opposite of what a learner needs. There is one exception. If a specific robot is the actual goal, buy that robot early, because its documentation, its driver and its quirks are then part of your syllabus. Learning robotics without buying anything covers how far the free route goes.

How long does this roadmap take, honestly?

You can have a simulated robot doing something deliberate within a month of evenings, and you will feel competent somewhere in the second year. Those two facts are both true and beginners usually only hear one of them. The early progress is genuinely fast because the tools are good and the tutorials are plentiful, so a month of consistent evenings produces a robot that navigates a simulated room and reacts to what it sees. Then the curve changes shape. The middle stretch, roughly months three through nine, is where the interesting failures live: things work in simulation and not on hardware, timing problems appear that no tutorial mentioned, and progress stops feeling weekly. Most people who give up leave during that stretch, and they leave believing they lacked talent rather than that they hit the normal part. Plan for it. Set goals that are small enough to finish inside a fortnight, keep a log of what broke, and accept that a month spent understanding one stubborn failure is a month well spent rather than a month lost.

What do you need to know before you start at all?

Enough programming to write a loop, a function and a class in one language without looking everything up. That is the whole prerequisite, and everything else on the internet's list is optional at the start. You do not need calculus yet. You do not need to have soldered anything. You do not need to know what a quaternion is, and you will meet one soon enough with a concrete reason to care. What genuinely helps before you begin is a tolerance for setup work, because robotics software involves more installation friction than most fields and the first real skill is not panicking when a build fails. Bring the habit of reading error messages slowly rather than pasting them straight into a search box. Bring some way of keeping notes, since you will solve the same environment problem three times otherwise. If you are hesitating between languages before you start, start with Python, and let the first project that genuinely needs speed be the thing that sends you towards a compiled language.

What does it look like when learning robotics goes wrong?

It looks like three months of activity with nothing that moves, and a growing suspicion that you are not clever enough. The commonest shape is tutorial drift: you complete one guide, then another, then a course, and each one works while you follow along, but you could not start an empty project on your own because you have been reading rather than building. A second shape is the perpetual setup, where every session is spent on installation, environment problems and version mismatches, so the learning never begins. A third is the ambition trap, where the first project is a humanoid or a self-driving car, and the gap between that and your current ability is so wide that no week produces visible progress. All three share one cure: shrink the target until you can finish something in a fortnight, and make the finished thing move. A robot that drives in a square and stops before the wall is worth more to your development than a half-built machine with a beautiful architecture diagram and no motor that has ever turned.

What do beginners try first, and why does it stall?

Almost everyone starts with the ROS 2 tutorials, and a large share of them stop somewhere around the third one. That is not a criticism of ROS 2, which is genuinely the standard toolset and worth learning. The stall has a specific cause: those tutorials assume Linux fluency, a working mental model of how processes talk to each other, and comfort with build systems, and a beginner missing any of the three cannot tell which layer a failure belongs to. When an error appears, the question is not what did I do wrong but rather which of five unfamiliar systems is upset, and no amount of persistence answers that quickly. The fix is not to avoid ROS 2 but to arrive at it later, once you have written a program that talks to another program and understood why that was harder than it looked. The second common stall is buying hardware immediately and discovering that most of your time now goes to wiring and power rather than to robotics. Whether ROS 2 is worth learning at all is a fair question to settle before you spend that time.

What do you give up by following an order like this?

You give up depth in the first year, and you should know that going in. Someone who starts with control theory and mathematics will understand why their robot wobbles in a way you will not for a while, and they will be better than you at the class of problem where an equation is the answer. Someone who starts with electronics will build machines you cannot build. Moving fast towards visible motion means accumulating a stack of things you use without fully understanding: a planner you did not write, a filter you cannot derive, a transform library doing rotations you could not do by hand. That debt is real and it comes due, usually at the point where something behaves oddly and the explanation lives inside the part you skipped. The trade is worth making anyway, because the alternative costs more people. Motivation is a resource with a shorter life than most curricula assume, and an order that produces a moving robot early keeps you present long enough to pay the debt down deliberately, one topic at a time, each time attached to a failure you actually met.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every learner whose goal is a job, a research position or a robot that must navigate a real building. The reason is not elegance, it is inventory. Drivers for the sensors you will buy, navigation that already works, motion planning that already avoids obstacles, simulation assets, and a decade of answered questions that match the errors you will hit word for word. Nothing else comes close on that measure, and a learner benefits from a large inventory more than an experienced team does, because a beginner cannot yet tell the difference between a hard problem and a missing package. ROS 2 is also the shared vocabulary: interviews assume it, papers assume it, and colleagues will describe their system in its terms. HORUS is not the answer for those learners, and choosing it there trades a huge library of working parts for plumbing you did not need to change. Learn ROS 2 second, after you can program, and it stops being a wall and becomes a toolbox.

Do you need a degree to work in robotics?

No, and here is why: robotics teams hire for evidence, and a working robot is better evidence than a transcript. The field has a large practical surface, and much of the daily work is software engineering with physical consequences, which is a thing you can demonstrate directly. A public repository containing a robot that does one task, with honest notes about what failed and how you found the cause, tells a hiring manager more than a module grade does. That said, the honest exception deserves stating plainly. Certain corners of robotics genuinely gate on formal mathematics: control design for aircraft, estimation research, optimisation-heavy motion planning, anything where the job is deriving rather than integrating. If those are your target, the degree is a shortcut through material that is genuinely hard to self-teach. For the much larger number of roles building, integrating and debugging robot systems, the degree is a common path rather than a required one, and the portfolio does the work.

Will an AI assistant write the robot code for you?

Partly, but not the way you think. An assistant is genuinely excellent at the parts of robotics that resemble ordinary software: parsing a configuration, writing a small service, explaining an unfamiliar error, generating the boilerplate around a node you already understand. Used that way it removes real drudgery and speeds up a beginner considerably. Where it misleads is everything physical. An assistant cannot see that your camera is mounted upside down, cannot know your gripper closes slightly late, and will confidently produce code assuming a coordinate convention your hardware does not use. It also tends to suggest the most-written-about approach rather than the one fitting your machine, which is why beginners are so often handed a heavyweight setup for a robot that needed a script. The skill that matters, then, is not prompting. It is being able to read the answer and tell whether it matches your robot, and that skill only comes from having debugged a few things yourself.

How do you decide what to study next month?

Pick whichever thing is currently stopping your robot, and study exactly that. This is a better rule than any curriculum because it guarantees relevance and it gives you a finishing condition. If the robot moves but wobbles, the topic is control. If the robot has no idea where it is, the topic is estimation. If two pieces of your code cannot run at the same time without one of them stuttering, the topic is messaging and timing, and what a control loop is doing between decisions is the right place to begin. If nothing is stopping your robot, your project is too small, so make it harder rather than reaching for a syllabus. Two questions keep this honest month to month. First: can I explain to someone else what my robot does and where it fails? If not, understanding is thinner than it feels. Second: what did I use last month without understanding? Pick one such thing each month and go a layer down, which turns borrowed tools into owned ones at a sustainable rate.

Decide by situation rather than by ambition:

• If you have never programmed -> Python and a simulator, because nothing else makes sense until code and motion connect.
• If you already ship software -> Linux, coordinate frames and timing, because those are the three things your job never taught you.
• If you want a robotics job or a lab place -> ROS 2 after your first moving project, because it is the shared vocabulary of the people hiring.
• If you want a physical hobby -> a cheap kit now, because motivation dies faster than curricula account for.
• If your robot is one computer running Python beside compiled control code -> a middleware built for that boundary, because that boundary is where beginners lose weeks.
• If you have stalled twice already -> a structured course, because the missing ingredient is a deadline rather than material.

When the foundation question finally arrives, weigh your candidates on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target and licence — and take the option that loses on the fewest, with no scoring involved. If your path is heading towards mixed-language code on a single machine, star HORUS on GitHub so it is in your list when you start building.