Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Robot Operating System – A flexible framework for writing robot software

ros.org

Post reply on HN
Print view View original

81–85 of 85 posts

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

#81

Post by protomikron »

cmansley wrote: post #74
protomikron wrote: post #51

Earlier quoted context omitted.

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

Can you detail some of the rock solid solutions in 2008 for the problems addressed? For example, building multiple C++ packages from source. Google's Bazel wasn't open sourced until 2015, so solutions were still appearing long after 2008.

Actually I don't really understand the problem, what do you mean with "C++ packages"? AFAIK C++ still has no concept of packages (although this has been proposed), so you probably mean how to build C++ based software that is located in different directories or how to do hierarchical builds in general?

That is supported by most build systems, plain old make can do it, CMake can do it, scons can do it, the list goes on and it is actually not something special in software development. It's not like we were unable to build software consisting of multiple "packages" before catkin or bazel.

I'm not saying that these existing solutions are perfect and the problem in general (dependency hell) is pretty hard to tackle. It's just that I don't see how catkin and the workspace concept help here.

Btw. did you know that catkin_make, successor of rosmake, is already old-school?

It's now "catkin build" - oh no wait, that's again uncool if you go with ROS2, there we have our meta-meta-build system "ament".

#edit: I kid you not, it's now apparently "colcon".

See e.g. the discussion https://discourse.ros.org/t/colcon-amend-tools/4685 and rationalization http://design.ros2.org/articles/build_tool.html.

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

#82

Post by cbames89 »

robotresearcher wrote: post #58
cbames89 wrote: post #20

Earlier quoted context omitted.

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/

Woah, guess I lost track..

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

#83

Post by dimatura »

protomikron wrote: post #81
cmansley wrote: post #74

Earlier quoted context omitted.

Can you detail some of the rock solid solutions in 2008 for the problems addressed? For example, building multiple C++ packages from source. Google's Bazel wasn't open sourced until 2015, so solutions were still appearing long after 2008.

Actually I don't really understand the problem, what do you mean with "C++ packages"? AFAIK C++ still has no concept of packages (although this has been proposed), so you probably mean how to build C++ based software that is located in different directories or how to do hierarchical builds in general? That is supported by most build systems, plain old make can do it, CMake can do it, scons can do it, the list goes on…

catkin_make and catkin-tools (where "catkin build" comes from) both use catkin. They're just different CLI tools, and for the most part compatible, and have been fairly stable for about four years now. How many build tools have come out for JS over that period?

Workspaces are actually super useful. They're a similar idea to virtualenv and conda environments. If you don't find those useful I don't know what to tell you.

Since ROS2 is essentially a fresh restart I'm not surprised there's some churn. I think most people expect it to be fairly unstable for a while.

I've been working with ROS since nearly the beginning (as well as other middleware solutions) and I definitely see a lot of its flaws, but understand the rationale for a lot of the decisions. It's like C or C++, a 'worse-is-better' solution that's overall pretty decent, specially considering it's open source.

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

#84

Post by tkruse »

asd4 wrote: post #28
protomikron wrote: post #12

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…

> 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 agree. When I ask these questions (we use ROS at our company) the answers usually sound like the following: 1. Catkin: No other solution for multi-project CMake. Apparently development often spans multiple projects / repositories for a si…

The own buildsystem/dependency system is not without precedent for open-source communities with large number of independent packages (https://developer.gnome.org/jhbuild/, https://www.pkgsrc.org/).

The initial build system "rosbuild" was arguably a main reason ROS1 became successful, because it started making individual robotics packages developed in diverse academic environments reusable by other users (before, each lab had their own half-broken way of building/packaging software).

The buildsystem in it's limited way also had a very low learning curve for junior developers (though not for people trying to package binaries).

ROS1 was initially distributed as source packages, and that combined with a unified buildsystem led to a very low barrier for contributions. By installing ROS all users already had an environment set up in which they could easily modify sources packages from other packages created by people in other organizations, run with modifications and submit patches.

Compare that to installing a library as a binary, suspecting a bug, and then starting to find out where to get the sources, how to build the sources, how to locally build against those sources, etc.

The downside of this was of course packaging binaries was hell. But the bottom line was that this combination (making binary packaging and distribution very hard, while making dirty source builds very easy), was the winning ticket to create a vibrant open-source community with high cohesion and lots of contributions in academia.

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

#85

Post by dimatura »

takluyver wrote: post #52
dimatura wrote: post #41

Earlier quoted context omitted.

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

Super useful, in fact. A lot of the code I write follows a typical pattern of bottleneck code in C++ with python wrappers, or a mixture of pure python nodes (for the things that don't have to be super fast) and pure C++ nodes. This is fairly common throughout ROS. If catkin played better with current Python packaging and virtual environment systems (virtualenv/conda) it would be so much better, though.
Post reply on HN