Long and love-rate (more rate than love) relationship, take mostly of this review with a grant of salt.
ROS (started in 2010) have some great tools visualize topics, send and debug messages, check frequencies, and much more. It's also possible to use more advanced tools and solutions like: rviz, gmapping, rtabmap, stereo_image_proc and the list goes on. With ROS, it's possible to take advantage of all drivers that exist for different pieces of hardware. Keep in mind that this is possible, but not easy, usually the drivers need specific configuration, custom settings and may give as output really complex data that needs to be processed or analyzed by another program.
ROS uses catkin, a build system based over CMake. What happens when you use an already complex build system for newcomers and put another layer of complexity over it ? Ha, something much more complex.
The C++ example already provides some an idea of how the build system and the project management works.
First, all messages need to be defined in a srv format or msg, some new format standard ? After that, you'll need to use some catkin magic to generate a XML for the first time (and you may edit it later manually! Cool right ?) With that XML, catkin will crab the necessary information (because the previous two format files can't do that), and use it to generate the necessary message definition files for C++ and Python. That should make it easy to make the messages well accessible between multiple languages, but sharing/accessing such definition files is still necessary.
Since messages definition and access are now well established, the user should be happy with the data structure and values that he's going to access inside his program. That's done with complexity and some unnecessary bureaucratic steps. But you should be fine if you have a simple python project, with ROS installed in your machine, that's going to access ROS pre-defined messages. If you start using custom messages.. You may need to put much more time.
ROS is well-known for breaking compatibilities between different versions, having fixed versions of ubuntu per ROS version and making things as contained as possible. The consequence ? Breaks, incompatibilities, old libraries, old OS, old programs.. a big pain for developers after a couple of years.
Oh, this also applies for messages between releases.
ROS2 was announced in 2014 (Oh yes, I hear about ROS2 for 8 years already), the first version was released in 2017.
| Features | ROS | ROS2 |
|---|---|---|
| C++ | C++03 // don’t use C++11 features in its API | Based over C++14 |
| Python | Based over Python 2 | >= Python 3.5 |
| Middleware | Custom serialization format (transport protocol + central discovery mechanism) | Currently all implementations of this interface are based on the DDS standard. |
| Unify duration and time types | The duration and time types are defined in the client libraries, they are in C++ and Python | In ROS2 these types are defined as messages and therefore are consistent across languages. |
| Components with life cycle | In ROS every node usually has its own main function. | The life cycle can be used by tools like roslaunch to start a system composed of many components in a deterministic way. |
| Threading model | In ROS the developer can only choose between single-threaded execution or multi-threaded execution. | In ROS2 more granular execution models are available and custom executors can be implemented easily. |
| Multiple nodes | In ROS it is not possible to create more than one node in a process. | In ROS2 it is possible to create multiple nodes in a process. |
| roslaunch | In ROS roslaunch files are defined in XML with very limited capabilities. | In ROS2 launch files are written in Python which enables to use more complex logic like conditionals etc. |
Based over: https://www.generationrobots.com/blog/en/ros-vs-ros2
ROS1 and ROS2 shares mostly of the negative/positive points, ROS2 is not as adopted or old as ROS1, so there fewer tools and solutions for it, but a vast land for us to grow. However, do not expect compatibility between versions.
ROS/ROS2: It's cool as a concept, but if you create a product based over it, you'll be stuck with the release cycle.
This document was inspired by hmartiro/zeromq-vs-redis