ROS Workspace

The concept of a workspace is independent of the ROS version. In other words, it doesn’t matter whether you’re using ROS 1 or ROS 2, both rely on the workspace concept.

The key word in this definition is directory. A ROS workspace is simply a folder in your file system that contains ROS packages.

But you may be wondering: what is a ROS package? That is a fair question. For now, think of a package as a self-contained unit that groups code, configuration files, and other resources. We will dive into the concept of ROS packages later in the note about ROS Packages.

Underlay

I know what you may be think, we are defining this unknown thing called “underlay” with another undefined term “overlay”.

Let’s explore our underlay workspace: /opt/ros/humble/

Overlay

Note, that for some reason unknown to me, the terms “underlay” and “overlay” are not frequently used in the ROS community. The vast majority of people when they refer to workspace it is usually the overlay workspace.

Create a overlay workspace is simple as creating a directory using the mkdir bash command. Just keep in mind that this directory MUST contain a src folder inside. Inside the src folder your packages will live.

The build tool in ROS 2 is called colcon (collective construction). colcon is an iteration on the ROS build tools catkin_make, catkin_make_isolated, catkin_tools and ament_tools.

colcon compile, test and install packages for you. colcon internally uses build systems depending on the type of package to compile or test, CMake↗ for C++ packages and setuptools↗ for python.

Open a new terminal and try to run the following commands:

user@hostname:~ $ cd ~/ros2_ws
user@hostname:~ $ colcon build --symlink-install

Failure? Why? hint: the ament_cmake is a ROS package that is currently not available.

The option --symlink-install creates a symlink to their original locations instead of copying.

This will create a three folders:

ros2_ws/
├── build
├── install
├── log
└── src

• build
• install
• log

External resources:

• A universal build tool↗

Workspace activation (source) is accumulative.

Don’t forget to source your underlay in EVERY terminal you open.

We do this to update our local package index (the packages intalled in our machine or robot).

External reference on sourcing here↗

What is the diference on setup.bash in the underlay an local_setup.bash in the overlay?

• setup.bash in the underlay under /opt/ros/<DISTO>/setup.bash enables all the packages in the underlay.
• local_setup.bash in the overlay under (usually) ~/<YOUR WORKSPACE>/install/local_setup.bash enables the ONLY the current workspace.
• setup.bash in the overlay under ~/<YOUR WORKSPACE>/install/setup.bash enables the current workspace as well as the underlay it was created in.

If you want to automate the process of sourcing the underlaying workspace you can use the power of bash in linux: