ROS learning note file system

Posted by vandalite on Mon, 31 Jan 2022 00:12:17 +0100

ROS learning notes (II) file system

Opening: file system structure of ROS. To learn to build a ROS project, we must first understand a ROS project, understand their organizational structure, be fundamentally familiar with the organizational form of ROS project, and understand the functions and functions of various documents, so as to carry out development and programming correctly.

The main contents of this chapter are to introduce the compilation system of catkin, the creation and structure of catkin workspace, the creation and structure of package software package, and cmakelists Txt file, package XML and other common files. Thus, it systematically combs the structure of ROS file space, which plays an important role in our ROS learning and development.

2.1 Catkin development system

For the source code package, we have to compile to run on the system. The compilers under Linux include gcc and g + +. With the increase of source files, it is inefficient to directly use gcc/g + + commands. People began to compile with Makefile. However, with the increase of project volume, Makefile can not meet the demand, so cmake tool appears. Cmake is the generator of make tool and a higher-level tool. It simplifies the compilation and construction process, can manage large projects and has good scalability. For a large platform like ROS, cmake is adopted, and ROS extends cmake, so Catkin compilation system is available.

The early ROS compiling system was rosbuild, but with the continuous development of ROS, rosbuild gradually exposed many shortcomings and could not meet the needs of the system. After the release of Groovy, catkin was officially put into use as a substitute for rosbuild. Catkin has more simplified operation, higher work efficiency, better portability, and supports cross compilation and more reasonable function package allocation. At present, ROS supports both rosbuild and catkin compilation systems, but the core software packages of ROS have also been converted to catkin. Rosbuild has been phased out, so it is recommended that beginners start catkin directly.

In this section, we mainly introduce the compiling system of catkin.

2.1.1 Catkin features

Catkin is a compilation and construction system based on CMake, which has the following characteristics:

Catkin follows the tradition of package management, such as find_package() infrastructure, PKG config
Extends CMake, for example
- After the software package is compiled, it can be used without installation
- Auto generate find_package() code, PKG config file
- It solves the problem of construction sequence of multiple software packages

A Catkin package must include two files:

package.xml: includes the description information of the package
- name, description, version, maintainer(s), license
- opt. authors, url's, dependencies, plugins, etc...
CMakeLists.txt: CMake file required to build package
- Call Catkin's function / macro
- Parse package xml
- Find other dependent catkin packages
- Add this package to the environment variable

2.1.2 Catkin working principle

The workflow of catkin compilation is as follows:

First, catkin in the workspace_ Recursively find the package of each ROS under WS / SRC /.
There will be package in package XML and cmakelists Txt file, Catkin(CMake) compiles the system according to cmakelists Txt file to generate makefiles (put in catkin_ws/build /).
Then make the just generated makefiles and other files, compile the link and generate the executable file (put it in catkin_ws/devel).

In other words, catkin is a tool that encapsulates cmake and make instructions to complete the whole compilation process. Catkin has outstanding advantages, mainly including:

Easier operation
One configuration, multiple use
Cross dependent project compilation

2.1.3 using catkin_ Compile with make

To compile a project or software package with catkin, you only need to use catkin_make command. Generally, when we finish writing the code, we execute catkin once_ Make to compile, call the system to automatically complete the compilation and linking process, and build and generate the target file. The general process of compilation is as follows:

$ cd ~/catkin_ws #Back in the workspace, catkin_make must be executed in the workspace
$ catkin_make    #Start compilation
$ source ~/catkin_ws/devel/setup.bash #Refresh the bad environment

Note: before compiling catkin, you need to go back to the workspace directory_ Make will not compile successfully in other paths. After the compilation is completed, if a new target file is generated (not originally), it is generally followed by the source to refresh the environment, so that the system can find the ROS executable file just compiled and generated. This detail is easy to be omitted, resulting in errors such as unable to open the executable file.

catkin_ The make command also has some optional parameters, such as:

