Let's look into the technical requirements for this chapter:

• ROS 2 (source installation) on Ubuntu 18.04 (Bionic)
• Timelines and test platform:
  • Estimated learning time: On average, 90 minutes
  • Project build time (inclusive of compile and run time): On average, 60 minutes
  • Project test platform: HP Pavilion laptop (Intel® Core™ i7-4510U CPU @ 2.00 GHz × 4 with 8 GB Memory and 64-bit OS, /GNOME-3.28.2)

The code for this chapter is available at https://github.com/PacktPublishing/ROS-Robotics-Projects-SecondEdition/tree/master/chapter_2_ws/src/ros2_talker.

Now, let's get started with ROS-2.

ROS-2 is a deterministic effort toward improving the communication network framework that will be used with real-time systems and production-ready solutions. ROS-2 aims to do the following:

• Provide secure communication between components
• Communicate in real time
• Connect multiple robots with ease
• Improve the quality of communication irrespective of the communication medium
• Provide an ROS layer directly onto hardware, such as sensors and embedded boards
• Use the latest software improvements

Remember the ROS equation diagram from the previous chapter? ROS-2 follows the exact same equation but in a different manner:

ROS-2 follows an industrial standard and implements real-time communication through...

In ROS-1, the user code would connect to the ROS client libraries (such as rospy or roscpp) and they would communicate directly with other nodes from within the network, whereas in ROS-2, the ROS client libraries act like an abstraction layer and connect to another layer that communicates with the network using other nodes through DDS implementation. A simple comparison is shown here:

As you can see, in ROS-2, the communication with the OS layer and further down to the hardware layer is done through DDS implementation. The DDS component in the preceding diagram is vendor-specific and implemented by the vendors.

The abstract DDS layer component is connected via ROS-2 and helps the user connect their code through DDS implementation. This way, the user need not be explicitly aware of the DDS APIs as they come through ROS-2...

As we saw in the previous chapter, ROS client libraries are nothing but APIs for implementing ROS concepts. Hence, we can directly use them in our user code to access ROS concepts such as nodes, services, and topics. ROS client libraries come with the ease of connecting with multiple programming languages.

Since each programming language has its own advantages and disadvantages, it's left to the users to decide which to choose from. For instance, if a system is concerned with efficiency and faster response rates, you could choose rclcpp, and if the system demands prototyping as a priority with respect to the development time that's utilized, you could choose rclpy.

The ROS client libraries in ROS-2 are split into two sections: one is language-specific (such as rclcpp, rclpy, and rcljava) and the other contains common functionalities that...

Unlike ROS-1, ROS-2 provides tools for debugging message logs and topic information as well. ROS-2 supports visual and command-line tools. However, since there is heavy development in ROS-2, not all the tools have been ported yet. You can still use ROS-1 tools using a ROS-1 to ROS-2 bridge (shown in the upcoming sections) for development.

Rviz is the exact same as how it was defined in ROS-1. The following table shows the features that have currently been ported from ros-visualization/rviz to ros2/rviz:

In the previous chapter, we used the package manager to set up the ROS-1 environment, desktop, pull keys, and startup installation. ROS-2 is no different and the same method can be followed (but obviously using different setup keys and commands). However, unlike ROS-1, where we followed the Debian package installation technique, we will try the source installation technique in this chapter for installing ROS-2, although you can use the Debian package installation technique as well. It is best to build ROS-2 manually on Linux (that is, via source installation) so that we can add any new changes or releases directly into the package and compile them. Let's get started with the source installation.

A ROS workspace is a directory where we keep the ROS packages. As you saw in the preceding setup, you know that the build technique that's used in ROS-2 is colcon instead of catkin, which was used in ROS-1. The workspace layout is a bit different in ROS-2. Colcon does out of source builds and creates the following folders:

• The build folder is where intermediate files are stored.
• The install folder is where each package will be installed.
• The log folder is where all the logging information is available.
• The src folder is where the source code is placed.

As the build steps were already explained and tried out while building the ROS-2 packages, let's quickly look at the commands that are needed to build any ROS-2 workspace.

Let's consider the ros2_examples_ws package for demonstration...

Writing nodes in ROS-2 is comparatively different from ROS-1 due to the introduction of the additional software layers we saw in the Fundamentals of ROS-2 section. However, OSRF has ensured there isn't a huge difference while writing the ROS-2 code in order to save time and effort. In this section, we'll compare ROS-1 code and ROS-2 code and find out the differences in their usage.

Let's consider the traditional publish...

As we already know, ROS-2 is still under heavy development and there isn't a proper long-term release. Hence, writing nodes in ROS-2 directly or porting them to ROS-2 immediately would be an arduous task. There is an option where you could still use ROS-1 packages with ROS-2 packages to develop your projects. This is done through a package called ros1_bridge.

It is actually an ROS-2 package, which establishes the automatic or manual mapping of messages, topics, and services and communicates between ROS-1 and ROS-2 nodes. It could subscribe to messages in a ROS version and then publish them in the other ROS version. This package comes in handy when you would like to use a simulator such as Gazebo with ROS-2 to test your project. There's only a limited number of messages supported in the ros1_bridge package at the time of writing. Hopefully, other...

This chapter was an introductory chapter to ROS-2 and introduced us to its features and capabilities compared to ROS-1. We understood how different the build systems are and how the nodes are written. We also wrote custom nodes and compared them to how they're written in ROS-1. Since ROS-2 is under development, we also learned how to make use of ros1_bridge, which helps us use ROS-1 packages and tools alongside ROS-2. From the next chapter onward, we shall begin working with interesting robot projects using ROS-1.

In the next chapter, we will learn how to build an industrial mobile manipulator.