Choosing a Robotics Stack for a University Capstone Project

For most university capstone projects ROS 2 is the right stack, with HORUS or a plain single-program approach making sense for narrower builds. A capstone has a fixed end date and a team still learning, so the stack that already contains drivers and a simulator usually wins. That flips when the robot is one board running one tight loop and the graded work is the loop itself. This post is for a team choosing in week one, before anyone has installed anything, with one semester and no way to restart.

Your team has a semester, a project name on a whiteboard and a robot that does not exist yet. Week one goes to picking tools, which feels productive and is not. Week three, someone gets the framework installed on their laptop, nobody else can reproduce it, and the person who managed it cannot explain how. By week five there are three programs that each work alone and none that work together, plus a group chat full of build errors that mean nothing to anyone yet. The hardware arrives late, the lab is booked by another group, and half the team can only work in the evenings. Someone suggests starting over in plain Python. Someone else says the supervisor expects the standard framework and that starting over looks bad in the report. Nobody wants to be the person who chose wrong in week one, so the decision gets made by whoever installed something first and got it working. What everyone is actually worried about is the same thing: the demo is on a fixed date, the report is due before it, and none of the tooling arguments will be worth a single mark.

What stack should a capstone team actually choose?

Choose the stack that already contains the parts your project is not about, and for most capstones that is ROS 2. A capstone is graded on one idea — an arm that sorts objects, a rover that maps a corridor, a drone that holds a line — and everything around that idea is scaffolding that has to exist before the graded part can be demonstrated at all. Sensor drivers. A way to start six programs together and stop them together. A simulator to work in when the hardware is in the lab and you are at home. A way to see what the robot believed while it was moving. A team that writes all of that themselves spends the semester on scaffolding and shows a rough version of the idea in week thirteen. The exception is a project whose whole subject is the low-level part: a balancing machine, a haptic handle, a motor controller, a study of timing. There the scaffolding is genuinely small, the graded content is the loop, and a large framework mostly adds ceremony around code the team was always going to write by hand.

What is a robotics stack, and which parts does a capstone actually need?

A robotics stack is four separate things that arrive as one download, and a capstone genuinely needs two of them. The first is message passing: the way one program tells another what the camera saw or how fast a wheel should turn. The second is process management: starting eight programs in the right order with the right settings, and stopping all of them when someone hits the switch. The third is tooling — watching messages while the robot runs, recording a run so it can be replayed at a desk at midnight, drawing what the robot believes about the room. The fourth is the catalogue: drivers, mapping, navigation, arm planners, a simulator that speaks the same message types. The catalogue is by far the largest and is the reason one framework dominates university labs. Every capstone needs the first two. Almost every capstone needs the recording part of the third, because a failure that happens in the lab and cannot be reproduced at a desk costs a week. Whether you need the fourth is the entire decision, and it is answerable in an afternoon.

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

Nearly every team starts with one Python script that reads a sensor and moves a motor, and that is the right first move. The script survives longer than anyone expects and then fails in four recognisable ways. A sensor vendor ships a driver in C++ only, and the script cannot reach it. The image handling takes long enough that the wheels stutter while it runs, so the robot drives in a way nobody intended and nobody can explain. One part crashes and takes down the part that was supposed to stop the motors, which is the failure that ends a lab session early and sometimes ends a gearbox. And four people editing one file produce a version that works on one laptop for reasons nobody can name. Teams that push through all four without changing anything build a private middleware by accident — a socket here, a shared file there, a launch script only one person can modify. 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 demo misbehaves.

What are the real options for a semester-long robot project?

There are six families, and the honest shortlist is shorter than the reading list your supervisor sent. First, ROS 2 as a full distribution, which brings message passing, launching, tooling and the catalogue as a single decision and a long install. Second, ROS 2 trimmed to the two or three packages you actually open, which is a real strategy and rarely taught. 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, which suits a robot living entirely on one board with a mix of languages, and which is open source under Apache-2.0. Fourth, a general message library of the ZeroMQ sort, where delivery is provided and every message shape, supervision rule and debugging tool is yours to define. Fifth, the kit or robot vendor's own SDK, which is the shortest route to something moving and the hardest thing to leave later. Sixth, no middleware at all: one program, one language, threads and a queue.

Which option fits which kind of capstone team?

The option that fits is the one whose assumptions match the robot on your bench, not the robot in your proposal.

Two rows at once is normal and often correct: the vendor SDK underneath because you were handed the robot, and something small above it for the parts you write.

What should we pick if nobody on the team has built a robot before?

Pick the option with the most strangers who have already had your problem, and that is ROS 2 almost every time. A first robot's hard problems are not interesting problems. They are a driver that will not build, a permission on a serial port, a message that arrives with the axes swapped, a launch file that starts things in the wrong order. Every one of those has been solved in public by someone else, and the size of that archive is worth more to a beginner than any property of the software underneath. Your teaching assistants have probably debugged the same errors, which is a resource no smaller project can match. The cost is real and worth naming: the framework itself takes weeks to become comfortable with, and those weeks come out of the semester. Read an honest account of how long ROS 2 takes to learn before you assume the learning happens in the background. If the answer frightens you, the fix is to use fewer parts of it, not to abandon the ecosystem entirely.

What if the department gives us a robot or a board we cannot change?

