7.2 Introduction of project files

7.2.1 Project file structure

The file structure of ROS is shown below. Not every folder is necessary, it is designed according to your needs.

image-20210830115928145

7.2.2 Workspace

The workspace is the place to manage and organize the ROS project files. It can be described as a warehouse, which is loaded with various ROS projects, it is convenient for system organization and management. It is a folder in the visual graphical interface. The ROS code we written is usually placed in the workspace. There are four main first-level directories:

The top-level workspace (you can name it arbitrarily) and the src (name must be src) folder need to be created by yourself;

Note: Before using catkin_make to compile, be sure to return to the top-level workspace. Function packages with the same name are not allowed in the same workspace; function packages with the same name are allowed in different workspaces.

7.2.3 Function package

package is a specific file structure and folder combination. Usually, we put the program code that implements the same specific function into a package. Only CMakeLists.txt and package.xml are [Required], and the remaining paths are determined according to whether the package is needed.

Create function package

【rospy】、【rosmsg】、【roscpp】are dependent library, which can be based on business needs.

File structure

7.2.4 CMakeLists.txt introduction

1. Overview

CMakeLists.txt was originally a rule file of the Cmake compilation system, and the Catkin compilation system basically followed the CMake compilation style, but added some macro definitions for the ROS project. CMakeLists.txt of catkin is basically the same as CMake.

CMakeLists.txt is very important. It specifies the rules from source to target file. When the catkin build system works, it will first find the CMakeLists.txt inthe each package, and then compile and build according to the rules.

2. Format

The overall structure is as follows:

3. Boost

If you use C++ and Boost, you need to call find_package() on Boost and specify which aspects of Boost are used as components.

For example, if you want to use Boost threads, you need to enter the following command

4. catkin_package()

catkin_package() is a CMake macro provided by catkin. This is necessary to specify catkin-specific information for the build system, which in turn is used to generate pkg-config and CMake files.

Before using add_library() or add_executable() to declare any target, this function must be called. This function has 5 optional parameters:

More details, please click here to check.

Eg:

This indicates that the folder "include" within the package folder is where exported headers go. The CMake environment variable ${PROJECT_NAME} evaluates to whatever you passed to the project() function earlier, in this case it will be "robot_brain". "roscpp" + "nodelet" are packages that need to be present to build/run this package, and "eigen" + "opencv" are system dependencies that need to be present to build/run this package.

5. Package path and library path

Prior to specifying targets, you need to specify where resources can be found for said targets, specifically header files and libraries:

The argument to include_directories should be the *_INCLUDE_DIRS variables generated by your find_package calls and any additional directories that need to be included. If you are using catkin and Boost, your include_directories() call should look like:

The first argument "include" indicates that the include/ directory within the package is also part of the path.

Eg:

The CMake link_directories() function can be used to add additional library paths, however, this is not recommended. All catkin and CMake packages automatically have their link information added when they are find_packaged. Simply link against the libraries in target_link_libraries()

6. xecutable Targets

To specify an executable target that must be built, we must use the add_executable() CMake function.

This will build a target executable called myProgram which is built from 3 source files: src/main.cpp, src/some_file.cpp and src/another_file.cpp.

7. Library Targets

The add_library() CMake function is used to specify libraries to build. By default catkin builds shared libraries.

8. target_link_libraries

Use the target_link_libraries() function to specify which libraries an executable target links against. This is done typically after an add_executable() call. Add ${catkin_LIBRARIES

Syntax:

Eg:

Note that there is no need to use link_directories() in most use cases as that information is automatically pulled in via find_package().

9. Messages, Services, and Action Targets

Messages (.msg), services (.srv), and actions (.action) files in ROS require a special preprocessor build step before being built and used by ROS packages. The point of these macros is to generate programming language-specific files so that one can utilize messages, services, and actions in their programming language of choice. The build system will generate bindings using all available generators (e.g. gencpp, genpy, genlisp, etc).

There are three macros provided to handle messages, services, and actions respectively:

These macros must then be followed by a call to the macro that invokes generation:

 

7.2.5 package.xml introduction

The package manifest is an XML file called package.xml that must be included with any catkin-compliant package's root folder. This file defines properties about the package such as the package name, version numbers, authors, maintainers, and dependencies on other catkin packages. Note the concept is similar to the manifest.xml file used in the legacy rosbuild build system.

package.xml file build_depend must contain message_generation, and run_depend must contain message_runtime.

The package manifest with minimal tags does not specify any dependencies on other packages. Packages can have six types of dependencies:

Build Dependencies specify which packages are needed to build this package. This is the case when any file from these packages is required at build time. This can be including headers from these packages at compilation time, linking against libraries from these packages or requiring any other resource at build time (especially when these packages are find_package()-ed in CMake). In a cross-compilation scenario build dependencies are for the targeted architecture. Build Export Dependencies specify which packages are needed to build libraries against this package. This is the case when you transitively include their headers in public headers in this package (especially when these packages are declared as (CATKIN)DEPENDS in catkin_package() in CMake). Execution Dependencies specify which packages are needed to run code in this package. This is the case when you depend on shared libraries in this package (especially when these packages are declared as (CATKIN)DEPENDS in catkin_package() in CMake). Test Dependencies specify only additional dependencies for unit tests. They should never duplicate any dependencies already mentioned as build or run dependencies. Build Tool Dependencies specify build system tools which this package needs to build itself. Typically the only build tool needed is catkin. In a cross-compilation scenario build tool dependencies are for the architecture on which the compilation is performed.

Documentation Tool Dependencies specify documentation tools which this package needs to generate documentation.

<url> - A URL for information on the package, typically a wiki page on ros.org.

<author> -The author(s) of the package