Note that Copper can be distributed too, we do support iceoryx2 for example if you need to split it in 2 or more processes.

We have ~100x less latency and ~12x faster logging also because we have adopted a data oriented architecture: the tasks outputs are written back to back in memory, all the IOs are linear (we could log to a block device straight, we don't even need a filesystem). I am not sure it is possible to touch this with ROS just because of its "everything is asynchronous" design pattern.

So the question is more about those limits in practical applications: do you have use cases where you absolutely need every single component deployed as a kind of micro service in a robot?

I will say the default network-transparency of ROS is probably more of a long-term hindrance than a help to applications built on top of it. A lot of projects would get a lot further if they were designed from the outset with clear boundaries where network communication was required (and what can be done to deal with what that implies), and it would be nice if components intended to be used in those systems were designed to be composed with that in mind, instead of requiring a network-based pub-sub system with not particularly great latency or reliability guarantees, even if it has a mode where those are tightened up a lot.

I disagree that the ROS2 comparison is questionable. If ROS want's to be seen as performant, they need to use a performant middleware by default. You shouldn't have to fiddle endlessly with it to get reasonable latencies.

Having worked on both large ROS systems and large monolithic robotics systems, the monolith wins hands down. The ROS paradigm that every node is it's own process is frankly insane.

TBF

> every node is it's own process

.. was SOA about 10 years ago. At this point any comparison to ROS1.0 is just strawman.

Nowadays nodelets and Ros2 eschew that approach to a larger degree. But you're right. Plenty of shops still use ROS1.0.

ROS was ... first, so they set the standard, and were AFAICT the introduction to distributed and message-passing systems for most roboticists coming out of school/Academia. They all graduated and had to relearn things over time (myself included). A plain-jane shared memory paradigm is just simpler and easier once you get a basic framework together for most things. There certainly are situations where you want process partitions, e.g., plug-and-play payloads. But even there, ROS plug-and-play is atrocious, since this is akin to a network drop, which it just doesn't handle. So, everyone just writes bridge nodes anyway.

Then don't get me started on multi-agent systems. At one point it was honestly believed that all agents would use a common Ros Master. Laughable!

While it may not be required anymore, one node per process still looks to me like the default paradigm in ROS2. If people are actually eschewing that approach, one would expect the ROS to update their docs to reflect these new best practices. Yet, their beginner tutorial and robot example still use that as the model as do many of the open source projects I have seen. I can't comment on how industry practices have evolved around ROS2, since my job still uses ROS1.