Start from what the hardware already speaks, because a driver you have to write yourself is a month nobody budgeted. In the first week, take the parts list — every sensor, every motor controller, the computer, the camera — and search each one by name. What comes back is either a maintained driver in some ecosystem, a vendor SDK in one language, or a forum thread from someone still asking. That result decides more than any comparison of frameworks. If everything on the list has a ROS 2 driver, the decision is made and you should stop deliberating. If the robot came with an SDK in C++ and your team writes Python, the question becomes how those two talk to each other, which is a middleware question and a real one. And if the tight timing 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 be relaxed about how messages move.

What if we have one semester and a fixed demo date?

Freeze the stack in week two and never revisit it, because a mid-semester migration eats exactly the weeks the report needs. The version of this project that ends badly is always the same: the team switches foundations in week nine because someone read that a different tool was better, and the demo becomes a video of the old version. Budget backwards instead. Work out the last date the robot has to move, subtract the time to write the report, subtract two weeks for hardware that arrives broken, and whatever is left is your actual build window. Then pick the stack that fits inside it and stop evaluating. What decides capstone demos is never the middleware. It is whether the robot stops safely when something goes wrong, whether you can restart it in front of an audience without a laptop apology, whether someone watching can tell what the robot is trying to do, and whether you have a recording of a good run for the moment the live one fails.

What if the team only really knows Python?

Stay in Python and leave it only for the one part that cannot stay, which is usually a single control loop. Python covers sensor reading, coordination, planning at human speeds, logging, dashboards and most of a capstone, and a team that knows it will build more robot per evening than the same team learning C++ in parallel. Python stops being enough at a recognisable moment: when 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 robot twitches in a way that has nothing to do with your logic. That is the point to move one part into a compiled language, not the whole robot. This is the case where a middleware in which Python and a compiled language read the same buffers earns its place, because the rewritten part is small and everything else stays where it is. If your project is heading that way, what actually happens to Python under a control loop is worth reading before the deadline arrives.

What do we give up by choosing the smaller option?

You give up the catalogue, and the catalogue is the real product. No lidar driver waiting for you, no mapping, no navigation, no arm planner, no simulator that already speaks your message types, no visualiser that finds your topics on its own. You give up the archive of strangers who solved your error in 2019, which for a first-time team is the difference between an evening and a week. You give up handover: a project on the standard stack can be picked up by the next cohort, and a project built on your own arrangement of parts is one only your team can run, which matters if the supervisor wants to keep it going. And you give up a small amount of legibility on a CV, since ROS 2 appears in job adverts and other names do not. That last one is worth less than students think — what employers read in a capstone repository is mostly evidence that you made hardware work and understood why it failed.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the value of your project comes from parts other people already built. A mobile base that must map a corridor and navigate it: ROS 2, without argument, because that stack exists today and writing it is a multi-year project rather than a semester. An arm using an established motion planner. Anything tested in a simulator that already speaks the same message types. Anything the next cohort inherits, because the standard stack is the one they will arrive knowing. Anything spanning two machines by design — a robot and a workstation doing the heavy perception — since HORUS is a single-machine middleware and shared memory stops at the edge of the computer. Anything where your supervisor and teaching assistants can only help with one ecosystem, which is a practical constraint and not a technical one, and which decides plenty of capstones correctly. And anything whose loops run at rates where how messages move simply does not matter, which describes a great many working robots.

Is a capstone too small to need middleware at all?

No, and here is why: the alternative is not "no middleware", it is a middleware your team wrote by accident and cannot debug in week eleven. Four people build four components. One of them must not stall when another is slow. One must keep running when another crashes, particularly the one that commands the motors. All four of you eventually want to record a run and replay it at a desk, because reproducing a lab failure on hardware takes an afternoon and reproducing it from a recording takes minutes. Every one of those is a middleware feature, and teams that avoid choosing one implement all of them badly across the semester. The accidental version fails in a specific way that capstones cannot afford: one person renames a field, another component keeps reading the old shape, nothing complains, and the robot does something inexplicable during the only lab session that week. Declared message types turn that into an error the moment the program starts. The real question is never whether you need message passing. It is only whether you need the catalogue attached to it.

Will our supervisor mark us down for not using ROS 2?

Partly, but not the way you think. Almost no rubric awards marks for a framework name, and a supervisor who reads the report carefully will grade the reasoning rather than the choice. What actually costs marks is being unable to explain the decision, or making it silently in week one and then defending it in week fourteen with reasons invented afterwards. Write a paragraph in week two saying what you picked and why, and that paragraph becomes a section of the report that grades well. There is a genuine risk that is not about marking: if your supervisor and the lab's teaching assistants only know one ecosystem, choosing outside it means your questions have nowhere to go, and that costs you real weeks even though it costs you no marks directly. Ask before you decide. A supervisor who says "use whatever you can defend" has given you permission that a supervisor who says "everyone here uses the standard stack" has not, and both answers are useful.

How do we decide this in one meeting?

Write three lists on the whiteboard and let them decide for you. First, what your team will not write itself: drivers, mapping, navigation, planning, simulation. Second, how many computers will be running your code on demo day. Third, how many languages the robot will contain, counting anything a vendor forced on you. Then read them together. A long, specific first list means take the ecosystem and accept the upkeep, because rebuilding those parts is a project larger than your project. A short first list plus one computer means take something small and spend the saved evenings on the robot. 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 earns its keep. If the lists disagree with each other, weight the first one hardest, because the catalogue is the only thing on this page that takes years to replace and the only one you cannot buy back with effort.

A short version, by situation:

• If your project is a mobile base that must map and navigate -> ROS 2, because that stack exists today and a semester is not long enough to write it.
• If you were handed a robot 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 needing 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 can only help with 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 rest. If an assistant is writing much of your code, how far a prompt actually gets you is the companion question to this one.

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.