Is ROS 2 the Right Choice for a University Capstone?

Yes for most university capstones, ROS 2 is the right choice; a smaller single-machine stack or plain Python wins only in narrow cases. A capstone is graded on one idea, and ROS 2 already contains the drivers, simulator and tooling that idea has to stand on. That flips when the robot is a single board running one timing-critical loop, where something like HORUS or no middleware fits better. The rest of this post is for a team in week one, with a fixed demonstration date, deciding whether to install the standard stack or avoid it.

You have a project title, four names on a group form and one semester. Someone senior said to use ROS 2. Someone in the year above said ROS 2 ate their semester. The tutorial you found installs for most of an evening and then fails on a step that assumes a version of Linux nobody on the team is running. One person eventually gets it working, cannot say how, and their laptop quietly becomes the laptop that everything now depends on. Meanwhile the hardware order has not arrived, the lab is booked by another group until Thursday, and half the team can only work after eight in the evening. The group chat fills with error messages that mean nothing to anybody yet, and every hour spent on them feels stolen from the actual project. Underneath all of it sits a fear nobody says out loud: that a tool decision made in week one, by whoever installed something first, will be the reason the machine does not move on the day it is marked.

Should our capstone team build on ROS 2?

Build on ROS 2 if your project depends on work other people have already finished, which describes most capstones. The graded idea is usually one thing — an arm that sorts parts by colour, a rover that finds a door, a drone that holds a line — and underneath it sits a pile of work nobody will grade: reading a lidar, starting eight programs in the right order, seeing what the machine believed while it drove, replaying a run at a desk after the lab has closed. ROS 2 hands you that pile on day one. A team that writes the pile themselves spends the semester on plumbing and shows a rough version of the idea in the final fortnight. The answer changes when the project has almost no pile. A balancing machine, a haptic handle, a motor controller study, a project whose whole content is one loop on one board: there the framework adds ceremony around code you were always going to write by hand, and the setup alone can cost more than the parts it saves you. Work out which of those two shapes your project has before arguing about anything else.

What is ROS 2, in plain terms, for a team that has never used it?

ROS 2 is four separate things that arrive as one download, and only two of them are what people usually mean by the name. The first is message passing: how the program holding the camera tells the program holding the wheels what it saw. The second is process management: starting many programs together with the right settings, and stopping all of them when somebody hits the switch. The third is tooling — watching messages while the machine runs, recording a run so it can be replayed at a desk, drawing what the machine believes about the room. The fourth, and by far the largest, is the catalogue: drivers for real sensors, mapping, navigation, arm planners, simulators that speak the same message types. The catalogue is the actual product and the reason ROS 2 dominates university labs. Despite the name, ROS 2 is not an operating system; it runs on top of Linux and is fussy about which version. Every capstone needs the first two. Almost every capstone wants the recording part of the third. Whether you need the fourth is the entire decision.

What do capstone teams build first, and why does it stop working?

Almost every team starts with one Python script that reads a sensor and drives a motor, which is exactly the right first move. That script then fails in four recognisable ways, usually in the same order. A sensor vendor ships a driver in C++ only, and the script cannot reach it. The image processing takes long enough that the wheels stutter while it runs, and nobody can explain why the machine drives in a way the code does not describe. One part crashes and takes down the part that was supposed to stop the motors, which ends a lab session early and occasionally ends a gearbox. And four people editing one file produce a version that works on one laptop for reasons nobody can reconstruct. Teams that push through all four without changing anything end up writing a middleware by accident: a socket here, a shared file there, a startup script only one person dares to touch. That costs more than choosing one deliberately, and none of the tools come along with it. No recording, no way to watch messages, nothing to put in front of a supervisor when the demonstration misbehaves.

What are the actual alternatives to ROS 2 for a capstone project?

