Hacker News Reader

Comment by Davidbrcz | Hacker News Reader

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 using ROS for building robots for the French (and European) robot championship (see https://twitter.com/AIGRIS_Birds). It works pretty well, it is convenient, easy to learn and provide some nice tooling (bagging for replaying messages, simulation with Gazebo...).

It is the de facto standard for robotics middleware for scientific projects. It not widely used by industrials because of some shortcomings even if initiatives like ROS Industrial and ROS 2 will likely improve things.

View on HN

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.

I've been hearing about how ROS 2 is going to fix these problems since 2013. I'm not holding my breath.

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.

catkin is built on top of CMake, so that's no excuse.

A robot is made of dozen, if not hundreds of packages. catkin compiles the whole workspace in a single command while dealing with non trivial build dependency between packages, and generates a ready to deploy folder.

CMake has its drawbacks, fair enough, but 10 years ago it was pretty much already the de facto standard build system for C++. What would have used instead of CMake ?

  - Make and autotools (Haha) ? 
  - scons ?
  - completely custom build system ?
  - something else ?

The most painful I had to deal with was my teammates who, instead of creating a brand new package, would simply copy and paste and existing one without fixing the dependencies, resulting in a build that fails if the workspace was cleared.

> A robot is made of dozen, if not hundreds of packages. catkin compiles the whole workspace [...]

s/robot/software

Why even have the concept of a `workspace`? I don't think it solves any problem.

Most bigger software projects are built on-top of other software, but most deal with it without having to implement their own build system. I know that CMake is established software, but despite its own horrendous scripting language I find it mostly useful if you want to build cross-platform native software - if you're going to run on Linux anyway, I think there is no point for this indirection.

> - Make and autotools (Haha) ?

You might laugh about these tools, but they build most of your userspace if you're on Linux. And yes they even work on distributions other than Ubuntu.

Reply on news.ycombinator.com