catkin_make [args]
  -h, --help            Help information
  -C DIRECTORY, --directory DIRECTORY
                        Path to workspace (Default to '.')
  --source SOURCE       src Path of (Default to'workspace_base/src')
  --build BUILD         build Path of (Default to'workspace_base/build')
  --use-ninja           use ninja replace make
  --use-nmake           use nmake take'make
  --force-cmake         force cmake，Even if already cmake too
  --no-color            Disable color output(Only right catkin_make and CMake take effect)
  --pkg PKG [PKG ...]   Only for one PKG conduct make
  --only-pkg-with-deps  ONLY_PKG_WITH_DEPS [ONLY_PKG_WITH_DEPS ...]
                        Will specify package White list CATKIN_WHITELIST_PACKAGES，
                        In the white list package. The environment variable exists in CMakeCache.txt. 
  --cmake-args [CMAKE_ARGS [CMAKE_ARGS ...]]
                        Pass to CMake Parameters of
  --make-args [MAKE_ARGS [MAKE_ARGS ...]]
                        Pass to Make Parameters of
  --override-build-tool-check
                        Used to cover errors caused by different compilation tools

2.2 Catkin workspace

Catkin workspace is a directory for creating, modifying, and compiling catkin packages. Catkin's workspace is intuitively described as a warehouse loaded with various projects of ROS, which is convenient for system organization, management and call. In the visual graphical interface is a folder. The ROS code we write is usually placed in the workspace. This section introduces the structure of catkin workspace.

2.2.1 initializing catkin workspace

After introducing the catkin compilation system, let's establish a catkin workspace. First, we need to create an initial catkin on the computer_ WS / path, which is also the highest level of catkin workspace structure. Enter the following instructions to complete the initial creation.

$ mkdir -p ~/catkin_ws/src　　
$ cd ~/catkin_ws/
$ catkin_make #Initialize workspace

The first line of code directly creates the second level folder src, which is where we put the ROS package. The second line of code makes the process enter the workspace, and then catkin_make.

Note: 1 catkin_ The make command must be executed on the workspace path 2 The original initialization command is catkin_init_workspace remains

2.2.2 structure introduction

The structure of catkin is very clear. The specific structure diagram of catkin workspace is as follows. At first glance, catkin workspace looks extremely complex, but in fact, it is not. The structure of catkin workspace is actually very clear.

Use the tree command in the workspace to display the file structure.

$ cd ~/catkin_ws
$ sudo apt install tree
$ tree

The display result is very long, as long as there is a tree structure.

You can see the structure of catkin workspace through the tree command. It includes three paths: src, build and devel. Other paths may also be included under some compilation options. But these three folders are the default of catkin compilation system. Their specific functions are as follows:

Src /: catkin package of ROS (source code package)
Build /: cache information and intermediate files of catkin (CMake)
devel /: generated target files (including header files, dynamic link libraries, static link libraries, executable files, etc.), environment variables

The compilation process is shown in the figure below:

Catkin workspace is basically the above structure. Package is the basic unit of catkin workspace. When developing ROS, we write code and then catkin_make, the system will complete all the compilation and construction work. As for the more detailed package content, we will continue to introduce it in the next section.

2.3 Package

The definition of package in ROS is more specific. It is not only a software package on Linux, but also the basic unit of catkin compilation. We call catkin_ The objects compiled by make are packages of ROS, that is, any ROS program can be compiled only when it is organized into packages. Therefore, package is also the place where ROS source code is stored. Any ROS code, whether C + + or Python, should be put into package so that it can be compiled and run normally.

A package can compile multiple object files (ROS executable, dynamic and static library, header file, etc.).

2.3.1 package structure

Common files and paths under a package include:

  ├── CMakeLists.txt    #Compilation Rules for package (required)
  ├── package.xml       #Description of package (required)
  ├── src/              #Source code file
  ├── include/          #C + + header file
  ├── scripts/          #Executable script
  ├── msg/              #Custom message
  ├── srv/              #Custom service
  ├── models/           #3D model file
  ├── urdf/             #urdf file
  ├── launch/           #launch file

The package is defined as cmakelists Txt and package XML, these two files are essential in the package. Before compiling, catkin compiling system must first parse these two files. These two files define a package.

CMakeLists.txt: defining the package name, dependency, source file, target file and other Compilation Rules of the package is an indispensable component of the package
package.xml: describes the package name, version number, author, dependency and other information of the package. It is an indispensable component of the package
src /: stores the source code of ROS, including C + + source code and (. cpp) and Python module(.py)
include /: store the header file corresponding to the C + + source code
Scripts /: store executable scripts, such as shell script (. sh), Python script (. py)
msg /: store messages in custom format (. msg)
srv /: a service (. srv) that stores custom formats
Models /: store 3D models of robots or simulation scenes (. SDA,. STL,. DAE, etc.)
urdf /: store the model description of the robot (. urdf or. xacro)
Launch /: store the launch file (. Launch or. xml)