There are six honest options, and most reading lists blur several of them together. First, ROS 2 as a full distribution: messaging, launching, tooling and the catalogue in one decision and one long install. Second, ROS 2 used narrowly — the two or three packages you genuinely open and nothing else — which is a real strategy that nobody teaches. Third, a single-machine real-time middleware such as HORUS, where Rust, Python and C++ read the same shared-memory ring buffers so messages are not serialised between processes on that computer; that suits a robot living entirely on one board with more than one language in it, and the licence is Apache-2.0. Fourth, a general message library, which delivers bytes and leaves every message shape, restart rule and debugging tool to you. Fifth, the kit vendor's own SDK, the shortest route to a moving machine and the hardest thing to leave in week ten. Sixth, no middleware at all: one program, one language, threads and a queue. Most capstones end up running two of these at once, which is normal rather than a mistake.

Which option fits which kind of capstone team?

The option that fits is the one whose assumptions match the machine on your bench rather than the machine in your proposal.

Two rows at once is common and usually correct: a vendor SDK underneath because you were handed the machine, something smaller above it for the parts you write.

What if our team is mostly mechanical and electrical students?

Choose the option with the largest archive of strangers who have already had your problem, and that is ROS 2 by a distance. A team whose software experience is one programming module will not be defeated by interesting problems. They will be defeated by boring ones: a driver that will not build, a permission on a serial port, a message arriving with two axes swapped, programs starting in the wrong order. Every one of those has been solved in public, and the size of that archive matters more to a beginner than any property of the software underneath. Your demonstrators have probably debugged the same errors, which no smaller project can offer. The cost is real: the framework itself takes weeks to become comfortable with, and those weeks come out of your semester rather than out of nowhere. Read an honest account of how long ROS 2 takes to learn before assuming that learning happens in the background. If the answer worries you, the correct response is to use fewer parts of the ecosystem, not to leave it.

What if the department hands us hardware we did not choose?

Start from what the hardware already speaks, because a driver you have to write yourself is a month nobody budgeted for. In week one, take the parts list — every sensor, the motor controllers, the on-board computer, the camera — and search each item by name. What comes back is one of three things: a maintained ROS 2 driver, a vendor SDK in one language, or a forum thread from somebody still waiting for an answer. That result settles more than any framework comparison. If everything on the list has a ROS 2 driver, stop deliberating and install. If the machine arrived with a C++ SDK and your team writes Python, your real question is how those two talk to each other on one board, which is a middleware question and a serious one. And if the timing-critical part lives on a microcontroller rather than the main computer, much of this decision evaporates, because the part that must never be late is in firmware and the computer above it can afford to be relaxed about how messages travel.

What if the demonstration is at the end of the semester and nothing is installed?

Freeze the stack in week two and never revisit it, because a mid-semester migration consumes exactly the weeks the report needs. The version of this project that ends badly is always identical: somebody reads in week nine that a different tool would have been better, the team switches foundations, and the demonstration becomes a video of the old version. Budget backwards instead. Find the last date the machine has to move, subtract writing time, subtract a fortnight for hardware that arrives broken or late, and whatever remains is your genuine build window. Pick a stack that fits inside it and stop evaluating. What decides capstone demonstrations is never the middleware anyway. It is whether the machine stops safely when something goes wrong, whether you can restart it in front of an audience without apologising to a laptop, whether an observer can tell what the machine is trying to do, and whether you recorded a good run for the moment the live one refuses to cooperate.

What if the team only knows Python from coursework?

Stay in Python and leave it only for the one part that cannot stay, which is almost always a single control loop. Python covers sensor reading, coordination, planning at human speeds, logging, dashboards and most of a capstone, and a team fluent in it will build more machine per evening than the same team learning C++ in parallel. Python stops being enough at a recognisable moment: the loop holding a wheel speed or keeping an arm from hitting the table misses its moment because the language paused to tidy memory, and the machine twitches in a way your logic does not explain. That is the point to move one part into a compiled language, not the whole robot. It is also the case where a middleware that lets Python and a compiled language read the same buffers earns its place, because the rewritten piece stays small and everything else stays where it already is. If your project is heading there, what actually happens to Python underneath a control loop is worth reading before the deadline arrives.

What do we give up by choosing ROS 2?

