Many ROS packages come with "launch files", which you can run with:
$ roslaunch package_name file.launch
These launch files usually bring up a set of nodes for the package that provide some aggregate functionality.
To find out more about the main roslaunch tool and other command-line tools, please consult:
roslaunch uses XML files that describe the nodes that should be run, parameters that should be set, and other attributes of launching a collection of ROS nodes. For a specification of this XML format, please see:
roslaunch was designed to fit the ROS architecture of complexity via composition. Understanding roslaunch's architecture will give you better insight in how to construct your .launch files and better debug remote vs. local launches.
A simple usage example of the Python API can be found here:
roscore is a specialization of the roslaunch tool for bringing up the "core" ROS system. A roslaunch will automatically start roscore if it detects that it is not already running (unless the --wait argument is supplied). For more information, please see the roscore documentation. Note: due to a race condition, roslaunch should not be used to guarantee a singleton instance of roscore.
The launch file syntax itself is stable, and every effort will be made to provide backwards compatibility with new features.
The code API of roslaunch is very unstable and should not be used directly. In order to support the new features that are being planned, it may be necessary to make major, incompatible changes to the programmatic API.
There are many new features being planned for roslaunch. These include new features within the launch file syntax, GUI tools for interacting with launch files more effectively, network API, better coordination between separate launch files, and more.
Ref. SIG for roslaunch
- Roslaunch tips for large projects
This tutorial describes some tips for writing roslaunch files for large projects. The focus is on how to structure launch files so they may be reused as much as possible in different situations. We'll use the 2dnav_pr2 package as a case study.
- How to Roslaunch Nodes in Valgrind or GDB
- How to profile roslaunch nodes
Since roslaunch XML allows inline YAML parsing, it is beneficial to have syntax (highlighting and indentation) support in your favorite editor.
The roslaunch_add_file_check CMake macro can be used to check launch files for common errors such as missing arguments, dependencies, packages, or nodes.
The following is how you would check all *.launch files in a package's "launch" directory:
find_package(catkin REQUIRED COMPONENTS roslaunch) roslaunch_add_file_check(launch)
NOTE: roslaunch_add_file_check takes only one directory at a time.
The check runs during tests. So something like following is cleaner.
if (CATKIN_ENABLE_TESTING) find_package(roslaunch REQUIRED) roslaunch_add_file_check(launch) endif()
Since you need to find roslaunch in find_package as above, you better explicitly add a dependency in your package.xml as following:
The macro accepts either a single directory or file argument. Basically, it adds additional test targets into catkin generated Makefile.
Options for check during Catkin
New in K Turtle
Pass an optional argument "USE_TEST_DEPENDENCIES" to roslaunch_add_file_check as the following example, if your package defines dependency for the tests (e.g. test_depend). This avoids issues that happen during tests such as this issue.
find_package(catkin REQUIRED COMPONENTS roslaunch) roslaunch_add_file_check(launch USE_TEST_DEPENDENCIES)
A few graphical tools are available to support launch functionalities of ROS.
rqt_launch (very experimental) can run launch files.
rqt_launchtree allows you to interactively introspect launch files.
roslaunch_to_dot converts a launch file tree to a graph and save into a dot file.