ROS 2: when it is required, and when it is just overhead
The de facto standard for robot middleware, BSD-licensed at the core with no royalty for commercial use. But it handles messaging, not policies — and a single desktop arm running system-level middleware is often a factory carrying a desk job.
- Licence
- BSD-3-Clause core; no royalty for commercial products
- Current LTS
- Kilted Kaiju (five-year support window)
- Next LTS
- Lyrical Luth, released May 2026
- ROS 1
- End of life since May 2025; tutorials written against it are out of date
- Languages
- First-class Python and C++, with Rust bindings
- Docs
- docs.ros.org
- What it solves
- It solves communication and real-time behaviour between subsystems: cameras, arms, bases, navigation and planning each run as separate processes and need a messaging layer that keeps time and priority straight. When your robot is one arm and two cameras, none of those requirements exist, and the middleware's overhead is pure cost.
- Alternatives
- For a single arm doing learning work, running LeRobot directly is far quicker and removes the whole concept stack. For simulation-first work, Isaac Lab ships its own training framework. A vendor SDK is often sufficient on its own: if you command one machine and do not coordinate multiple devices, an SDK plus a bit of scripting usually beats introducing middleware. The value of ROS 2 rises with system complexity, not with your skill level.
- What it takes to start
- The price is a set of concepts you cannot skip: DDS configuration, QoS policies, node graphs, lifecycle management. These are not optional details — when a topic is silent, the cause is almost always sitting in one of them. On top of that it generally pins you to a specific Linux distribution, so the environment itself is work.
- Known pitfalls
- (1) Following a ROS 1 tutorial: ROS 1 is end of life and a great deal of online material has not been updated, which produces a string of unexplainable errors. (2) QoS mismatches that silently drop a topic — no error, just no data, which makes it one of the most expensive classes of bug. (3) Adopting it for credibility: on a small single-machine project the complexity it adds dwarfs what it solves.
- What we checked
- We checked the licence and commercial terms, the release cadence and the ROS 1 end-of-life date, and its division of labour with learning libraries (layers, not substitutes). Not checked: performance numbers in a specific project — the real-time impact of a DDS configuration depends heavily on hardware and setup, and we have not run comparative tests.
Decide on complexity, not on seniority: multiple subsystems that must cooperate — use it; one arm on one machine — do not. A practical threshold: the moment you start writing your own glue for inter-process communication, that is the signal to bring in ROS 2. If you are only trying to make one arm move, that is the signal to stay away from it a while longer.
Complexity decides it
| Your situation | Suggestion |
|---|---|
| One desktop arm plus a camera, goal is policy training | Go straight to the learning library; skip middleware |
| Arm plus base plus navigation, several subsystems cooperating | ROS 2 is the right call, and now the overhead earns its place |
| Commanding one vendor's finished machine | Start with the vendor SDK; migrate when it visibly stops being enough |
| Multi-robot fleets, industrial deployment | There is essentially no alternative at this layer |
Installing ROS 1 packages from a tutorial written two or three years ago. Check which distribution a tutorial targets before you type anything — five minutes now removes every "why does this command not exist" afterwards.
Sources
- ROS 2 official documentation (release support windows, licence, system requirements)
- Public technical comparisons (the layering between learning libraries and middleware)
Objects in this entry
Last checked 2026-09-28