May be you don't need ros2
ROS2 isn't always the answer. Let's take a real hardware case that can help you exactly when to skip it
Why You Might Not Need ROS2
Every ROS2 tutorial begins the same: install it, learn nodes and topics, build your first publisher-subscriber pair. No one is telling you when to stop and not do any of that.
I’ve been on both sides of this enough to know the difference is not academic. Full ROS2 stack on a Jetson-driven survey quadcopter, and a bare ESP32 running an IMU over I2C with no ROS2 in sight. If you pick the wrong call, it will cost you weeks.
The case that convinced me
I wanted a 10DOF IMU (MPU9250 + BMP280) giving orientation information at high rates, filtered through Madgwick AHRS algorithm, calibrated to within about half a degree per axis. The immediate thought for anyone fresh out of ROS2 would be that it’s time to use it right away — publish an Imu, subscribe where necessary, problem solved.
Only that the IMU was sitting on an ESP32. No operating system, no DDS implementation, no memory space to run ROS2 clients. The actual solution was a stream of binary packets from serial port at 921600 baud rate, with a special bridge node handling the conversion to ROS2 messages when it gets to the machine capable of running one. ROS2 was not touching the microcontroller at all. It didn’t have to.
And there’s a name for this pattern: ROS2 is a distributed systems framework designed for machines which can be part of a distributed system. An ESP32 cannot. Many machines cannot.
When ROS2 is the wrong tool, not just overkill
Single-sensor systems. In case the entire project consists of only one sensor connected to one controller communicating to one device, then there is no "system"; there is a device. The whole idea behind using ROS2 is that of coordination of many nodes within the computation graph. There is no use in coordination of nothing with something.
Hard real-time control. The executors of ROS2, even the static and single threaded one, don't seem to provide the deterministic guarantees required by a hard real-time loop. In case missing a deadline means failure in safety – that is, losing a frame is not acceptable – then your choice would be a full fledged RTOS or a bare metal loop with ROS2 running a layer above.
Microcontrollers. rclcpp needs a real OS underneath it. No Linux, no ROS2 client library, full stop. micro-ROS exists for exactly this gap, but it's a different, more constrained tool with its own trade-offs — not a drop-in.
Mass-market products. If you're shipping a consumer device, you're not shipping a full OS plus a middleware stack plus DDS discovery traffic. That's an engineering-workstation cost structure, not a BOM you ship at volume.
Where it flips back to yes
None of this is an argument against ROS2. My own quadcopter project uses a Jetson Orin Nano, a Cube Orange+ flight controller and a Livox Mid-360 LiDAR. Three compute and sensor areas that really need to communicate with each other find each other and keep working even if one of them restarts on its own. That is the situation ROS2 was created for: real distributed robotics, multiple nodes, multiple sensors, a system that needs the coordination tools.
The question is not "is ROS2 good." The question is "does my system have than one part that needs to communicate with more, than one other part on hardware that can handle it." If the answer is yes then use it. The community and tools are worth the work. If the answer is no then the ESP32 solution is usually the choice: fix the real problem first and connect to ROS2 later when something else actually needs to listen.
