Best Robotics Middleware for Teaching and Classroom Use

For a full-term robotics course the best teaching middleware is usually ROS 2; for a short module or a first programming course, something smaller wins. The deciding factor is what students leave with: ROS 2 teaches a vocabulary they meet again in industry, and setup cost is the price. That flips on a short module or shared machines, where a lean stack such as HORUS gets more robots moving. The rest of this post is for whoever has to pick the stack before the term starts and then support it alone for ten weeks.

Week one is installation. Week two is still installation, for the four students whose laptops did something different, plus the two on a machine you have never seen before. By week three you have a room where half the class has a working environment and half is watching somebody else's screen, and you are the only person who can fix either. Nobody signed up to teach package managers. The other version of this is quieter and worse: everything installs, the robot moves in the first lab, and then the assignment that was supposed to be about a control loop turns into an assignment about build errors. Students conclude they are bad at robotics. They are not. They are bad at a build tool, which is a different skill and one nobody taught them. Meanwhile you have six robots for thirty people, a lab that only exists for two hours a week, and a term that ends whether or not the projects work. The choice made before the term starts decides how much of that term you spend on your actual subject.

What is the best robotics middleware for teaching a class?

For a term-long course aimed at students who will work in robotics afterwards, ROS 2 is the best teaching stack, and the reason is not technical. The reason is that the vocabulary transfers. A student who has argued with topics, nodes, message types and launch files has met the words they will meet in a job advert, a research group and a codebase somebody else wrote. No leaner option gives them that, and pretending otherwise does them a disservice. The verdict changes on two conditions, and both are common. If the course is short, so that setup would eat a meaningful part of it, the standard stack costs more than it teaches. If the students bring their own laptops rather than using managed lab machines, the same is true, because you will spend the term as an unpaid support desk. In both cases the right answer is either a prepared image that hides the setup entirely, or a smaller stack whose whole surface fits in one lecture. Choose by term length and machine control, not by which tool is most respected.

What is robotics middleware, explained the way you would explain it to a student?

Middleware is the postal service inside a robot. One program reads the camera, another decides where to go, a third drives the wheels, and middleware is what carries messages between them and decides what happens when one of them is slow or has crashed. That framing is worth giving in the first lecture, because it makes the rest of the course make sense. Students who never get it treat the middleware as magic incantations to be copied, and then cannot debug anything. Alongside the postal service, most middleware ships three extra things: a way to start all the programs at once, a way to watch messages flowing while the robot runs, and a catalogue of components other people wrote. That last one is why the standard stack dominates teaching. It is also worth being honest in class that the postal service itself is small, roughly a lecture's worth of ideas, and the rest of the difficulty is the packaging around it. Students who know which difficulty they are fighting stop blaming themselves for the wrong one.

What actually goes wrong in a robotics course, and in which week?

Three things go wrong, and they arrive on a predictable schedule. Week one is environments: thirty machines, thirty configurations, and a handful of students who cannot get past the install and quietly decide the subject is not for them. Week four is the shared robot: six machines, thirty students, a booking sheet, and groups who only get hardware time after their code was already written blind. Week eight is integration, when three student components that each worked alone are connected for the first time and none of them agree on units, timing or who is allowed to command the motors. The week-eight failure is the valuable one and the one most courses run out of time to reach. Structure the term so it happens in week five instead, when there is still time to learn from it. The week-one failure is the one to eliminate entirely, because it teaches nothing and it is the point at which you lose students. Every choice in this post is really about moving difficulty from week one to week eight.

What are the actual options for a teaching stack?

There are six options that courses actually pick between, and they suit different lessons. First, ROS 2 as a full distribution: the vocabulary students will meet in industry, a large catalogue of drivers and packages, and a setup cost that lands on you. Second, ROS 2 delivered as a prepared container or virtual machine image, which is the same lessons with week one deleted. Third, a lean single-machine middleware such as HORUS, an open-source project where Rust, Python and C++ share the same shared-memory ring buffers so messages are not serialised between processes on one computer, which fits a course teaching timing and mixed languages rather than the wider ecosystem. Fourth, a simulator with its own scripting layer, for classes with no hardware budget where every student needs a robot at home. Fifth, a general message library, for advanced students whose lesson is how middleware works underneath. Sixth, no middleware at all: one program, one language, threads and a queue, which is the honest answer for an introductory course.

