ROS2 vs ROS1? Or more like ROS2 + ROS1?
This 14th of December of 2018, ROS2 Crystal Clemmys was released officially. It’s a very important step due to the fact that it adds enough new functionality versus its prior older brother ROS2 Bouncy Bolson to be a real option to consider to make the jump from ROS to ROS2.
So here are some of my findings and facts about ROS2 versus ROS1. Just bear in mind that crystal is evolving really fast and it wouldn’t be a surprise that more improvements appear in the near future.
Use differences between ROS2 and ROS1
We will talk about ROS2 Crystal being the latest release. We will talk about the main basic differences in the way you use ROS2 versus ROS1:
- Launch files using .xml format are gone. Forget what you knew about launching nodes and other launch files using the package structure. The system now relies upon python files launching binaries or python scripts. You will use the python module launch and package launch_ros. Here you have a basic example of how the binary tc_node from a package called the_construct_pkg would be launched now.
from launch import LaunchDescription
package='the_construct_package', node_executable='tc_node', output='screen'),
- Catkin_make is gone: Catkin has been replaced by colcon. This new building system is in essence a universal building system for the ROS ecosystem. This means that it can compile not only ROS2 packages, but packages from ROS1 or even packages without any manifest. This is really useful to compile non-ROS-Packages like Gazebo, which traditionally was something to compile separated from ROS. Its grammar is very similar to the good old catkin_make:
# Compile one package
build --symlink-install --packages-select cpp_unit_3_services
# For everything in the "ros2_workspace"
- ROS Packages support exists but with some manual labor: ROS2 supports perfectly Cpp projects with the rclcpp. Python projects is another story. Although you can create rospackages that use python code with rclpy ros library in their scripts and rosrun those programs, the packages need to be configured manually for python use adding the ament_python export in the package xml. But that is defining the build type of the package and therefore, for the moment you won’t have easy mixing cpp and python code in the same package.
As for the main great features that ROS2 gives among others is the great capability of managing easily multiple robots and preliminary real-time programming support, features that are very welcomed by the community no doubt about that.
Can I use ROS2 completely forgetting ROS1? ROS1Bridge
The quick answer is: Yes but with drawbacks. So ROS2 Crystal has worked with the new GAzebo with ROS2 support, so you have access to creating your own simulations using only ROS2. You have access to the main ROS packages like tf, navigation, image_transport, rqt, and the big RVIZ. So it would seem that 90% of the current ROS users would be satisfied.
But the reality is that a huge amount of packages don’t come out of the bix working for ROS2 or are installed through debians. You will be obliged to compile them and probably make the modifications for ROS2 system. But there is an option which is using the ros1_bridge package.
This package allows you to run for example Gazebo simulations using ROS1, but communicate and control with ROS2 packages. It connects topics and services with the same message type and name. Crystal supports ros1bridge by default but only basic message types. If you want to use nonbasic message types, such as gazebo_ros_msgs you will have to compile ros1-bridge from source and in the same workspace have all the necessary messages you want to use with ROS2. Probably in the near future, it will support more message by default.
Absolutely! It feels cleaner and faster for sure. And unless you need to use specific packages that don’t exist yet in ROS2 and are difficult to port, I would use it no doubt. Its obvious that ROS2 will become the main ROS on the long run and now its functional enough to do practically anything that you did with the good old ROS1. And you have the added bonus of all the improvements added to the mix. So my recommendation is to go there and have a try with ROS2.
If you are a previous ROS1 Developer:
You are bound to stumble upon some functionality that you were used to that now has no support or is buggy. But no doubt this is the future and is just like when rosbuild was removed back in the old days of ROS1. Just deal with the changes and you will see its worth the initial headaches. Here you have a migration ROS1 to ROS2 guide.
But I would highly recommend to for the next years until ROS2 gets total support, combine ROS1 and ROS2. Especially in simulations which are not yet ported to ROS2 because they tend to be the less updated and more critical to change. Just until more and more simulations get ROS2 versions.
If you are new in the ROS world:
You won’t notice most of the missing or buggy features that another person used to ROS1 would notice. You will undoubtedly have a headstart and ROS2 is not much more difficult to learn than ROS1, as far as the basics are concerned.
Reading further sources :
- Course for ROS2
- Features Complete List
- Colcon full documentation
- ROS2 Examples
- Infographic | ROS2 vs ROS1
- Click to share on Twitter (Opens in new window)
- Click to share on Facebook (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to email this to a friend (Opens in new window)
- Click to print (Opens in new window)
- Click to share on Google+ (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Share on Skype (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on WhatsApp (Opens in new window)
- Click to share on Telegram (Opens in new window)