Live data from Hacker News

Robotics Development Environment with ROS in C++ and Python

github.com

51–59 of 59 posts

Re: Robotics Development Environment with ROS in C++ and Python

#51
post #48

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.

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.

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

Re: Robotics Development Environment with ROS in C++ and Python

#52
I've been using ROS for some 8+ years now, for university projects, competitions like RoboCup@Home and for work on robots operating in the wild, on water, land and among people in malls etc.

I've seen many RoboCup teams convert from their custom stuff to ROS because it allows to profit for so much other great work. In my own team, we replaced most custom stuff implemented in the early days of ROS and with ROS with the now de-facto standard ROS stuff for the same task so we can focus more on the stuff that made us win the competition this year :-)

Re: Robotics Development Environment with ROS in C++ and Python

#53
post #48

Earlier quoted context omitted.

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.

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

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

Re: Robotics Development Environment with ROS in C++ and Python

#54
post #36

Earlier quoted context omitted.

Examples of poor decisions? I am just interested.

- Fundamental bug in the way they compute message schema checksums used for compatibility checks, causes buffer overflows and undefined robot behavior when changing array lengths. Is marked as wontfix because they don't want to recompile existing packages. - custom build tooling based on cmake is super cumbersome and buggy, and it means that you simply cannot communicate with ROS based stuff, without yourself becomin…

catkin packages are just CMake projects, and you can use find_package to discover them without making your module into a catkin package. I've written a few drivers this way without any problems (using existing message definitions.) For example: https://bitbucket.org/richmattes/si7021-sensor/src/master/CM...

Lack of QOS (and many other things) are definitely a drawback of ROS. ROS 2 is built on top of DDS, which replaces ROS 1's bespoke messaging/transport and has a robust set of tune-able QOS parameters.

Re: Robotics Development Environment with ROS in C++ and Python

#55
post #26
post #7

Earlier quoted context omitted.

It’s true, the reason for choosing C++ and Python as first class languages is because of their strength in numerical computing and AI capabilities (for python anyway), which erlang mostly lacks. It would definitely be cool to be able to use erlang though.

Honestly, the language that I'd love get first class support for on ROS2 would be Rust. Robotics really needs type and memory safety while maintaining performance and I personally feel like Rust is the perfect fit. I'd also love to see a mature linear algebra library in Rust (benchmarked to and as easy to use as Eigen).

There is an implementation of rust bindings for ROS 2: https://discourse.ros.org/t/announcing-rust-bindings-for-ros... https://github.com/ros2-rust/ros2_rust

It looks like they could use more help pushing things along.

Re: Robotics Development Environment with ROS in C++ and Python

#56
post #53

Earlier quoted context omitted.

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

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

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

Re: Robotics Development Environment with ROS in C++ and Python

#57
post #36

Earlier quoted context omitted.

- Fundamental bug in the way they compute message schema checksums used for compatibility checks, causes buffer overflows and undefined robot behavior when changing array lengths. Is marked as wontfix because they don't want to recompile existing packages. - custom build tooling based on cmake is super cumbersome and buggy, and it means that you simply cannot communicate with ROS based stuff, without yourself becomin…

With roslibpy you can communicate with ROS stuff without being a ROS Node: https://github.com/gramaziokohler/roslibpy "Unlike the rospy library, this does not require a local ROS environment, allowing usage from platforms other than Linux." Please also consider, that this is related mostly to ROS1.

This is interesting, but won't you lose out on a lot of the benefits of using ROS in the first place? None of the tooling (command line tools and roslaunch stuff) that expects nodes will work.

Re: Robotics Development Environment with ROS in C++ and Python

#58
post #36

Earlier quoted context omitted.

- Fundamental bug in the way they compute message schema checksums used for compatibility checks, causes buffer overflows and undefined robot behavior when changing array lengths. Is marked as wontfix because they don't want to recompile existing packages. - custom build tooling based on cmake is super cumbersome and buggy, and it means that you simply cannot communicate with ROS based stuff, without yourself becomin…

With roslibpy you can communicate with ROS stuff without being a ROS Node: https://github.com/gramaziokohler/roslibpy "Unlike the rospy library, this does not require a local ROS environment, allowing usage from platforms other than Linux." Please also consider, that this is related mostly to ROS1.

Yea I purposefully didn't include ROS-Bridge because thats another can of worms.

Re: Robotics Development Environment with ROS in C++ and Python

#59
post #53

Earlier quoted context omitted.

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

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 t…

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.
Post reply on HN