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.

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

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 ?

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.

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 single integrated "feature" on the robot.

2. IDL: Because they have their own middleware. I think this goes away in ROS 2.0 as they move to DDS.

3. Rosdep: Because they want to run on multiple distributions even though it seems Ubuntu is the only truly supported distro. Rosdep is just a thin layer over the local package manager, pip, and whatever else they have glued in.

4. Environment: They provide the concept of "workspaces" to enable checking out source for a small subset of packages to work on and override whatever is installed on the base system.

I live in the embedded / hardware world but my colleagues working on the higher level software tend think all of the above is necessary for dealing with the hundreds of packages and dependency hell that come with the "modular" robot software approach.

That said, the popular packages in the ecosystem for simulation, planning, robot modeling, etc seem powerful. Community developed ROS "drivers" (middleware integration) are also useful so you don't reinvent the wheel for off the shelf hardware integration.

> I live in the embedded / hardware world but my colleagues working on the higher level software tend think all of the above is necessary for dealing with the hundreds of packages and dependency hell that come with the "modular" robot software approach.

But it's not a huge step to push your packages to debian, and after that rosdep feels totally unnecessary.

> That said, the popular packages in the ecosystem for simulation, planning, robot modeling, etc seem powerful. Community developed ROS "drivers" (middleware integration) are also useful so you don't reinvent the wheel for off the shelf hardware integration.

I agree 100%.

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.

ROS is a packaging system for academic robotics software with a message passing layer. It was created by hammering a huge collection of existing software into talking a common protocol. The ROS people also made the distribution buildable as a whole (more or less; it's notorious for breaking due to version pinning problems.) Just having some kind of standard was a big win. It beats downloading multiple pieces of academic software and trying to bash it into cooperating.

I've used ROS and contributed to ROS in a minor way, but I don't like it.

Having said that, it did great things to bring together the community and kill the fragmented landscape of robotics. (Does anyone remember the 2000s-2010s and all the custom, proprietary robot abstraction layers that were built up? Awful.). Clearpath and a number of small vendors partnered well with ROS, pushing the BS off the stage.

But it hasn't aged well ...

The messaging and logging is the only useful component (for me / my teams). The codebases / nodes are abysmally intertwined, over cohesive, and lack a nice unixy modular architecture that I'd expect with something built on top of a message passing layer. The central point of failure is often a very real point of failure in spotty networking environments (dropping from wifi can kill your whole stack, even if all messages are local machine only)

DDS is nice, but everyone serious is pretty much already using it (mil / aero), esp because of shared memory transport. So it's great that they were dragged forward ... but it doesn't quite feel like the big leap that ROS 1.0 was.

I find this sentiment among most researchers and industry people I've talked to at IROS and ICRA. I always make a point to ask what they like about ROS when I find out they're using it and probably 95% of the time the top 2 answers are the message transport layer and rviz (the visualization tool). tf (the frame of reference graph) is sometimes in the top 2, but it's also been a complete pain for me (and others, so much that there are 2 competing versions: tf and tf2) and would be in my bottom 2 features. The rest of it I find most people say they could do without.

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 requirements. The real-time stuff for motor control there is handled by EtherCAT.

[0] https://design.ros2.org/

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`?

I've seen several times that companies write their message passing stuff on top of ZeroMQ, mttq and what-have-you, while they could have spent all that time doing something novel as well. At the cost of using less than perfect tools made by someone else that a lot of people are also using.

  [in any folder out of source]
  mkdir build
  cd build
  cmake [source folder]
  make
  source devel/setup.bash
  roslaunch your_fancy_package demonstrator_nodelet_or_whatever.launch

The source folder must contain a main CMakeLists.txt symlink which points to `/opt/ros/[distribution e.g. kinetic]/share/catkin/cmake/toplevel.cmake`. This symlink will be created when calling "catkin_init_workspace". You can also just put a copy of that file there to commit it in git. I do this and even modify it to include my own cmake modules and debugging stuff.

You can now layout your folders any way you want. That means the packages don't need to all be in the same folder, but can be grouped as necessary.

Example project layout:

  project
  ├── cmake
  |   └── FindSomePackage.cmake
  ├── doc
  |   └── index.md
  ├── project_msgs
  |   ├── msg
  |   |   ├── Foo.msg
  |   |   └── Bar.msg
  |   ├── CMakeLists.txt
  |   └── package.xml
  ├── project_utils
  |   ├── include
  |   |   └── project_utils
  |   |       └── foo.h
  |   ├── launch
  |   |   └── ...
  |   ├── scripts
  |   |   └── do_stuff.py
  |   ├── src
  |   |   └── foo.cpp
  |   ├── CMakeLists.txt
  |   └── package.xml
  ├── components
  |   ├── heisenberg_compensator
  |   |   ├── include
  |   |   |   └── ...
  |   |   ├── src
  |   |   |   └── ...
  |   |   ├── CMakeLists.txt
  |   |   └── package.xml
  |   ├── warp_controller
  |   |   ├── include
  |   |   |   └── ...
  |   |   ├── src
  |   |   |   └── ...
  |   |   ├── CMakeLists.txt
  |   |   └── package.xml
  |   ├── ...
  |
  ├── .gitignore
  ├── readme.md
  └── CMakeLists.txt -> /opt/ros/[distribution e.g. kinetic]/share/catkin/cmake/toplevel.cmake
        should contain set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

https://github.com/gerkey/ros1_external_use

But if you're looking for good documentation and tutorials, then yes catkin is basically required, but I don't think that's unreasonable.

Regarding catkin, I actually think it's an OK solution with some nice features. It's mostly a set of CMake macros that work with a certain conventional structure for packages. If you look at some other (newer) C++ package managers out there, like Hunter or FIPS, it's essentially the same idea. And catkin also supports Python code [1]. It's far from ideal, but it's a hard problem. Like many things in ROS, it's a "worse-is-better" kind of solution.

[1] Not as well as it could, re:pip integration and such; ROS2 supposedly has a better solution.

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.

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.

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.

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++.

A few years ago I tried to run a project based on ROS and gave up in the end due to compatibility problems (I was installing ros packages on top of an existing Ubuntu and it caused all kinds of problems). Now that I'm using their pre-built docker image and took the time to read the tutorials, I'm finding it more reliable and much nicer.

The tutorials are very clear and all the steps have "just worked" for me, although the individual packages don't always seem very well documented.

catkin doesn't seem like a heavyweight build system - more like an opinionated layout combined with some cmake macros and some scripts, built on top of cmake. I can see how this would be useful for myself as well as real roboticists to develop multiple packages in parallel without having to poke through complex and disparate build systems. A robotics student would want to dive into C++ or Python as fast as possible as opposed to figuring out the build system, and I think catkin serves this purpose.

Also, it's common for inexperienced linux/mac users to get confused between multiple installations - when they have to compile things from source, i.e. opencv. I wonder if the ros command line tools are partly designed to help students overcome that obstacle, i.e. the pattern roscommand packagename rosoptions.

I'd also argue against the added complexity of avoiding single points of failure during early stage robot development. Having to think about distributed systems and SRE would be a huge distraction from the already complex task of designing a robot and its software. I also very much hope that ROS isn't currently being used in self-driving cars without a lot of safety systems including hardware ones.