7 ms·

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 f

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 really hard to make a system that interfaces with all kinds of different robots and hardware, but I don't understand why they don't exploit existing high-quality solutions for the "not-robot-related" parts of their system. At the moment I don't think I would like to have ROS run a potential self-driving car.

ragebol 8y ago
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 requirements. The real-time stuff for motor control there is handled by EtherCAT. [0] https://design.ros2.org/ https://design.ros2.org/
- protomikron 8y ago
  > 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`?
  - oarfish 8y ago
    It's not even really supported outside specific Ubuntu releases I think, so for anything else you're on your own mostly.
  - ragebol 8y ago
    I think CMake is quite established. I don't like these kind of holy wars (I like vim too :-)) but to get stuff done. ROS lets me do that. 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.
  - dimatura 8y ago
    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.
    - takluyver 8y ago
      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.
      - xaedes 8y ago
        You actually can just cmake and that is all you need! [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 That works, but you can't mix it with catkin_make or other build tools (rosbuild). I.e. you can't just invoke catkin_make there, this won't work afaik. 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) You can put software components/packages in folders that are structured similar to project_utils / project_msg on any sublevel, I don't know what happens when you directly nest them though.. I wouldn't do that.
  - rmattes 8y ago
    ROS runs on Mac, and ROS 2 adds Windows support.
  - akoumis 8y ago
    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
    - jschwartzi 8y ago
      The Make equivalent is just the set of commands you would use to generate OpenCV plus a target and dependencies. If you can shell script you can write a Makefile.
      - akoumis 8y ago
        My point is that "find_package(OpenCV 3.0 REQUIRED)" is a whole lot simpler to remember than whatever the equivalent shell commands are to enforce the minimum version of a library. What you are suggesting is to build the exact version for use with this specific project, different from "Developer I checked your environment and your version is too low". I'm just speaking from my experience, if you are very experienced with shell and can reproduce this type of behavior more quickly then more power to you. This is a similar debate to "why rewrite standard libraries in every project", for example, to count items in a list in python I can loop through and modify counts in a dict or I can use "collections.Counter(list_)" and it does it for me. Cmake provides ample standardized methods for C++ builds that I don't have to rewrite over and over again for every project.
oarfish 8y ago
The bugginess aspect and often absent documentation and lack of tutorials which go beyond turtlebot is what irks me most. Sometimes, fundamental functionality such as message synchronization is just not useable.
Davidbrcz 8y ago
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 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.
- discreteevent 8y ago
  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 https://www.rti.com/products/what-is-a-databus
  - inamberclad 8y ago
    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.
- krona 8y ago
  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.
  - Davidbrcz 8y ago
asd4 8y ago
> 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 8y ago
  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).
dimatura 8y ago
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 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.
- protomikron 8y ago
  > 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.
  - cmansley 8y ago
    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.
    - protomikron 8y ago
securityfreak 8y ago
Agree. I used to work with ROS during a semester of AI. We had to build a robot that drove itself on top of a roomba vacuum cleaner and used a kinect for vision. I was super familiar with Ubuntu/Debian, but ROS was a mess. The materials we were provided by the course staff was more troubleshooting guides with ROS, than initial setup tutorials. It was a lot of fun, but I couldn’t imagine building something with real-world applications on top of it. Outdated packages. Lots of unpredictable failures. If the original purpose was only prototyping for students, then it works well for that.
tnecniv 8y ago
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.
Animats 8y ago
Yes. But it's still useful. 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.
- jvanderbot 8y ago
  I love the basics of ROS, but good lord they crammed far too much "into it" for it to only sit on one (or a few closely related) operating systems. If you build an ecosystem on top of an operating system, at least make it OS independent. (python+pip anyone?) 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.
- ModernMech 8y ago
  > I've used ROS and contributed to ROS in a minor way, but I don't like it. 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.
cantagi 8y ago
ROS beginner here. I've been experimenting with ROS in my spare time for about a week, with the ultimate goal of building a trainable robot. So far, I've built a custom robot arm in gazebo, converted it to URDF, and hooked up gazebo to ROS. The next step is to start controlling joints. 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.

ragebol 8y ago

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 requirements. The real-time stuff for motor control there is handled by EtherCAT. [0] https://design.ros2.org/ https://design.ros2.org/

protomikron 8y ago
> 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`?
- oarfish 8y ago
  It's not even really supported outside specific Ubuntu releases I think, so for anything else you're on your own mostly.
