Should You Learn Robotics or Wait for Foundation Models to Solve It?

Learn robotics now, because a foundation model is absorbing the perception and grasping code, not the timed control layer that sits underneath it. The skills that take months — keeping a control loop on time, knowing what ROS 2 or HORUS does underneath your program — are the ones no model removes. That verdict flips only if you plan to buy finished robots rather than build them. The rest of this post is for someone fluent in models who is deciding whether a year spent learning robotics is a year wasted.

You have been watching the videos, and they are doing something to your judgement. An arm you could not have programmed in a decade folds a shirt, and the caption says the whole thing was learned from demonstrations. Somebody in your feed says the old stack is legacy and anyone starting a robotics course now is training for a job that will not exist. So you open a tutorial, get four hours into an install that fights you, and close it, because a voice says this will be obsolete before you finish. Meanwhile you cannot tell from any demonstration what was actually autonomous, how many takes it took, or whether a person was holding a controller off camera. The forums are no help: half of them are people who have never touched a motor predicting the end of the field, and the other half are people who have never trained a model insisting nothing has changed. You have shipped real software. You know how to tell when a claim is doing work and when it is doing marketing. Here, you cannot tell, and that is what is stopping you.

Should I start learning robotics now, or wait until foundation models are better?

Start now, because the part you would be waiting out is not the part being automated. Two jobs sit inside every robot and from outside they look like one thing. The first decides what should happen next — pick up that cup, cross to the kitchen, put the shirt in the drawer — and that job is genuinely being eaten by models, faster than most people expected. The second job runs without pause underneath: read where the machine is, compare that with where it should be, move a little closer, and refuse anything that would drive an elbow through a table. That second job has a deadline on every cycle, and a component that answers whenever it answers cannot hold a deadline. Learning robotics means learning the second job plus the wiring that joins the two, and no research programme is aimed at removing either. There is also an asymmetry worth naming. If you learn this and models advance faster than expected, you spent months understanding machines that now do more for you. If you wait and they do not, you are years behind people who did not.

What is a robot foundation model in plain terms?

A robot foundation model is a model trained on recordings of machines performing physical tasks, which outputs motion rather than text. The chat models you already work with were trained on an enormous pile of text that was already lying around. Nothing equivalent is lying around for bodies. Every hour of robot training data has to be produced by somebody moving a real machine, or by a simulator whose physics only approximates the real thing, and each recording is tied to that machine's particular arm lengths, gripper and camera placement. This is why progress here looks lumpy: a group collects a large dataset on one robot family, publishes something that folds laundry beautifully on that family, and the result does not simply arrive on your desk. What these models genuinely do well is the part hand-written code was always bad at — finding the mug among clutter, adapting a grasp to a shape nobody enumerated in advance. What they do not do is promise an answer inside a fixed window, or explain afterwards why the gripper closed early. If the category is new to you, the plain description of robot foundation models is worth the detour first.

What are my actual options if I start learning now?

Six paths cover nearly everyone, and they differ mostly in how much you build versus how much is handed to you. The first is learning ROS 2, the large ecosystem: drivers, navigation, arm planning, visualisation, and a name that appears in job postings, in exchange for a stack you install, learn and keep running. The second is a lean middleware such as HORUS under code you write yourself — open source under Apache-2.0, for Rust, Python and C++, where all three languages share the same shared-memory ring buffers, so a Python process holding a model and a compiled control loop are not serialising camera frames between them on one machine; that path hands you no navigation, no drivers and no models, and leaves the control code to you. The third is one Python script talking straight to a motor driver, which is the honest answer for a first machine. The fourth is a vendor SDK for one specific arm. The fifth is simulation with no hardware, which covers most of a first year for the price of a laptop. The sixth is waiting, which is a real choice for some readers.

How do those paths compare side by side?

Choose by what you refuse to build yourself and what you want to be true in a year, not by which path sounds most serious. Read the last two columns first, and treat the middle column as a warning about the weeks that pass before anything moves. These rows are not exclusive, and almost everyone who gets somewhere mixes them: a simulator early, a vendor SDK for the arm, their own code holding the middle. Assume you will change your mind at least once, which costs very little in the first month and a great deal in the second year, so favour the row that lets you find out fastest. The last row is on the list because waiting is a defensible choice with a real audience, and leaving it off would be dishonest. What no row buys you is a shortcut past the afternoon when a machine does something surprising and you have to work out why.