You give up weeks, and weeks are the only currency a capstone has. The install is long, the build tool has opinions, and the first fortnight produces error messages that teach you nothing about robots. You give up some ability to explain your own system, because a message that does not arrive can be your bug, a setting nobody chose deliberately, or the network — and telling those apart is a skill the semester does not leave room to develop. You give up freedom on the campus network, where the default discovery behaviour meets a managed wireless network and does surprising things; why that happens on normal Wi-Fi is worth ten minutes before demonstration day. You give up headroom on a small on-board computer, since the framework wants memory and processor time your own code also wants. And you accept a version treadmill: distributions have end dates, and a project pinned to an old one ages faster than the report suggests.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever your project's value sits on top of work other people finished. A mobile base that must map a corridor and navigate it: ROS 2, without argument, because writing that yourself is a multi-year project rather than a semester. An arm using an established motion planner. Anything you must show in a simulator that already speaks the same message types. Anything the next cohort inherits, because the standard ecosystem is the one they will arrive knowing. Anything that spans two computers by design — the machine plus a workstation carrying the heavy perception — because HORUS is a single-machine middleware and shared memory stops at the edge of one computer. Anything where your supervisor and demonstrators can only answer questions about one ecosystem, which is a practical constraint rather than a technical one and correctly decides plenty of capstones. And anything whose loops run at rates where how messages travel simply does not matter, which describes a great many working machines.

Is ROS 2 too heavy for one semester?

No, and here is why: the weight people describe is nearly all setup, and setup is a one-off cost you can pay in week two while the hardware is still in a box. The daily experience afterwards is ordinary programming, and the parts that feel heavy — the build tool, the launch files, the package layout — are the parts a team touches least often once the shape settles. What actually sinks semesters is not weight but drift: four laptops configured four different ways, so the machine runs on one of them and that laptop must be in the room on demonstration day. The fix is unglamorous and takes an afternoon. Write the setup down as a script, check it into the repository, and make sure somebody who is not the author can run it on a blank machine. Teams who do that in week two stop losing evenings to environments in week ten. Teams who skip it pay for the framework twice, once to install and once every time somebody's laptop breaks.

Will we spend the semester on tooling instead of robotics?

Partly, but not the way you think. Some tooling time is unavoidable and is not wasted, because recording a run and replaying it at a desk is the difference between a bug that takes an afternoon of lab access and a bug that takes an hour at a kitchen table. That is robotics work wearing a dull costume. The waste is elsewhere, and it is specific: rebuilding your environment repeatedly because nobody wrote it down, chasing a message that never arrives because two machines disagree about a setting, and rewriting a driver in week eight because nobody searched for one in week one. None of those are inherent to any framework. They come from making decisions implicitly and discovering them later. The other real trap is reviewing generated code nobody understands, which is now common enough to deserve its own method — how to review robot code you did not write covers what to check before it drives anything.

How do we decide this in one meeting?

Write three lists on the whiteboard and let them make the decision for you. First, everything your team will not write itself: drivers, mapping, navigation, planning, simulation. Second, how many computers will run your code on demonstration day. Third, how many languages the machine will contain, counting anything a vendor forced on you. Then read the lists together. A long and specific first list means take the ecosystem and accept the upkeep, because rebuilding those parts is a bigger project than your project. A short first list plus one computer means take something small and spend the saved evenings on the machine. Several computers means you want a networked message layer whether or not you want the catalogue. More than one language on one computer is the case where sharing memory between languages pays for itself. When the lists disagree, weight the first one hardest: the catalogue is the only thing here that takes years to replace and the only one you cannot buy back with effort. For the wider version of this question, see how to choose a stack for a capstone.

A short version, by situation:

• If your project must map a corridor and navigate it -> ROS 2, because that work exists today and a semester is not long enough to repeat it.
• If you were handed a machine with a vendor SDK -> the SDK first, because the shortest path to motion protects every other week you have.
• If your robot is one board mixing a compiled loop with Python glue -> a single-machine middleware, because the bridge you would otherwise maintain never stops asking for attention.
• If the graded content is one control loop in one language -> no middleware yet, because adding one before the boundaries exist is cost without return.
• If your supervisor and demonstrators only know one ecosystem -> that ecosystem, because unanswerable questions cost weeks you do not have.

To compare tools rather than symptoms, 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 a capstone, ecosystem size and setup effort outrank the other three every time.

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.