- ragebol 8y ago
  I think CMake is quite established. I don't like these kind of holy wars (I like vim too :-)) but to get stuff done. ROS lets me do that. 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.
- dimatura 8y ago
  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.
  - takluyver 8y ago
    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.
    - xaedes 8y ago
      You actually can just cmake and that is all you need! [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 That works, but you can't mix it with catkin_make or other build tools (rosbuild). I.e. you can't just invoke catkin_make there, this won't work afaik. 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) You can put software components/packages in folders that are structured similar to project_utils / project_msg on any sublevel, I don't know what happens when you directly nest them though.. I wouldn't do that.
- rmattes 8y ago
  ROS runs on Mac, and ROS 2 adds Windows support.
- akoumis 8y ago
  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
  - jschwartzi 8y ago
    The Make equivalent is just the set of commands you would use to generate OpenCV plus a target and dependencies. If you can shell script you can write a Makefile.
    - akoumis 8y ago
      My point is that "find_package(OpenCV 3.0 REQUIRED)" is a whole lot simpler to remember than whatever the equivalent shell commands are to enforce the minimum version of a library. What you are suggesting is to build the exact version for use with this specific project, different from "Developer I checked your environment and your version is too low". I'm just speaking from my experience, if you are very experienced with shell and can reproduce this type of behavior more quickly then more power to you. This is a similar debate to "why rewrite standard libraries in every project", for example, to count items in a list in python I can loop through and modify counts in a dict or I can use "collections.Counter(list_)" and it does it for me. Cmake provides ample standardized methods for C++ builds that I don't have to rewrite over and over again for every project.

oarfish 8y ago

The bugginess aspect and often absent documentation and lack of tutorials which go beyond turtlebot is what irks me most. Sometimes, fundamental functionality such as message synchronization is just not useable.

Davidbrcz 8y ago

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

discreteevent 8y ago
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 https://www.rti.com/products/what-is-a-databus
- inamberclad 8y ago
  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.
krona 8y ago
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.
- Davidbrcz 8y ago

asd4 8y ago

> 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 8y ago
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).

dimatura 8y ago

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

protomikron 8y ago
> 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.
- cmansley 8y ago
  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.
  - protomikron 8y ago

securityfreak 8y ago

Agree. I used to work with ROS during a semester of AI. We had to build a robot that drove itself on top of a roomba vacuum cleaner and used a kinect for vision. I was super familiar with Ubuntu/Debian, but ROS was a mess. The materials we were provided by the course staff was more troubleshooting guides with ROS, than initial setup tutorials. It was a lot of fun, but I couldn’t imagine building something with real-world applications on top of it. Outdated packages. Lots of unpredictable failures. If the original purpose was only prototyping for students, then it works well for that.

tnecniv 8y ago

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.

Animats 8y ago

Yes. But it's still useful. 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.

jvanderbot 8y ago
I love the basics of ROS, but good lord they crammed far too much "into it" for it to only sit on one (or a few closely related) operating systems. If you build an ecosystem on top of an operating system, at least make it OS independent. (python+pip anyone?) 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.
ModernMech 8y ago
> I've used ROS and contributed to ROS in a minor way, but I don't like it. 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.

cantagi 8y ago

ROS beginner here. I've been experimenting with ROS in my spare time for about a week, with the ultimate goal of building a trainable robot. So far, I've built a custom robot arm in gazebo, converted it to URDF, and hooked up gazebo to ROS. The next step is to start controlling joints. 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.