[picklebarrel]

I worked with ROS1 professionally for a few years. My big takeaway was that the middleware got a lot more attention than it deserved. There are tons of hard research problems to work on in robotics: reliable navigation, object recognition, planning, manipulation, etc. I felt like a better contribution to open source robotics would be some great class libraries for those things. But let your users wire them up however they want, rather than requiring them to fit into a predefined architecture.

[dgfitz]

I have also worked with ROS professionally, and it does the opposite of “get out of the way” almost as a design choice. It’s bad.

[rcxdude]

It would also cut down on the amount of code in those packages significantly. The overhead of gluing things into ROS is enourmous (and mostly makes everything worse: a robotic control system running through 3-4 unsynchronised nodes communicating over a network-based pub-sub system on commodity hardware has very little hope of working if everything is well written, let alone with the average quality of a ROS package).

[carlmr]

Exactly, the first question when somebody suggests using ROS should be: Do you even need it in the first place? Your code may be much simpler if you forgo the networking communicating nodes model completely.

[Datenstrom]

This was exactly my experience. We used DDS for our non-ROS parts but ROS2 was experimental at the time so we ended up needing to build bridges for everything that was ROS. Brining in even a single ROS package to not have to reinvent things was a huge pain point and ROS had issues where it couldn't be used across everything.

[dimatura]

There's probably not that much overlap between people who are good at writing communications middleware and people good at each of those research problems; there's not even that much overlap between people good at each of those research problems.

[moffkalast]

It was a real shotgun shot to the face. What ROS 1 needed was to modernize ros_comm a bit so it doesn't crash when the network changes and it would be a far better solution, plus integrating multimaster_fkie.

Now we've got this bullshit with multiple slower RMWs with vastly larger overhead and none of them work reliably, clogging the network with multicasts. Not only that but some packages only work with some RMWs or just one, fracturing the ecosystem even further, because breaking everything every 2 years wasn't enough to reduce compatibility.

Like the whole point of ROS in principle is the standardization, grab any two packages and they will work with each other if you remap the topics because the message types are the same. The effort should be in the direction to further this standardization, not actively prevent it.