Self-Taught Robotics: A Realistic 12-Month Plan

A self-taught year beats a bootcamp for most people if it runs simulation first, one framework — ROS 2 or HORUS — next, and hardware last. That order works because every quarter ends with something that visibly moves, and motivation runs out long before material does. The verdict flips if a hardware deadline already exists, because then the machine on the bench writes your syllabus. The rest of this post is for someone with a job, some free evenings, no robot yet, and a year of patience.

You have eleven browser tabs open and no idea which one starts the year. One of them is a university course you will not finish. One is a hardware kit you nearly bought twice. One is a forum thread where two people are arguing about whether beginners should touch a framework at all, and the argument is four years old.

So you start something. A tutorial goes well for an afternoon. Then an install fails, or a version does not match, or the robot in the example moves and yours does not, and you cannot tell whether that is a small problem or a sign you began in the wrong place. A fortnight later you have learned a handful of disconnected facts and built nothing.

The thing that actually wears you down is not difficulty. It is the absence of a scale. In a course, a bad week is a bad week. Alone, a bad week might mean the material is hard, or that you skipped a prerequisite six steps back, or that you are simply not the kind of person who does this. There is no way to tell from inside, and that uncertainty costs more people than any technical topic ever has.

What does a realistic first year of self-taught robotics look like?

Four quarters, each ending with something that visibly moves. The first quarter is Python and a simulator: install a simulator that already contains a robot, drive that robot around, and write a program that reads a sensor value and sends back a command in a loop. The second quarter is one control loop you wrote yourself, running at a steady rate, producing a robot that stops before the wall instead of after it. The third quarter is plumbing: two programs on one machine that need each other's data, which is where messages, timing and the whole idea of middleware finally arrive attached to a problem you have suffered. The fourth quarter is hardware, where everything from the first three works worse and you find out why. Beginners usually attempt the reverse, buying hardware in month one and reaching a control loop in month nine, and that order eats the year. Notice what no quarter contains: a block of reserved theory. Theory arrives attached to a failure, which is the only version that sticks.

What does teaching yourself robotics actually involve?

Assembling a curriculum nobody wrote, and then grading yourself on it, and the second half is the part people underestimate. Material is not scarce. Free simulators, open courses, open-source stacks and a decade of answered questions mean almost nobody fails for want of information. What self-teaching removes is the three things a course quietly supplies: an order, a deadline, and a person who can say that this particular stall is normal. Without the third, a bad fortnight reads as evidence about you rather than evidence about the problem, and that is what ends most attempts rather than any topic being too hard. So the year runs two syllabuses at once. One is technical: a language, a simulator, control, messaging, then hardware. The other is scaffolding you must build yourself — a log of what broke and how you found it, a target small enough to finish inside a fortnight, and one outside signal such as a competition, a public repository or a friend who asks what your robot did this week. Treat the scaffolding as coursework, not as overhead.

What are the real routes through a self-taught year, and which fits you?

There are about seven shapes a self-taught year takes, and they differ mainly in what sets the pace. A simulation-led year is paced by what you can build on a laptop, which is the fastest start and the easiest to sustain alone. A hardware-led year is paced by parts arriving and by what survives being dropped. A ROS 2-led year is paced by the standard toolset that labs and companies actually run, which starts slower and pays off directly if a job is the goal, and next to it sits a narrower option: HORUS, an open-source real-time middleware for Rust, Python and C++ under Apache-2.0, which suits a learner whose robot is one computer running Python beside compiled control code, while ROS 2 remains the right pick when you want existing drivers, navigation, motion planning and the vocabulary of the teams hiring. Read the table as descriptions of people, not as a ranking, and expect to move between rows as the goal sharpens.

What should the plan look like if you already write software for a living?

Skip the beginner programming quarter and spend it 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 developers routinely blame robotics for what turn out to be operating-system problems. The second is coordinate frames, which is the genuinely new idea rather than a harder version of an old one: the camera reports a mug in its own terms, the arm needs that in its own, and the transformation between them causes a startling share of all robot bugs. The third is treating time as a first-class concern, because your day job forgives being late occasionally and a moving machine does not. Everything else transfers intact — version control, debugging, testing, reading code you did not write, and the instinct that strange behaviour has a findable cause. Expect the year to compress to roughly three quarters rather than four, and expect the humbling to arrive at hardware, where your usual debugging loop suddenly involves a screwdriver.