Usually, ROS files are organized according to the above form, which is a conventional naming habit and is recommended to be followed. In the above path, only cmakelists Txt and package XML is required, and the rest paths are determined according to whether the software package needs it or not.

2.3.2 creation of package

Create a package in catkin_ Under WS / SRC, catkin is used_ create_ PKG command, usage:
catkin_create_pkg package depends
Where package is the package name and dependencies is the dependent package name, which can depend on multiple software packages.

For example, create a new package called test_pkg, depending on roscpp, rospy, STD_ Msgs (common dependency).

$ catkin_create_pkg test_pkg roscpp rospy std_msgs

This will create a new test in the current path_ PKG software package, including:

  ├── CMakeLists.txt
  ├── include
  │   └── test_pkg
  ├── package.xml
  └── src

catkin_create_pkg helps you complete the initialization of the software package and fill in cmakelists Txt and package XML, and the dependencies are filled into these two files.

2.3.3 package related commands

rospack is a tool for package management. The usage of the command is as follows:

rostopic command	effect
rospack help	Displays the usage of rospack
rospack list	List all package s on this machine
rospack depends [package]	Displays the dependent packages of the package
rospack find [package]	Locate a package
rospack profile	Refresh the location records of all package s

If the above command defaults to package, it defaults to the current directory (if the current directory contains package.xml)

roscd

The roscd command is similar to the cd of Linux system. The improvement is that roscd can be directly cd to the software package of ROS.

rostopic command	effect
roscd [pacakge]	Path from cd to ROS package

rosls

rosls can also be regarded as an improved version of Linux instruction ls, which can directly the contents of lsROS package.

rosls command	effect
rosls [pacakge]	List files under package

rosdep

rosdep is a command-line tool for managing ROS package dependencies. Its usage is as follows:

rosdep command	effect
rosdep check [pacakge]	Check whether the package dependency is satisfied
rosdep install [pacakge]	Dependencies for installing packge
rosdep db	Generate and display dependent databases
rosdep init	Initialize source in / etc/ros/rosdep
rosdep keys	Check whether the package dependency is satisfied
rosdep update	Update the local rosdep database

A commonly used command is rosdep install -- from paths src -- ignore src -- rosdistro = kinetic - y, which is used to install the dependencies of all packages under the src path in the workspace (specified by the package.xml file).

2.4 CMakeLists.txt

2.4.1 CMakeLists.txt function

CMakeLists.txt was originally the rule file of cmake compilation system, while catkin compilation system basically followed the compilation style of cmake, but added some macro definitions for ROS project. So in terms of writing, catkin's cmakelists Txt is basically consistent with cmake.

This file directly specifies which packages the package depends on, which targets to compile and generate, how to compile and so on. So cmakelists Txt is very important. It specifies the rules from the source code to the target file. The catkin compilation system will first find cmakelists under each package Txt, and then compile and build according to the rules.

2.4.12CMakeLists.txt writing method

CMakeLists. The basic syntax of TXT is still based on CMake, and Catkin adds a small number of macros. The overall structure is as follows

cmake_minimum_required() #Version number of CMake 
project()                #entry name 
find_package()           #Find other cmake / catkin packages needed for compilation
catkin_python_setup()    #Catkin adds a new macro and opens the support of catkin's Python Module
add_message_files()      #Add a new macro to catkin and add a custom Message/Service/Action file
add_service_files()
add_action_files()
generate_message()       #catkin adds a new macro to generate msg/srv/action interfaces in different languages
catkin_package()         #catkin adds a new macro to generate the cmake configuration of the current package, which can be called by other software packages that depend on this package
add_library()            #Build library
add_executable()         #Generate executable binaries
add_dependencies()       #The definition target file depends on other target files to ensure that other targets have been built
target_link_libraries()  #link
catkin_add_gtest()       #catkin adds new macros to generate tests
install()                #Install to this machine

2.4.3 CMakeLists example

To explain cmakelists in detail Txt. We take the package of turtle as an example. Readers can check it under the package of tuetlesim in roscd and in the package of Turtle / cmakelists Txt is written as follows:

cmake_minimum_required(VERSION 2.8.3)
#CMake at least version 2.8.3

project(turtlesim)
#You can use the ${project name} variable in the subsequent project name

