Every time I post about ROS 2, I get either “Just use ROS for everything!” or “ROS is bloated overkill.” Both camps have a point, and neither is entirely right. The real answer, as with most engineering decisions, depends entirely on the project in front of you.
My Make Magazine article on ROS 2 nodes, topics, and services covered the mechanics of how ROS works, and a previous post covered the “why” at a high level. This post tackles the harder question: should you use ROS for your project? To answer that, it helps to understand what kind of robot you’re actually building.
I also have a full Introduction to ROS video series on DigiKey’s channel should you wish to dive fully in to ROS 2:
Three Project Archetypes
Not all robots are created equal. For example, a maze-solving bot you build over a weekend and a warehouse autonomous mobile robot (AMR) used in a commercial fulfillment center are both technically “robots,” but they have almost nothing in common from a software architecture standpoint. Treating them the same way when making tooling decisions is where a lot of frustration comes from.
It helps to think about robotic projects on a spectrum, from simple and single-purpose on one end to complex and multi-component on the other. Where your project falls on that spectrum is the single most important factor in deciding whether ROS 2 is worth the investment. Let’s take a look at three possible projects with varying scopes along this spectrum.
Example 1: The Weekend Project or Hobbyist Bot
Think of the classic beginner builds: a line follower, a maze solver, a small rover controlled with a joystick. These projects typically run on a single microcontroller, use one or two sensors, and do one thing. The entire program might fit in a few hundred lines of C or MicroPython.
For projects like these, ROS is almost certainly overkill. You would spend far more time setting up a Linux environment, installing ROS 2, configuring packages, and wiring together nodes than you would actually building the robot behavior. A straightforward Arduino sketch or a bare-metal firmware loop will get you to a blinking LED, a spinning motor, or a sensor reading far faster, with much less friction.
The goal here is to build something that works and teaches you something. ROS gets in the way of that for simple projects.
Example 2: The Ambitious Personal or Academic Project
Now consider something more involved: a custom robotic arm, a mobile platform with simultaneous localization and mapping (SLAM) capability, or a project you want to put in your portfolio. Multiple subsystems are talking to each other. You have a sensor pipeline feeding into a processing node that drives actuators. You might be working in simulation part of the time and on hardware the rest.
This is the sweet spot where ROS 2 starts to earn its keep. When you find yourself writing custom message-passing code to shuttle data between your sensor driver and your motion planner, that’s usually your signal that you’re reinventing something ROS already provides. The ROS 2 ecosystem also gives you tools like RViz (a 3D visualization tool for seeing coordinate frames, sensor data, and robot models in real time) and rosbag (for recording and replaying data streams), which are genuinely difficult to replicate on your own.
There’s a real learning curve here, but if you put in the time, you’re also building skills that are directly transferable to industry. Most research labs and a growing number of commercial robotics companies use ROS 2 as their development foundation.
Example 3: The Commercial or Research Platform
This is where ROS 2 (or some other middleware) is almost a given. Think multi-robot systems, research manipulators, collaborative robots (cobots), or long-lived commercial products with hardware revisions planned from the start. These projects have multiple contributors, evolving codebases, and requirements that will change over time.
ROS 2 was specifically redesigned (from the original ROS 1, which reached end-of-life in May 2025) to address the shortcomings of its predecessor in exactly these scenarios. It introduced a distributed communication architecture based on the Data Distribution Service (DDS) standard, which removes the single point of failure that plagued ROS 1 and improves reliability in multi-machine systems. The hardware abstraction and standardized package ecosystem mean that porting your code to a new robot platform is a manageable task rather than a rewrite.
One important caveat: ROS 2 is still not a hard real-time operating system (RTOS). For safety-critical or strictly time-deterministic applications, you will still need to think carefully about where real-time constraints live in your system and potentially pair ROS 2 with a separate real-time layer. This is an active area of development in the ROS community, but it is worth knowing going in.
Questions to Ask Before Committing
Once you have a rough sense of where your project falls, these four questions can help sharpen the decision:
- How many subsystems need to communicate? If the answer is one or two, a simple function call or a shared data structure is probably enough. Once you have three or more independent components that need to exchange data asynchronously, a formal messaging layer starts to make sense.
- Do you expect the hardware to change or the codebase to grow? If this is a one-time build that will never evolve, the overhead of ROS 2 is harder to justify. If you expect to swap out sensors, target a different robot platform, or hand the codebase to someone else later, the portability and structure that ROS 2 provides are worth paying for upfront.
- Are you targeting a microcontroller or a Linux-capable single-board computer (SBC)? Standard ROS 2 requires a full Linux environment and a reasonably capable processor. It is not going to run on an ESP32 or a bare STM32. If your project is microcontroller-based, look into micro-ROS, which brings a subset of ROS 2 functionality to resource-constrained hardware and can bridge a microcontroller into a larger ROS 2 system. That topic deserves its own post, but it is worth knowing the option exists.
- Do you need real-time guarantees? Sensor fusion at high update rates, hard deadlines for motor control, safety interlocks: these concerns push you toward either bare metal, an RTOS like FreeRTOS or Zephyr, or a hybrid architecture where ROS 2 handles the higher-level orchestration and a separate real-time layer owns the time-critical work.
The Hidden Costs
Choosing ROS 2 is not just a technical decision. Rather, it is also a time investment, and it is worth being honest about that before you commit.
The learning curve is real. Getting comfortable with the ROS 2 build system (called colcon), the package manifest format (package.xml), the ament build tools, and the overall project structure takes time, especially if you are coming from a bare-metal or Arduino background. Budget a few weeks of regular tinkering before things start to feel natural.
Additionally, the resource requirements and overhead are non-trivial. A Raspberry Pi 4 or Pi 5 works well for running ROS 2, but older or lower-powered SBCs can struggle, particularly once you add visualization tools or multiple nodes. And as mentioned above, standard ROS 2 simply does not run on microcontrollers without micro-ROS.
Dependency management can become painful on longer-lived projects. The ROS 2 ecosystem moves quickly, and keeping up with distribution releases, deprecated packages, and upstream changes in your dependencies takes ongoing maintenance effort. This is a normal cost of working in an active open-source ecosystem, but it is something to factor in if you are planning a project with a multi-year lifespan.
None of these are dealbreakers, but they are real costs that the “just use ROS for everything” crowd sometimes glosses over.
My Take
The “just use ROS” crowd and the “ROS is bloated” crowd are both partially right, and they tend to be talking about different kinds of projects without realizing it. ROS 2 is a genuinely excellent tool for the problems it was designed to solve: complex, multi-component systems where communication, portability, and long-term maintainability matter. It is a poor fit for simple, single-purpose systems where its overhead outweighs its benefits.
Committing to ROS 2 before your requirements are clear can bog you down in infrastructure before you have anything working. Committing to a simpler approach and then outgrowing it can mean painful refactoring later. Taking a little time upfront to sketch out your subsystems, think about how they will communicate, and honestly assess whether the project is likely to grow will almost always save you time in the long run.
If you have decided ROS 2 is the right fit and you want to get started, my Make Magazine article and full Intro to ROS video series walk you through installing ROS 2 via Docker and building your first nodes, topics, and services from scratch. And if you are still on the fence about whether you need a formal framework at all, the Why Use ROS? post covers the broader case.
What kind of robotics project are you working on, and where did you land on the ROS decision? Let me know in the comments!