Live data from Hacker News

Robot Operating System – A flexible framework for writing robot software

ros.org

51–60 of 85 posts

Re: Robot Operating System – A flexible framework for writing robot software

#51

My experience with ROS has been suboptimal. It's a collection of incompatible, outdated and buggy tools that communicate with each other via a single-point of failure (roscore) using a pub/sub mechanism. Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment. I appreciate their effort and it is re…

ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage. Many of the changes in ROS2 are actually about incorporating some of these solutions -- the most obvious example being the switch to DDS for messaging. Regarding catkin, I actually think it's an OK solution with some nice features. It's m…

> ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage.

In my opinion this is no excuse. 10 years ago was 2008 and we had rock solid solutions to these problems - I don't think it was necessary to build custom solutions (and AFAIK catkin is already the successor of rosmake).

But rereading my top-level comment it does seem a little bit harsh, so I want to apologize and hopefully do not discourage ROS developers and the community. ROS is still useful and at least there is an organized effort to make an open-source robot software abstraction layer.

Remark that the robot community (especially in an industrial setting) is plagued with closed-source proprietary software that is even worse, so despite its flaws it's a step in the right direction.

Re: Robot Operating System – A flexible framework for writing robot software

#52

My experience with ROS has been suboptimal. It's a collection of incompatible, outdated and buggy tools that communicate with each other via a single-point of failure (roscore) using a pub/sub mechanism. Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment. I appreciate their effort and it is re…

ROS started development almost 10 years ago. A lot of "high quality" solutions that seem like a good idea now may not have been around that long ago, or were still in nascent stage. Many of the changes in ROS2 are actually about incorporating some of these solutions -- the most obvious example being the switch to DDS for messaging. Regarding catkin, I actually think it's an OK solution with some nice features. It's m…

> catkin also supports Python code

I can appreciate that if you're writing C++ with some Python, this is probably useful. My experience with it was a project that was entirely written in Python, and suddenly having a complex, unfamiliar build system to deal with definitely felt like unnecessary complexity.

As you say, it's a hard problem. You could imagine an easier option for pure Python code, but that just moves the hurdle to the first time you want to compile something in C++.

Re: Robot Operating System – A flexible framework for writing robot software

#53
post #14

Earlier quoted context omitted.

The build system is mostly macros on top of cmake. But not ideal indeed. Same for the IDL. ROS 2.0 [0] should adress a lot of those issues, also stuff like real-time, improved security, no roscore needed. On the robots I worked with, I never missed any of those features, to be honest. Largest project of those is a research home service robot, quite different from a self-driving car in terms of reliability requirement…

> The build system is mostly macros on top of cmake. That makes it even worse. So it's crap on top of crap. CMake is mostly used to build cross-platform software, but I don't think anybody uses ROS on a system other than Linux, so why not just use established tools like simple `make`?

Having written plenty of makefiles and cmakelists I would much rather write the latter for a CPP project. The idioms are easier to remember so I don’t have to search through SO to do little things. Let’s say I want to include a version of OpenCV of at least version 3.0, this is a super simple cmake command, make equivalent is probably not standardized and is some some strange syntax I will have to include in every makefile where I need the same functionality

Re: Robot Operating System – A flexible framework for writing robot software

#54

Earlier quoted context omitted.

> The build system is mostly macros on top of cmake. That makes it even worse. So it's crap on top of crap. CMake is mostly used to build cross-platform software, but I don't think anybody uses ROS on a system other than Linux, so why not just use established tools like simple `make`?

CMake is pretty established. You don't have to use CMake and if you don't want to, you don't have to use it - you can just compile your code however you like and manually put all your package files where ROS expects them to be, or use symlinks or some other hack. Doesn't seem to be worth it just to avoid CMake.

The build system is effectively almost required, though, because the documentation telling you how to do anything in ROS assumes you're using Catkin. I wouldn't know how to arrange files for ROS to use without going through the build system.

Re: Robot Operating System – A flexible framework for writing robot software

#55

Anyone using this.. what have you built?

I published a research paper as an undergrad on improving an existing algorithm for a team of mobile robots to navigate space and create a map of their environment.

I also used it as an intern at a robotics company to use a microsoft kinect as a depth sensor for helping the robot perceive space in three dimensions.

Re: Robot Operating System – A flexible framework for writing robot software

#56

Could someone explain for a new bee. If I’m building a robot why would I use this and not just write a python script running on Linux?

Robots usually consist of many complicated components. ROS provides a unique and consistent method for those components to communicate with each other via an API and a pub/sub method. That way each one of your components can handle it's own logic via whatever software it likes, just so long as you can connect to the ROS api and let the OS handle orchestrating each component. A bit like a conductor in an orchestra.

Re: Robot Operating System – A flexible framework for writing robot software

#57

My experience with ROS has been suboptimal. It's a collection of incompatible, outdated and buggy tools that communicate with each other via a single-point of failure (roscore) using a pub/sub mechanism. Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment. I appreciate their effort and it is re…

My experience has been similar. Every real system I have worked on starts with ROS for fast prototyping, then slowly replaces each component with an in-house replacement due to recurring frustrations.

Re: Robot Operating System – A flexible framework for writing robot software

#58

Anyone using this.. what have you built?

NASA's Valkyrie, and Robonaut 2, in addition Fetch, and Baxter,a couple of industrial arms via ROS-i. I know that it's pretty horrid, but it's also the devil I know. This allows for rapid prototyping. In addition, the API hasn't changed much so I can walk away for months and come back and still use the robot. Several organizations support OSRF, but they're still just a couple of people. It's all open source so I've b…

> but they're still just a couple of people.

27 people are listed on their staff page.

https://www.openrobotics.org/team/

Re: Robot Operating System – A flexible framework for writing robot software

#59
post #50

Earlier quoted context omitted.

What market are you looking at? Its all about risk... if you're targeting the medical domain for example, you have a multi-year project just to get thru the certifications. Conversely if you're just looking at creating a toy with limited movement, weight and power then the risk is significantly less. Get an engineering safety consultant to have a look.

Industrial cleaning, machine is slow, but has many liters clean and dirty water inside. Just prototyping it and thinking how to achieve reasonable price. 30-50k is too expensive, janitor is cheaper.

Robotic lawnmowers may be a good application to draw inspiration from. They need to be low cost and likely have similar safety requirements to meet in terms of avoiding collisions and going out of bounds.

Re: Robot Operating System – A flexible framework for writing robot software

#60

Earlier quoted context omitted.

I spoke Mikael Arguedas at the 2018 French ROS days (JONAROS) where he gave a presentation about ROS 2 (talks are available online IIRC, in French). During his presentation; he said that most of ROS 1 was engineered before any of today's well known frameworks were available , hence the lot of custom tools. That has driven a major part of ROS 2's design (especially the use of DDS). Otherwise, I have been personally us…

I just saw that ROS2 will be based on the DDS standard. I came across DDS before in a different context and it impressed me a lot. It reminds me of the concepts in the eve programming language where to build a distributed system you share a global data space. Both took inspiration from LINDA and tuple spaces. "The data is the interface" https://www.rti.com/products/what-is-a-databus

Thank god for that. I had an internship where I just wrote a shim layer between DDS and Ros Messages. It was a huge pain since they didn't map very well to each other.
Post reply on HN