find_package(catkin REQUIRED COMPONENTS geometry_msgs message_generation rosconsole roscpp roscpp_serialization roslib rostime std_msgs std_srvs)
#cmake macro, which specifies other pacaks that depend on, actually generates some environment variables, such as < name >_ FOUND, <NAME>_ INCLUDE_ DIRS, <NAME>_ LIBRARYIS
#catkin here is a must and depends on the rest of the geometry_msgs... As component

find_package(Qt5Widgets REQUIRED)
find_package(Boost REQUIRED COMPONENTS thread)

include_directories(include ${catkin_INCLUDE_DIRS} ${Boost_INCLUDE_DIRS})
#Specify the header file path of C + +
link_directories(${catkin_LIBRARY_DIRS})
#Specifies the path to the linked library

add_message_files(DIRECTORY msg FILES
Color.msg Pose.msg)
#Custom msg file

add_service_files(DIRECTORY srv FILES
Kill.srv
SetPen.srv
Spawn.srv
TeleportAbsolute.srv
TeleportRelative.srv)
#Custom srv file

generate_messages(DEPENDENCIES geometry_msgs std_msgs std_srvs)
#In add_message_files,add_ service_ This sentence must be added after the files macro to generate the srv msg header file / module. The generated file is located in devel/include

catkin_package(CATKIN_DEPENDS geometry_msgs message_runtime std_msgs std_srvs)
# catkin macro command, which is used to configure the package configuration file and CMake file of ROS
# This command must be in add_library() or add_ Before executable (), the function has 5 optional parameters:
# (1) INCLUDE_DIRS - include path of export package
# (2) LIBRARIES - export libraries in the project
# (3) CATKIN_ Demands - other catkin projects on which this project depends
# (4) Demands - the non catkin CMake project on which the project depends.
# (5) CFG_EXTRAS - other configuration options

set(turtlesim_node_SRCS
src/turtlesim.cpp
src/turtle.cpp
src/turtle_frame.cpp
)
set(turtlesim_node_HDRS
include/turtlesim/turtle_frame.h
)
#Specify turnlesim_ node_ SRCS,turtlesim_node_HDRS variable

qt5_wrap_cpp(turtlesim_node_MOCS ${turtlesim_node_HDRS})

add_executable(turtlesim_node ${turtlesim_node_SRCS} ${turtlesim_node_MOCS})
# Specifies the executable target, turnlesim_ node
target_link_libraries(turtlesim_node Qt5::Widgets ${catkin_LIBRARIES} ${Boost_LIBRARIES})
# Specify linked executable
add_dependencies(turtlesim_node turtlesim_gencpp)

add_executable(turtle_teleop_key tutorials/teleop_turtle_key.cpp)
target_link_libraries(turtle_teleop_key ${catkin_LIBRARIES})
add_dependencies(turtle_teleop_key turtlesim_gencpp)

add_executable(draw_square tutorials/draw_square.cpp)
target_link_libraries(draw_square ${catkin_LIBRARIES} ${Boost_LIBRARIES})
add_dependencies(draw_square turtlesim_gencpp)

add_executable(mimic tutorials/mimic.cpp)
target_link_libraries(mimic ${catkin_LIBRARIES})
add_dependencies(mimic turtlesim_gencpp)
# Also specify executable targets, links, and dependencies

install(TARGETS turtlesim_node turtle_teleop_key draw_square mimic
RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION})
# Install the target file to the local system

install(DIRECTORY images
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
FILES_MATCHING PATTERN "*.png" PATTERN "*.svg")

This is an example. Don't recite it. Just know the principle.

2.5 package.xml

package.xml is also a necessary file for catkin package. It is the description file of the software package. In the earlier version of ROS (rosbuild compilation system), this file is called manifest XML, which is used to describe the basic information of pacakge. If you see some ROS projects on the Internet that contain manifest XML, then it is mostly a project before the hydro version.

2.5.1 package.xml function

pacakge.xml contains the name, version number, content description, maintenance personnel, software license, compilation and construction tool, compilation dependency, operation dependency and other information of the package.
In fact, the reason why rospack find, rosdep and other commands can quickly locate and analyze the dependency information of packages is that they directly read the packages in each package XML file. It provides users with a channel to quickly understand a package.

2.5.2 package.xml writing method

pacakge.xml follows the writing method of xml tag text. Due to version change, there are two formats coexisting (format1 and format2), but there is little difference. The package of the old version (format1) xml usually contains the following tags:

