ROS2 – Day 1

Before we start to program we need to understand the fundamental concepts of ROS2. The concepts of ROS are managed via the REP (ROS Enhancement Proposal).

From a conceptual point of view a ROS workspace is the place where the programming happens. The Workspace filesystem schema is managed in the REP128. Best practice is to create a new directory for every new workspace. 

Due to the ROS2 documentation we start with a first development workspace:

mkdir -p dev_ws/src
cd dev_ws/src

A ROS workspace contains packages, often seen as one package = one node. The ROS package is among others defined by REP144. In the development documentation is it described here.

When you start, don’t be confused 🤔 by the alternatives CMake and Python. The naming is a bit wird. It should point to the two core supported development languages C(++) and Python. CMake is a tool used to control the software compilation process, often for the C-language.

Create a Python ROS2 package

We first continue with Python.

ros2 pkg create --build-type ament_python --node-name sender_node sender_package

Ups… usually the first failure appears.

ros2: command not found

We missed to source ROS2. Sourcing is the configuration, typically for a temporary purpose, of a specific development environment. It is often used in the Linux community; compare the e.g., bash command “source”. In the ROS development documentation it is described here.

. /<ROS2 install directory>/install/setup.bash

So before we continue lets clarify what the command “ros2” stands for. The “ros2” command is the CLI (aka command line interface) to ROS2. The new fashion term is “control plane interface”. A nice cheat sheet can be found here.

Lets type the command again:

ros2 pkg create --build-type ament_python --node-name sender_node sender_package

Now a directory “sender_package” with a bunch of files and folders has been created. Let’s have a look on these files and folders.

• Files:
  • package.xml, as defined by REP127 is IMHO only relevant using the new ROS2 catkin buildsystem. Due to REP127 is contains:
    • descriptive data (i.e. a description, maintainer)
    • dependencies on other ROS and system packages
    • meta-information (i.e. the author and website)
    • packaging information (i.e. the version)
  • setup.py, is nearly equal to the package.xml and points to the Distutils (aka setuptools) standard for building, installing and distributing Python3 modules. The Python package manager pip will use the setup.py to install your module. All of this is defined by the PEP (not REP). PEP is the Python Enhancement Process. Read more e.g. in PEP453.
  • setup.cfg, is required when a package has executables, so “ros2 run” can find them.
• Folders:
  • For Python the directory “sender_package” contains the generated ROS2 node source could as well as a “__init__.py” files which denotes a Python module.
  • resource …
  • test …

The build system(s)

So we do have a first overview of a ROS2 Python package and we already stated the ROS2 catkin buildsystem. The development documentation states colcon. Here we as developer have to take a decision. IMHO the article here supports the decision process well. Some say it is just build tool and the related orchestrating build system.

For ROS packages the primary build tools are

• ROS 1 packages using catkin 
• ROS 2 packages using ament_cmake

Colcon can be seen as a build system which orchestrates sets of packages.

When we goin our workspace directory with Colton we can build a set of packages

 colcon build --packages-select package1 package2

Run the ROS2 package (and node)

Lets run our code:

colcon build
. install/setup.bash
ros2 run sender_package sender_node

The expected output is:

Hi from sender_package.