[facontidavide]

I have been doing robotics for 20 years, and the "trend" to adopt a distributed architecture was already popular 15 years ago. ROS just adopted and continued that trend. I think you are missing some important points:

- a large amount of data can be transferred asynchronously. Pub/Sub is a great pattern to achieve that; the cases when you need a synchronous interface are the minority.

- a robotic software has MANY components, you need an approach that incentivize decoupling and lousily-coupled interfaces.

- this lousily-coupled architecture has been a catalyst for innovation and cooperation, because it makes it easier for people to share their code as "building blocks" of a larger system.

Is there a considerable overhead? Sure! But it is much more complicated to write thread-safe code in a huge, monolithic application.

[lqr]

I worked on a robotics project with a large team using ROS1. The loose coupling is pernicious: It's easy for everyone to work on their own ROS node in isolation and avoid testing the integrated system. There's no compiler to help you find all the clients of a node, etc.

Loose coupling is good if you mainly use open-source packages and modify one component for your research paper. I'm not sure it's a net positive when building most components yourself.

A big multithreaded program can still use queues instead of locks to share data between threads.

[spieswl]

So many of these comments sound like engineering process flaws.

Everyone's working on their own ROS nodes in isolation....with no thought to eventual integration testing? It doesn't seem like that is a fundamental shortcoming specific to ROS.

[lqr]

Of course, but ROS makes it easier to slip into this flawed process. I prefer tools that help you avoid bad engineering processes.