The thing with ROS is… it's pretty good at what it sets out to do. It's a common framework that everything in the robotics universe can speak to, has some amazing tooling, and handles many tedious things that robotics experts shouldn't have to care about. It does broadly achieve this.
But from my perspective as a generalist software engineer who isn't a low-level robotics expert – as an ecosystem, it seems to have adopted every bad practice available and invented some more of its own. My experience working with it has been an exercise in trying to isolate it as much as possible so that the blast radius can be restricted. Many of the architectural design decisions are frankly baffling, although I appreciate that this is in part down to age, legacy, and the open nature of the platform.
ROS2 definitely feels like it rounds off some of the sharper edges and I'm very happy to see this project push forward in some useful areas!
Eeyup. I've seen a few companies with a prototype built on ROS and they universally struggle to get it from a basic demonstrator to a production system until they ditch ROS because it's just so poorly engineered. Everything you gain in the short term from having a nicely integrated system with a bunch of existing libraries gets more than offset by how buggy, difficult to debug, slow, and incomplete each part of it is, relative to basically any other alternative. Especially because it defaults to a distributed system which basically takes your existing problem and makes many new and exciting ones to go along with it (and neither ROS nor most of its users/developers are well equipped to solve distributed problems reliably).
This is my life right now: reckoning with optimizing a ROS1-based system that was itself hacked together in record time.
ROS seems almost like it wants to distribute state by default. And it has no primitives for sanely managing distributed state, health checks, etc. The lego brick approach to camera drivers is great, but trying to orchestrate all those bricks is a nightmare. Rosparam/master is woefully inadequte as a control plane.
I recommend anyone in this space look at tools like Consul.
I agree from my own painful experience, which makes the OP more impressive. I once tried to get the navigation stack running on a raspberry pi based robot to test out a gps driver, and was shocked that I had to include massive libraries for lidar and point clouds that I had no intention of using to get anything to build. In the end everything ran but the nav stack ate up so many resources that my robot wasn’t able to move reliably.
But from my perspective as a generalist software engineer who isn't a low-level robotics expert – as an ecosystem, it seems to have adopted every bad practice available and invented some more of its own. My experience working with it has been an exercise in trying to isolate it as much as possible so that the blast radius can be restricted. Many of the architectural design decisions are frankly baffling, although I appreciate that this is in part down to age, legacy, and the open nature of the platform.
ROS2 definitely feels like it rounds off some of the sharper edges and I'm very happy to see this project push forward in some useful areas!