If you’ve worked on robots for more than 2 weeks, chances are you’ve touched ROS2. It’s the default middleware in research labs, startups, and classrooms. It gives you drivers, visualization tools, navigation stacks, and a messaging system so your robot’s parts can talk to each other.
But if you’ve spent months with it, you’ve probably hit the same wall many engineers complain about:
ROS2 is always one hack away from working as it should.
Serialization overhead, dependency bloat, and platform lock-in turn a promising tool into a productivity sink. That’s why the question keeps coming back:
What do people use instead of ROS2, and should I switch?
Why ROS2 Became the Standard
Before looking at alternatives, it’s worth asking why ROS2 exists at all.
Robotics is really, really messy: sensors stream data, actuators wait for commands, navigation and mapping run in parallel. Without middleware, every team ends up reinventing the wheel. ROS2 tried to solve this by offering:
- Unified messaging via DDS.
- A huge library ecosystem (Nav2 for navigation, MoveIt for motion planning, RViz for visualization, Gazebo for simulation).
- Community-driven drivers for everything from LiDARs to joysticks.
That ecosystem is ROS2’s greatest strength, and also its biggest weakness.
The Problems That Push People Away
Despite its tools, ROS2 carries heavy baggage.
First one is “Serialization Overhead“. Every message between nodes is serialized and deserialized, even if everything runs on one CPU. Passing a 4K camera stream at 30fps? That can burn three CPU cores just moving data around.
You also find too many abstractions, performance often comes down to tweaking yet another DDS plugin, QoS setting, or composable node. Instead of building robot logic, you’re debugging middleware.
Another problem you may encounter is called “Lock-In”. ROS2 runs best on Ubuntu LTS and NVIDIA Jetson boards. If you want to use a real-time OS or the latest C++ standard, you’ll literally fight the framework.
Lastly, Dependency Bloat. As a programmer I find the same problem with other frameworks such as Node.JS (completely out of topic but relatable), and so with ROS2, getting started often means apt install-ing gigabytes of packages. That’s fine for a research laptop, but less so for an embedded controller.
For quick prototyping, these tradeoffs are acceptable. But for industrial robots, where reliability and efficiency matter, the cracks start to widen.
What People Actually Use Instead
Engineers don’t agree on a single replacement. Instead, they pick lighter or more specialized solutions depending on the problem.
1. Code-Centric Minimalism
- Plain C++ with shared memory: Threads pass pointers directly instead of serializing.
- Custom lightweight frameworks: C or Python scripts with UDP for fast data and TCP for heavier payloads.
It is great for single-board systems where everything runs locally, but you lose ROS2’s plug-and-play ecosystem
2. Domain-Specific Stacks
- PX4 or Ardupilot → drones.
- AUTOSAR with MISRA C++ → automotitve robots.
- PLC ladder logic → industrial arms.
Those stacks are just optimized for their own niches, meaning that you can’t just use it in any robotics toolkit you want.
3. Messaging-Only Frameworks
- Zenoh → a lightweight alternative to DDS.
- MQTT → popular in IoT robots and AMRs (Autonomous Mobile Robots).
I’ll admit, those frameworks are faster and leaner than ROS2, but you must build your own ecosystem on top, since they provide only messaging. So you must build drivers, visualization, and coordination tools yourself.
4. Commercial Ecosystems
- ABB’s RoboStudio, KUKA’s middleware.
- Navigation stacks like BlueBotics ANT or Navitec Navitrol for AMRs.
They are stable, certified, supported, but expensive and closed-source.
Why There’s No One-Size-Fits-All Replacement
Here’s the catch: no alternative gives you what ROS2 does out of the box. As we said earlier:
- Zenoh or MQTT → great for messaging, but no visualization or TF tree.
- PX4 or AUTOSAR → great for drones or cars, but useless outside their niche.
- Plain C++ → fastest, but you reinvent every driver and tool.
That’s why many engineers don’t ditch ROS2 completely, they just use it sparingly.
The Pragmatic Fix
If you’re a hobbyist, researcher, or part of a small startup, ROS2 can be a real time-saver.
Tools like RViz for visualization and bag files for logging make it easy to test ideas quickly without having to build everything from scratch. The overhead is there, but in most early projects the convenience of having a ready ecosystem outweighs the performance cost.
For production-grade robots, though, the priorities shift. In that case, it often makes sense to prototype with ROS2, then phase it out as the design matures.
Performance-critical parts of the system-like control loops or heavy sensor processing, benefit from being written directly in C++ with shared memory. If you plan your architecture carefully, you can keep ROS2 where it helps, but still remove it later without tearing the whole system apart.
Key Takeaways
- ROS2 is bloated and sometimes frustrating, but its ecosystem is unmatched.
- Alternatives exist. C++ shared memory, PX4, Zenoh, MQTT, proprietary stacks, but none fully replace ROS2.
- The smartest path isn’t to abandon ROS2 entirely. Use it sparingly: prototype with it, then optimize around it.
No comments yet