16 comments

[ 2.9 ms ] story [ 52.4 ms ] thread
I think ROS was/is an incredible boon for open-source and education, and Willow Garage did great work by creating such a strong community for it. Unfortunately, I don't think that ROS has kept up with the requirements of more modern robotics applications, and I personally haven't found that ROS2 is fixing most of my major gripes.

There are so many huge companies with massive robotics projects nowadays (i.e. warehouse robotics, self driving cars, etc) that I'd love to see the lessons learned there put into a next-generation open-source system. I know from experience that the stuff these companies have internally feels like a step-function improvement. Unfortunately I don't know how to get something like that off the ground.

I have similar feelings toward ROS, but I don't have experience with industrial alternatives. Would you be willing to elaborate (insofar as you're allowed to) about what made the "step-function" level of difference between ROS and the internal systems you've used? Or on what you would want to see in such a next-generation system?
Robotics is very much split into research users and industry. In industrial automation you buy a device (say a sensor or programmable logic controller) that comes with a few supported protocols. Typically a field-bus for realtime communication. And for the fancy ones also OPC UA (ISO 62541).

I don't know automation vendors that sell devices with ROS-support out of the box. With the use of Python it must be hard to get ROS safety-certified.

OPC UA is like a merge of ROS (channels for PubSub communication) and "CORBA done right" (an object-model that can be transparently interacted with over the network).

Full transparency, I maintain open62541, an open source implementation of OPC UA.

When I was using it, I didn't get any vibes of "anything done right", I actually find OPC UA to be a horrible (and underdocumented) mess. This can also be seen in nearly all the various language bindings, just as if nearly everyone has had some problems with the protocol or ran out of steam at the most basic things.

open62541 is really nice though, thank you for your work.

I do find any comparison of ROS and OPC UA a bit weird though, but that maybe depends a little on your use case, especially if not strictly talking about what you mentioned.

I don't know about ROS2, but ROS is pretty good for prototyping things. Maybe not what you want for shipping a product, but it is highly productive as a platform. Lots of companies use it.
I am the developer advocate for ROS. Many of those projects you mention are using ROS or ROS 2, and the feedback from those users was instrumental in developing ROS 2. By my last count we had approximately 400 companies using ROS and that is likely an undercount. I usually point people to the ROS 2 TSC or the ROS Industrial consortium to get a sense of who using ROS in production.

We just published a new paper on ROS 2 in Science Robotics that demonstrates ROS's use on land, sea, air, space, and industry (the link below should take you to the open publication).

https://www.openrobotics.org/blog/2022/5/12/science-robotics...

What are your major gripes?

I’m trying to launch a ROS alternative called Mech (github.com/mech-lang). Would be interested to hear what you find lacking in ROS.

Ah… I smell the horrors of poorly-written Modern C++ and the eldritch abomination that is ‘catkin_cmake’…
technically it's 'colcon build' now but point taken
Wait, they even made a new thing to replace catkin? Oh fuck, we now have two eldritch meta-build systems instead of one…
ROS has been pretty incredible for robotics research. It reduces the barrier to entry for new postgrad students.

I would guess that most University robotics labs are running ROS (based on robotics publications).

My experiences with ROS have mostly been klunky. The documentation is really sub par, the Python portions completely highjack the logging module, and (if my memory serves me) the messages types aren't backwards compatible like other IDLs and so it can be a maintenance nightmare. I also felt like it was too easy to outgrow, like when wanting to communicate using something other than ROS messages, or upgrading the codebase to a C++ version that ROS noetic doesn't support.
What tools did you switch to once you outgrew ROS? Did you have to develop a system from scratch or was there a different protocol you built on?

Also, despite the lack of official support, I've found ROS noetic to work with even c++20. Granted my use cases might have been much simpler, but I haven't found that to be an issue.

I'm the electronics engineer working in a project involving ROS. And for what I see is quite powerful. My main gripe is that there is not a cheap way to get into the programming side if you are a engineer at home.

The cheapest robot out of the box is 600 euros, which is not cheap. Then you could try to build one yourself which is doable but requires time and could be a project in itself.

And I cannot find a standard DIY robot platform with a well explained tutorial. Maybe there is market for one of those kits?

I used Ros extensively over a decade ago but haven't kept up with it. Most of my work was on simulation, and what was then known as player stage gazebo.

Has that kept up with The Cutting Edge of simulation? Especially things like simulated limbs, friction coefficients, just overall physical realism? Is it being used by the Deep learning crowd when they simulate embodiment? also, has there been any interest in recent work on transference from simulation to the real world?