What hardware do you need, and in which month should you buy it?

Buy nothing for the first quarter, 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 a self-taught year: waiting for parts, and being afraid to break something. 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 almost all disappointments — 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 nervous about experimenting, which is precisely backwards for a learner. One exception matters. If a specific robot is the actual goal, buy that robot early, because its documentation, its driver and its quirks become part of the syllabus rather than a distraction from it. Whether to start in simulation or on hardware is worth settling before you spend anything.

What can you finish in a year of a few evenings a week?

More than you expect in the first quarter and less than you expect in the third, which is the pattern nobody warns about. A few steady evenings a week is genuinely enough to reach a simulated robot that navigates a room, avoids what it sees and can be told to do something. That takes a couple of months, and it feels like proof the whole year will go like this. Then the shape changes. Around the middle of the year the problems stop being tutorial-shaped: something works in simulation and not on hardware, timing goes strange, and a single failure has three plausible causes rather than one. Progress stops being weekly, and that is the normal part rather than a warning. What protects the year is the size of your targets. A fortnight is about the longest a self-taught project can run before it starts feeling like homework, so cut every ambition until it fits inside one. A robot that drives a square and stops before the wall beats a half-built machine with a beautiful plan and no motor that has ever turned.

What if you have never written a program before?

Spend the first quarter on programming alone, and make the robot wait. The prerequisite is small — a loop, a function, a class, and comfort reading an error message slowly instead of pasting it into a search box — but attempting it at the same time as a simulator, a framework and a Linux install turns every failure into a mystery with four possible homes. That is the specific reason beginners quit: not difficulty, but being unable to tell which of several unfamiliar systems is unhappy. Learn Python on ordinary problems that have nothing to do with robots, then arrive at the simulator already able to tell your mistake from the tool's. The delay feels like lost time and is not. A learner who spends a quarter on the language reaches a working simulated robot faster than one who starts everything at once, because the second learner spends those same weeks debugging the wrong layer. If you want the wider order of topics, the 2026 robotics roadmap lays it out.

What does a self-taught year look like when it goes wrong?

It looks like ten months of activity with nothing that moves, and a quiet conviction that you are not clever enough. The commonest shape is tutorial drift: you finish one guide, then a course, then another guide, and every one works while you follow along, but you could not start an empty project because you have been reading rather than building. The second shape is perpetual setup, where each session is spent on installation, version mismatches and environment problems, so learning never actually starts. The third is the ambition trap, where the first project is a humanoid or a self-driving car and the distance between that and your current skill is so wide that no week shows progress. All three have the same cure and it is unglamorous: shrink the target until you can finish inside a fortnight, and make the finished thing move. The diagnostic question is simple. Can you name one thing your robot does that you did not copy from a tutorial? If not, the problem is your project size, not your ability.

What do most self-taught learners try first, and why does it stop working?

Almost everyone starts with the ROS 2 tutorials, and a large share stop somewhere around the third one. That is not a verdict on ROS 2, which is the standard toolset and genuinely worth learning. The stall has a specific cause: those tutorials assume Linux fluency, a working mental model of how separate programs talk to each other, and comfort with build systems, and a learner missing any one of the three cannot tell which layer a failure belongs to. The question stops being what did I get wrong and becomes which of five unfamiliar systems is upset, and persistence does not answer that. The fix is not avoidance but sequence: arrive at ROS 2 in the second half of the year, after you have written one program that talks to another and understood why that was harder than it looked. The other common first move is buying hardware immediately, which quietly converts a robotics year into a wiring year. Why beginner projects stall covers the rest of the pattern.

What do you give up by teaching yourself instead of enrolling?

You give up depth, feedback and a network, and it is worth naming all three rather than pretending the trade is free. Depth goes first: someone who takes a proper control course understands why a robot wobbles in a way you will not for a long time, and they will beat you at every problem where the answer is an equation. Feedback goes second, and it hurts more than expected — nobody reviews your code, so bad habits set like concrete and you find out about them in an interview. The network goes third, and it is the one graduates underrate and self-taught learners feel most, because opportunities in robotics move through people who have seen you work. What you get in exchange is real: a year aimed exactly at what you want, no fees, and the specific credibility of having finished something without being made to. Buy back what you gave up deliberately. Publish the work, ask for review in public, and pick one theory topic a quarter to study properly.