<pacakge>           Root tag file  
<name>              Package name  
<version>           Version number  
<description>       Content description  
<maintainer>        Maintainer 
<license>           software license  
<buildtool_depend>  Compile build tools, usually catkin  
<build_depend>      Compile dependencies, and Catkin Medium  
<run_depend>        Run dependency

Note: 1-6 are mandatory tags, 1 is the root tag, and all other tags are nested, 2-6 are various attributes of the package, and 7-9 are compilation related information.

In the new version (format2), the label included is:

<pacakge>               Root tag file  
<name>                  Package name  
<version>               Version number  
<description>           Content description  
<maintainer>            Maintainer 
<license>               software license  
<buildtool_depend>      Compile build tools, usually catkin    
<depend>                The specified dependency is the dependency required for compilation, export and operation. It is the most commonly used
<build_depend>          Compile dependencies  
<build_export_depend>   Export dependencies
<exec_depend>           Run dependency
<test_depend>           Test case dependencies  
<doc_depend>            Document dependencies

You can see the new version of package XML format is added, < build_ export_ depend>,<exec_ depend>,<doc_ Depend >, which is equivalent to subdividing the previous build and run dependency descriptions.

At present, Indigo, Kinetic, Lunar and other versions of ROS support both versions of package XML, so whatever format you choose is OK.

2.6 Metapackage

In some ROS teaching materials and blogs, you may also see a concept of Stack (function package set), which refers to putting multiple software packages with similar or even interdependent functions into one set. However, the concept of Stack was cancelled after Hydro and replaced by Metapackage. Although the vest has been changed, its function has not changed. It puts some similar functional modules and software packages together.

The common metapacaks in ROS are:

Metapackage name	describe	link
navigation	Set of navigation related function packages	https://github.com/ros-planning/navigation
moveit	Function package set related to motion planning (mainly manipulator)	https://github.com/ros-planning/moveit
image_pipeline	Function package set related to image acquisition and processing	https://github.com/ros-perception/image_common
vision_opencv	Function package set of ROS and OpenCV interaction	https://github.com/ros-perception/vision_opencv
turtlebot	Turtlebot robot related function package set	https://github.com/turtlebot/turtlebot
pr2_robot	pr2 robot driving function package	https://github.com/PR2/pr2_robot

The above lists some common function packages, such as navigation and turnbot, which are used for certain functions. Take navigation metapackage (the name stack is still used in the official introduction) as an example, which includes the following software packages:

Package name	function
navigation	Metapackage, which depends on all of the following packages
amcl	location
fake_localization	location
map_server	Provide map
move_base	Path planning node
nav_core	Interface class for path planning
base_local_planner	Local planning
dwa_local_planner	Local planning

For the specific function introduction, we will leave it to Chapter 9. Here we only look at the software package navigation. This navigation is a simple package. There are only a few files in it, but it depends on all other software packages. Catkin compilation system will understand that these software packages belong to navigation meta pacakge.

This reason is not difficult to understand. For example, when installing ROS, we use sudo apt get install ROS kinetic desktop full command. Because it relies on all core components of ROS, we can install the whole ROS during installation.

2.6.2 Metapackage writing method

Taking ROS Academy for beginners as an example, we introduce the writing method of meteapckage. In the teaching package, there is a ROS Academy for beginners software package, which is a metapacakge, in which there are and only two files: cmakelists Txt and packge xml.

CMakeLists.txt is written as follows:

cmake_minimum_required(VERSION 2.8.3)
project(ros_academy_for_beginners)
find_package(catkin REQUIRED)
catkin_metapackage()   #Declare that this package is a metapacakge

pacakge.xml is written as follows:

<package>
    <name>ros_academy_for_beginners</name>
    <version>17.12.4</version>
    <description>
        --------------------------------------------------------------------------
        A ROS tutorial for beginner level learners. This metapacakge includes some
        demos of topic, service, parameter server, tf, urdf, navigation, SLAM...
        It tries to explain the basic concepts and usages of ROS.
        --------------------------------------------------------------------------
    </description>
    <maintainer email="chaichangkun@163.com">Chai Changkun</maintainer>
    <author>Chai Changkun</author>
    <license>BSD</license>  
    <url>http://http://www.droid.ac.cn</url>

    <buildtool_depend>catkin</buildtool_depend>

    <run_depend>navigation_sim_demo</run_depend>  <!--Pay attention here run_depend Tag to set other packages as dependencies-->
    <run_depend>param_demo</run_depend>
    <run_depend>robot_sim_demo</run_depend>
    <run_depend>service_demo</run_depend>
    <run_depend>slam_sim_demo</run_depend>
    <run_depend>tf_demo</run_depend>
    <run_depend>topic_demo</run_depend>

    <export>    <!--There needs to be export and metapacakge Label, pay attention to this fixed writing-->
        <metapackage/>
    </export>
