[asd4]

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

[rcxdude]

Indeed, while I critisize the quality of the implementation, much of what they implement is necessary for or assists the development of such systems. Catkin is crap, but you need a reasonable way of assmbling multiple packages (from multiple languages) into a build, and there's not many decent options (vanilla CMake has grown a lot of relevant features now, so you could probably design a similar system with a lot less extra custom code and quirks). Their IDL is naive but you do need a standard one and the landscape was a lot bleaker when the project was started. Rosdep is mostly optional: I outright ignore it when I use ROS and just sort out installing the relevant dependencies using my package manager (If you do this you find ROS works just fine on other distros). The fact that environments are generally self contained is a huge help to development: I usually put in effort to persuade other bits of software to work in a similar manner (I try to keep each project contained to a folder: dependencies outside those available and installed by my distro's package manager should not leak outside this).

[jvanderbot]

Agree, these are, from a certain perspective, justified costs.

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

[tkruse]

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.