Does this change if I am a machine learning engineer rather than a hardware person?

It changes what will surprise you, not what you have to learn. Coming from models you already own the two habits that matter most: you write Python quickly, and you are comfortable depending on a component that is confidently wrong some of the time. What catches people from this direction is that the physical layer has no held-out split. There is no number telling you whether the grasp generalises. There is a table, a cup, and whether the cup is still standing. Retries are not free either — a bad run costs a knocked-over glass or a stripped gear, not a slightly worse score — so the instinct to fix things by running the experiment again works against you here. The second surprise is how much of the work is unglamorous wiring: getting the camera process and the control process to agree about what time it is and what they are looking at. Roboticists arriving from the other direction hit the opposite wall, and neither group is behind the other. If you want a concrete first target rather than a syllabus, what to build first in embodied AI is the shorter road.

What hardware do I need to start, and can I start with none?

None for the first months, then the cheapest machine that moves something real. A simulator and a laptop will teach you timing, coordinate frames, how a control loop is structured, and how a program behaves when a sensor stops reporting, and none of that knowledge is thrown away when hardware arrives. What simulation will not teach you is the mechanical half: the gripper that slips on glass, the cable that catches at the end of travel, the motor that warms up and quietly drifts. When those become the interesting failures, buy something. A small arm or a wheeled base with wheel encoders is enough for years of learning. If you want to run a model on the machine rather than in a data centre, budget for a second computer, because a machine running a model and a control loop together will starve the loop first, and the loop is the part with the deadline. A small board next to the motors is a separate purchase and a separate skill. The practical route through all of this is set out in learning robotics without buying a robot.

How long before I can build something that actually works?

A weekend to make something move, and several months before you would leave it running with a stranger in the room. The weekend version is real and worth having: a motor spins, a wheel turns, a camera frame reaches your code, and the abstraction stops being abstract. What takes the months afterwards is everything the weekend skipped. What the machine does when a sensor stops reporting. What it does when a grasp fails halfway. Where the arm goes when your program crashes mid-motion. Whether you can tell, from a log, why yesterday's run went differently from today's. That is the actual curriculum, and no framework choice shortens it much. What does shorten it is picking one small machine and one small task and refusing to change either until the task works ten times in a row without you touching anything. People who keep restarting with better hardware and better goals are still on their first week after a year, and they usually call it a tooling problem rather than a scope problem.

What do I already know that transfers, and what do I have to learn from scratch?

Enough Python to write a function with honest preconditions transfers directly, and that is most of the entry requirement. Nothing here demands control theory or kinematics on day one, and people telling you otherwise are describing a graduate course, not a first project. Three things do have to be learned properly. The first is why the loop underneath cannot wait, which is the single idea separating people who build something safe from people who build something that worked once on camera; the explanation of control loops and their timing is the prerequisite, not the framework documentation. The second is coordinate frames, because every bug where the arm moves in the wrong direction lives there, and it is duller than you want it to be. The third is knowing where an interpreted language is fine and where it is not, since your decision code will be Python and your loop may not be able to be. Mathematics beyond that arrives when a project needs it, not before.

What does it look like when someone learns robotics the fast way and it goes wrong?

The classic failure is a machine that works once on camera and never again, and the cause is almost never the model. It goes like this. The script computes a sequence of joint positions and sends them, which works because the object was where it was during testing. Nothing checks reality between one position and the next, so the day the cup is slightly left, the gripper closes on air and the script reports success. Nothing bounds the path, so a perfectly reasonable sequence sends the elbow into a monitor. When a step fails there is no defined state to return to, so the next run starts from somewhere the code has never seen. And there is no log worth reading, so every debugging session is somebody staring at the machine hoping to catch the moment. Each of these is a missing habit rather than a missing library, which is why buying a better framework does not fix it. The fix is boring: named actions with preconditions, a known safe state, and a log that says what each part believed at the time.

What do I give up by learning this now instead of waiting?

