4 ms·

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

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.

jvanderbot 2y ago
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!
- patrick451 2y ago
  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.

jvanderbot 2y ago

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!

patrick451 2y ago
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.