Which option suits which kind of course?

The option that fits is the one whose assumptions match your students, your machines and the length of your term.

Most good courses use two rows: a simulator for everyone at home, and one shared stack on the robots in the lab.

What should you choose if you are one instructor with no teaching assistant?

Choose whatever you can hand out as a single prepared image, because your scarcest resource is not lab time or hardware, it is your own attention during week one. One instructor supporting thirty environments is a bottleneck that no amount of enthusiasm survives, and every hour spent on somebody's graphics driver is an hour not spent on the subject you were hired to teach. A prepared container or virtual machine changes the shape of the problem: you debug the environment once, in August, on your own schedule, and the class starts on the robot. This matters more than which stack is inside the image, which is why it belongs before the ranking rather than after it. Two practical notes. Make the image rebuildable by writing down how it was made, or next year's version of you inherits a black box. And test it on the worst laptop you can find, not your own, because the student with an old machine and an unfamiliar operating system is the student who quietly disappears in week three.

What if the students only have laptops and the class shares a few robots?

Teach in simulation as the default and treat the physical robots as a scheduled event rather than the everyday environment. Shared hardware fails in a specific way: groups write code blind all week, get their forty minutes with the robot, spend thirty of them discovering a units mistake, and leave with nothing learned about the actual lesson. A simulator every student runs at home removes that entirely, because the debugging happens where the debugging is cheap, and hardware time becomes what it should be, the place you discover what simulation lied about. Be honest with students about that gap rather than hiding it. The floor is slipperier, the camera is noisier, the battery sags, and the arm that was exactly right in simulation is a little late in the room. If your students have no robot at all, learning the standard stack without owning hardware is more workable than most people assume, and it changes what a course can promise on a small budget.

What if the course is ten weeks long?

Ten weeks is too short to teach the standard stack and a subject, so pick one and be deliberate about which. If the course exists to produce students who can join a robotics team, spend the term on the standard stack, hand out a prepared image so week one is not lost, and accept that you will cover fewer robotics ideas than you wanted. If the course exists to teach control, perception or the ideas behind autonomy, use the smallest thing that moves messages and spend the recovered weeks on the subject. What fails in ten weeks is trying to do both, which produces students who have half a vocabulary and half a control loop and cannot use either. Work backwards from the assessment. If the final artefact is a working robot behaviour, protect the weeks it needs and cut setup ruthlessly. If the final artefact is a report, you can afford more tooling. One more thing worth its cost in a short term: reach a moving robot in the first session, however trivial the motion.

What if the students have only ever written Python?

Teach in Python and do not apologise for it, because a student who sees a robot move in the first session stays and a student who fights a compiler in week one leaves. Python is enough for perception glue, for state machines, for most of what an undergraduate course assesses, and for every idea that matters in an introductory syllabus. The moment to introduce a compiled language is when the lesson itself is timing, which means a control loop that must run steadily while something heavier is also running, and a robot that stutters when it does not. That lesson lands far better when students have felt the problem than when they are told it exists. Courses that go there need a stack where a Python component and a compiled component can exchange messages without students hand-writing a bridge, which is an interesting engineering exercise and a terrible use of week nine. If you want the gentler on-ramp instead, whether a simpler version of the standard stack exists is a fair question with a real answer.

What do you give up by teaching a smaller stack than industry uses?

You give up vocabulary, and you should say so out loud in the first lecture. A student taught on a lean stack understands publishers, subscribers, message types, timing and integration, but has not typed the specific commands, has not fought the specific build tool, and cannot claim the specific line on a CV that recruiters filter on. That is a real cost in a course whose purpose is employment, and no amount of arguing that concepts transfer makes a keyword search see them. You also give up the catalogue, which in teaching terms means the ready-made mapping, navigation and simulation pieces that let a class build something impressive in a fortnight. Losing those changes what a capstone can attempt. What you do not give up is the understanding, which is the part that survives the tool. Students who learned the ideas cleanly pick up the standard stack in a couple of weeks when they need it. Students who learned incantations without the ideas are stuck the moment the tutorial ends.