</package>

The differences between the above two files in metapacakge and ordinary pacakge are:

CMakeLists.txt: catkin is added_ Metapackage() macro, which specifies that this software package is a metapackge.
package. xml:<run_ The dependent > tag lists all software packages as dependencies and adds a label declaration to the tag.

metapacakge may be useful when we actually develop a large project

2.7 other common document types

There are many other common file types in the package of ROS. Here is a summary.

2.7.1 launch file

Launch files are generally in Launch or At the end of xml, it packages the program that ROS needs to run and starts it with a command. Generally, the launch file will specify which executable programs under which packages to start, which parameters to start, and some management and control commands.
The launch file is usually placed in the launch / path of the software package.
See Section 3.2 for the specific writing method of launch file.

2.7.2 msg/srv/action file

There may be some custom message / service / action files in the ROS program, and the data structure designed for the program sender. Such files are based on msg,. srv,. The end of action is usually placed under the msg/,srv/,action / path of the package.

See Section 3.4 for the writing method of msg file and section 3.6 for the writing method of srv file.

2.7.3 urdf/xacro file

urdf/xacro file is the description file of robot model urdf or Xacro ends. It defines the information of the robot's links and joints, as well as the position and angle between them. The physical connection information of the robot can be expressed through urdf file. And displayed in visual debugging and simulation.

See Chapter 7 for the writing method of urdf file.

2.7.4 yaml file

Yaml file generally stores the parameter information that ROS needs to load and the configuration of some attributes. It is usually read in the launch file or program Yaml file and load the parameters into the parameter server. Usually we store yaml files in param / path

2.7.5 dae/stl file

dae or stl files are 3D model files, which are usually referenced by urdf or simulation environment of robot. They describe the 3D model of robot. Compared with the properties simply defined in urdf file, dae/stl file can define complex models, and can directly export robot assembly models from solidworks or other modeling software, so as to display more accurate shapes.

2.7.6 rviz documents

Rviz file is essentially a fixed format text file, which stores the configuration of rviz window (which controls, perspectives and parameters are displayed). Usually, the rviz file does not need to be modified manually. Instead, it is directly saved in the rviz tool and read directly the next time it runs.

The content of the second chapter is just to understand. We have little practical operation, and basically all are theories.

o end. It defines the information of the robot's links and joints, as well as the position and angle between them. The physical connection information of the robot can be expressed through urdf file. And displayed in visual debugging and simulation.

See Chapter 7 for the writing method of urdf file.

2.7.4 yaml file

2.7.5 dae/stl file

2.7.6 rviz documents

The content of the second chapter is just to understand. We have little practical operation, and basically all are theories.

Source: https://www.kancloud.cn/zhouws/robot_ustc_mooc/2153682

Topics: Machine Learning AI Autonomous vehicles

Programmer Think

ROS learning note file system

ROS learning notes (II) file system

2.1 Catkin development system

2.1.1 Catkin features

2.1.2 Catkin working principle

2.1.3 using catkin_ Compile with make

2.2 Catkin workspace

2.2.1 initializing catkin workspace

2.2.2 structure introduction

2.3 Package

2.3.1 package structure

2.3.2 creation of package

2.3.3 package related commands

roscd

rosls

rosdep

2.4 CMakeLists.txt

2.4.1 CMakeLists.txt function

2.4.12CMakeLists.txt writing method

2.4.3 CMakeLists example

2.5 package.xml

2.5.1 package.xml function

2.5.2 package.xml writing method

2.6 Metapackage

2.6.2 Metapackage writing method

2.7 other common document types

2.7.1 launch file

2.7.2 msg/srv/action file

2.7.3 urdf/xacro file

2.7.4 yaml file

2.7.5 dae/stl file

2.7.6 rviz documents

2.7.4 yaml file

2.7.5 dae/stl file

2.7.6 rviz documents

Hot Topics