You give up months, and you give up arriving later with better tools than exist today. That trade deserves to be stated without spin. Some of the code you write this year will be made unnecessary by something released next year, particularly the hand-tuned perception and the grasp heuristics, which is exactly where models are strongest. The tutorials will be better later. The hardware will be cheaper later. If your current work is well paid and intellectually full, the opportunity cost of a serious side project is real and nobody should pretend otherwise. What you get in exchange is a class of understanding that does not depreciate: how a machine behaves at the boundary between software and physics, why a system that passes every test still fails in a kitchen, and what to check first when it does. That understanding is also what lets you evaluate the next demonstration video honestly, which is a skill the people arguing about this in your feed conspicuously lack. Read why a language model can write an app but cannot pick up a cup if you want the mechanism behind that gap.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the ecosystem is the point rather than an overhead. If your machine has to build a map of a building and cross it, plan an arm path around obstacles, or talk to a sensor whose vendor ships ROS 2 support and nothing else, the packages waiting there represent years of work you are not going to redo. If you want a robotics job, ROS 2 is named in the postings and a portfolio built on it is legible to the person reading your application. In a research group it is how your results get reproduced by somebody else, which is not a technical argument and is usually the deciding one anyway. When more than one computer is involved, ROS 2 answers questions you would otherwise spend a month answering badly. HORUS is not the answer in those situations and does not pretend to be: no navigation, no mapping, no driver library, validated in simulation rather than across shipped fleets, and no ecosystem to fall back on when you get stuck at midnight.

Will better models eventually make this knowledge unnecessary?

No, and here is why: the layer underneath is not there because the deciding layer is insufficiently clever. It is there because something has to be on time, every cycle, with a bounded worst case, and no amount of model improvement softens that requirement. A perfect planner still needs something running continuously that holds the joint limit, notices the person who stepped into the workspace between one decision and the next, and brings the machine to a stop when a reading stops arriving. Those are guarantees rather than decisions, and guarantees are properties of code somebody can read line by line and reason about. The machine also has to behave sensibly when the model is unreachable, which is a Tuesday rather than an edge case. What better models genuinely change is how much perception code you write yourself, how loosely a request can be phrased, and how many grasps work on shapes you never tested. Those are real and significant improvements. They are improvements to a different layer than the one you would be learning.

Is this the same argument people made about self-driving cars?

Partly, but not the way you think. The similarity is genuine: a demonstration arrives, everyone extrapolates a straight line from it, and the last part of the problem turns out to hold most of the difficulty. The difference is that driving is one task with one body and enormous economic pressure behind it, and it still took far longer than the confident predictions. Robotics is thousands of tasks across bodies that share almost nothing mechanically, so the same slow tail applies separately in more places. But the comparison is also used dishonestly in the other direction, as a reason nothing will ever ship, and that is wrong too. Driving assistance did arrive and is genuinely useful, just narrower than promised and heavily constrained by code written by careful people. Expect the same shape here: models that make specific tasks work far better than hand-written code ever did, wrapped in a great deal of ordinary engineering that decides whether the result is trustworthy. The engineering half is the half you would be learning.

How do I decide what to do this month?

Decide by naming the outcome you want in a year, because that settles it faster than any comparison of frameworks. If the honest answer is that you want to work in robotics, the ecosystem with the job postings wins and the argument is over. If the answer is that you want to build one specific machine for yourself, pick the smallest path that gets it moving and ignore everything else. If the answer is that you are curious and would like to know whether you enjoy this, spend nothing: a simulator, a control loop you wrote, and one task that works ten times in a row. Then check whether your interest is really in the deciding layer or in the moving layer, because they are different careers wearing the same word. People fascinated by planning and language should read how robots decide what to do next before choosing hardware at all. Last, set a date to reassess rather than reassessing continuously, because the field will keep producing videos and every one of them will make you want to restart the decision.

Take the line that matches your situation:

• If you want a robotics job in a year -> learn ROS 2, because the postings name it and the portfolio is legible to whoever reads your application.
• If you want to build one machine for yourself -> the smallest stack that moves it, because motion this month teaches more than a survey of options.
• If you are curious but uncommitted -> a simulator and your own control loop, because it costs nothing and answers the real question.
• If you only ever intend to buy finished robots -> wait, because the products will arrive and you do not need the internals.
• If a model process and a compiled loop must share one machine -> a lean middleware under your own code, because that sharing is the whole problem.

The HORUS Fit Framework is the checklist behind those lines, and none of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every candidate on all five, and let the axis you cannot compromise on decide.

Whatever the models learn to do next, something underneath still has to be on time. HORUS is open source under Apache-2.0 at github.com/softmata/horus. Star it so it is in your list when you start building.