4 ms·

I kind of feel ROS rebuilt a ton of Google tech before it was open sourced. rosbuild is bazel, Ros messages are protobuffers/flatbuffers, orchistration is k8s.

I kind of feel ROS rebuilt a ton of Google tech before it was open sourced. rosbuild is bazel, Ros messages are protobuffers/flatbuffers, orchistration is k8s. I feel we could do a better job these days with the newer tools rather than ROS's less maintained, less interesting to researchers, reimplementation of infra tech.

isatty 7y ago
ROS does not do orchestration. The only valid point you have is that ROS IPC can do with better serde and yes, protocol buffers are indeed more elegant. The rest of it's not relevant to the actual project at all.
- tlarkworthy 7y ago
  "roslaunch is a tool for easily launching multiple ROS nodes locally and remotely via SSH, as well as setting parameters on the Parameter Server. " sounds like a form of orchestration to me
ragebol 7y ago
I've seen IPC tools be built from scratch or on top of more popular stuff in several companies I worked in, unfortunately. ROS2 is building on DDS, which is a standardized protocol and has implementations from multiple vendors as well as open source implementations, with QoS built in etc.
- tlarkworthy 7y ago
  yeah that looks cool but DDS is a technology designed for air gapped factories. AFAIK most ROS teams are still using ROS1 due to the lack of cross language tooling in ROS2. Again, bazel + gRPC* could solve this. * or perhaps better is flatbuffers see tensorflow-lite
  - ragebol 7y ago
    gRPC, ZeroMQ, RabbitMQ, ActiveMQ, there's a whole bunch of them. The decision to use DDS is explained here in https://design.ros2.org/articles/ros_on_dds.html https://design.ros2.org/articles/ros_on_dds.html
    - tlarkworthy 7y ago
      yes I read it at the time. However, HTTP3 + QUIC config [1] of gRPC also runs over UDP with more fallbacks to make it work over commodity hardware. DDR is a pain for random labs to work with as you have to have admin control over the network and bridges to make it work. This basically means it can't be used in the cloud or most corporate environments. It has huge deployment friction. Given the bad uptake of ROS2, I think the market agrees with me. Note QUIC and HTTP3 were not really a thing when ROS2 was conceived, but the problem of head of line blocking was known and ROS2 was just a bit too ahead of the curve. [1] https://www.fastly.com/blog/why-fastly-loves-quic-http3 https://www.fastly.com/blog/why-fastly-loves-quic-http3
      - ragebol 7y ago
        I think the market is pretty into ROS2 actually, its just the PhDs and grad students that will be on ROS1 for a longer time because they don't have the resources to make any switch. Amazon and a lot of other companies are big on ROS2.

isatty 7y ago

ROS does not do orchestration. The only valid point you have is that ROS IPC can do with better serde and yes, protocol buffers are indeed more elegant. The rest of it's not relevant to the actual project at all.

tlarkworthy 7y ago
"roslaunch is a tool for easily launching multiple ROS nodes locally and remotely via SSH, as well as setting parameters on the Parameter Server. " sounds like a form of orchestration to me

ragebol 7y ago

I've seen IPC tools be built from scratch or on top of more popular stuff in several companies I worked in, unfortunately. ROS2 is building on DDS, which is a standardized protocol and has implementations from multiple vendors as well as open source implementations, with QoS built in etc.

tlarkworthy 7y ago
yeah that looks cool but DDS is a technology designed for air gapped factories. AFAIK most ROS teams are still using ROS1 due to the lack of cross language tooling in ROS2. Again, bazel + gRPC* could solve this. * or perhaps better is flatbuffers see tensorflow-lite
- ragebol 7y ago
  gRPC, ZeroMQ, RabbitMQ, ActiveMQ, there's a whole bunch of them. The decision to use DDS is explained here in https://design.ros2.org/articles/ros_on_dds.html https://design.ros2.org/articles/ros_on_dds.html
  - tlarkworthy 7y ago
    yes I read it at the time. However, HTTP3 + QUIC config [1] of gRPC also runs over UDP with more fallbacks to make it work over commodity hardware. DDR is a pain for random labs to work with as you have to have admin control over the network and bridges to make it work. This basically means it can't be used in the cloud or most corporate environments. It has huge deployment friction. Given the bad uptake of ROS2, I think the market agrees with me. Note QUIC and HTTP3 were not really a thing when ROS2 was conceived, but the problem of head of line blocking was known and ROS2 was just a bit too ahead of the curve. [1] https://www.fastly.com/blog/why-fastly-loves-quic-http3 https://www.fastly.com/blog/why-fastly-loves-quic-http3
    - ragebol 7y ago
      I think the market is pretty into ROS2 actually, its just the PhDs and grad students that will be on ROS1 for a longer time because they don't have the resources to make any switch. Amazon and a lot of other companies are big on ROS2.