When is ROS 2 the better choice?

ROS 2 is the better choice for any course whose graduates are meant to be employable in robotics, and that is most university courses. If your students will apply for jobs and internships where the advert names the standard stack, teach the standard stack, because the vocabulary is a substantial part of what the degree is selling. It is also the better choice whenever the course builds something ambitious quickly: a mapping and navigation project is achievable in a term only because the pieces already exist. Any course with managed lab machines, where you control the environment and setup is a one-time cost you pay in the holidays, should use it. And any course spanning several computers by design, since HORUS is a single-machine middleware and shared memory stops at the edge of the computer. The honest summary is that the standard stack loses only where setup cost is a real fraction of the term or where the machines are not yours to control. Everywhere else, the ecosystem is the lesson.

Is teaching anything other than the industry standard doing students a disservice?

No, and here is why: the thing that transfers between robotics jobs is not a command set, it is the ability to reason about a system made of parts that fail independently. A student who has genuinely understood why one component must not block another, why timing drifts, why two programs disagree about units, and what happens when the process holding the motors dies mid-motion, has the skill an employer is actually short of. Command sets are learned in a fortnight by anyone with that understanding. The reverse is not true, and every robotics team has met the graduate who can recite the tutorials and cannot debug anything the tutorials did not cover. That said, the disservice is real if you teach the concepts and never mention the standard, so do both: teach clearly on whatever stack fits your term, then spend two sessions near the end reading a real codebase in the industry-standard one. Recognition is cheap to teach and it is most of what a first interview tests.

Is setup time really the reason students fall behind?

Partly, but not the way you think. Setup is what students blame and what instructors count, but the actual mechanism is confidence rather than hours. A student who spends three evenings failing to install something forms a belief about themselves, and that belief, not the lost time, is what makes them stop asking questions and eventually stop attending. The same three evenings spent failing at a control loop produce the opposite effect, because the failure is legibly about the subject and everybody in the room is having it too. That is why a prepared image is worth more than the hours it saves. It moves the first failure from a place where students feel stupid to a place where they feel like engineers. The second mechanism is invisible and worse: students who cannot run the code stop reading it. They copy from a teammate whose environment works, submit something they do not understand, and pass. Nothing in your marking scheme catches that, and it compounds every term.

How do you choose before the term starts?

Answer four questions in this order and the choice makes itself. First, how many weeks do you have, counting from the first session where students touch code, not from the first lecture. Second, do you control the machines, or do students bring laptops you have never seen. Third, what is the final assessment: a working robot behaviour, a written analysis, or a demonstration. Fourth, what will your students do next, meaning industry jobs, research, or a different field entirely. A long term plus managed machines plus an industry destination is the standard stack, and the decision is done. A short term plus student laptops is a prepared image or a lean stack, whichever you can maintain alone. A written assessment gives you room for tooling that a robot demonstration does not. If two answers conflict, weight the destination hardest for degree courses and the term length hardest for everything else. Then run the whole first lab yourself, on a fresh machine, in August. That rehearsal finds more problems than any amount of comparison.

A short version, by situation:

• If you teach a term-long degree course on managed lab machines -> ROS 2, because the vocabulary is a large part of what the degree is selling.
• If you teach a ten-week module and students bring their own laptops -> a prepared image or a lean stack, because week one decides who stays.
• If you have no hardware budget -> a simulator every student runs at home, because a robot that cannot be broken beats a robot nobody can book.
• If the lesson is timing and the class mixes Python with a compiled language -> a stack where both read the same buffers, because a hand-written bridge is not the lesson.
• If this is a first programming course with a robot attached -> no middleware, because architecture is a distraction before students can make a wheel turn.

When you want to compare options rather than defend one, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. For teaching, setup effort and ecosystem size decide almost everything, and licence quietly matters when students want to publish their work. If you are also choosing the robots, whether hardware or software should be decided first is the companion question.

HORUS is open source under Apache-2.0 and the repository is linked below. Star it so it is in your list when you start building.