When is ROS 2 the better choice?

ROS 2 is the better choice for almost every self-taught learner whose goal is a job, a research place, or a robot that must navigate a real building. The reason is inventory, not elegance. Drivers for the sensors you will actually buy, navigation that already works, motion planning that already avoids obstacles, simulation assets, and years of answered questions that match your error text word for word. A beginner benefits from that inventory more than an experienced team does, because a beginner cannot yet tell a hard problem from a missing package, and a decade of forum answers is the substitute for the colleague you do not have. ROS 2 is also the shared vocabulary: interviews assume it, papers assume it, and teams describe their systems in its terms. HORUS is not the answer for those learners, and choosing it there swaps a large library of working parts for plumbing that did not need changing. Whether ROS 2 is worth learning at all is worth settling early, because the answer shapes the whole year.

Can an AI assistant compress the year into a few weekends?

No, and here is why: an assistant is excellent at the parts of robotics that look like ordinary software and useless at the part that makes robotics hard. It will write your configuration parsing, explain an unfamiliar error, draft the skeleton of a node and save you real hours of drudgery. What it cannot do is see that your camera is mounted upside down, know that your gripper closes a fraction late, or tell that the coordinate convention in its answer does not match your hardware. It also tends to recommend whatever has been written about most, which is why beginners are so often handed a heavyweight setup for a robot that needed a script. The deeper problem is that the year's value is not the code produced. It is the judgement built by being wrong repeatedly with a machine that does not argue back. An assistant that hands you working code removes exactly the failures the year exists to give you. Use it to go faster through the known parts, never to skip the confusing ones.

Does finishing twelve months make you employable?

Partly, but not the way you think. Twelve honest months will not make you competitive against a robotics graduate on theory, and pretending otherwise sets up a painful interview. What twelve months can produce is the thing hiring managers are actually short of: someone who has debugged a physical system and can describe the process without hand-waving. That is a narrower claim and a stronger one. A public repository containing one robot that does one task, with notes on what failed and how the cause was isolated, is read more carefully than a list of courses completed. The honest limits deserve stating. Roles that gate on formal mathematics — control design for aircraft, estimation research, optimisation-heavy planning — are genuinely hard to reach this way, and a degree is a shortcut through material that resists self-teaching. The far larger number of roles building, integrating and debugging robot systems are reachable, and they are reached with evidence rather than credentials. Aim the year at one demonstrable thing rather than at broad coverage.

How do you decide what to do in month one?

Pick the smallest thing that ends with something moving on your screen, and do only that. Concretely: install one simulator, load a robot that already exists in it, and write a program that makes that robot drive forward and stop before it hits something. Nothing else in month one. Not the framework question, not the hardware question, not the language debate, because none of those can be answered usefully before you have seen a robot respond to code you wrote. After that first moving thing exists, the decisions get easy, because each one attaches to a problem you now have. When two programs need to share data, you will care about messaging. When the robot wobbles, you will care about control. When you want it to happen on a desk rather than a screen, you will care about hardware. The rule for the whole year is the same rule: study whatever is currently stopping your robot. If nothing is stopping it, the project is too small, so make it harder rather than reaching for another syllabus.

Decide by situation, not by ambition:

• If you have never programmed -> a quarter on Python alone, because every later failure needs a layer you can rule out.
• If you already ship software -> Linux, coordinate frames and timing first, because those are the three gaps your job left.
• If you want a robotics job -> a ROS 2-led year after your first moving project, because it is the vocabulary of the people hiring.
• If your motivation dies without a physical object -> a cheap kit in month one, because a finished year beats an optimal one.
• If your robot is one computer running Python beside compiled control code -> a middleware built for that boundary, because that boundary eats weeks.
• If you have already started and stopped twice -> a structured course, because the missing ingredient is a deadline, not material.

When the framework question finally arrives, 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 whichever loses on fewest, with no scoring involved. If your year is heading towards mixed-language code on a single machine, star HORUS on GitHub so it is in your list when you start building.