What are launch files?
A launch file is one file that starts several programs at once, in the right order, with the right settings. Instead of opening three terminals and typing three commands, you type one: ros2 launch.
The problem launch files solve
In the previous RViz2 laboratory, we had to start several components manually: robot_state_publisher, joint_state_publisher_gui, and RViz2. We also had to source the workspace in the required terminals and configure the robot description and RViz2. This works for a small example, but as a robot application grows, repeating these steps becomes inconvenient and error-prone.
A real robot may involve sensors, controllers, localization, navigation, visualization, and many parameters. Launch files let us describe this complete startup process once and reproduce it consistently.
Think of a movie theater remote that has one “Start Movie” button. Press it once, and it turns on the projector, dims the lights, and starts the sound system together, in order. A launch file is that one button for your robot software.
Watch both ways happen, side by side
InteractiveA launch file is just a list
At its simplest, a launch file is a description of the operations that ROS 2 should perform. In a Python launch file, these operations are collected into a LaunchDescription. The description can contain nodes, processes, parameters, included launch files, and other launch actions.
For our visualization example, think of the launch description as an instruction sheet: start the robot state publisher, start the joint-state publisher, start RViz2, and give each component the configuration it needs.
Build your own launch file
InteractiveUncheck rviz2 and run it again. Notice the code shrinks, and only two nodes start. That is the entire idea of a LaunchDescription: it is a list, and only what is on the list runs.
Sometimes startup order matters
Not every component needs to start at exactly the same moment. Some components can start independently, while others may depend on another component or event being available first. A launch description can express this startup behavior instead of leaving the entire sequence to manual terminal commands.
Startup order and data availability are related, but they are not the same thing. Starting one process first does not automatically guarantee that all of its data is already available. ROS 2 components communicate asynchronously, so a dependency may need a suitable event or readiness mechanism rather than an arbitrary delay.
Think of a workshop where one machine produces a part that another machine needs. You may want the first machine started before the second, but what really matters is whether the required part or signal is available. ROS 2 launch gives us tools to describe this kind of startup relationship more reliably than simply guessing with a fixed delay.
Same dependency, three startup strategies
InteractiveThis animation illustrates the idea of startup dependencies. It is not claiming that RViz2 must always be started after robot_state_publisher, or that a process-start event automatically means its data is ready. The correct synchronization method depends on the actual dependency in the application.
① Start together: both operations are requested at approximately the same time. This can be completely appropriate when the components are independent. If one component provides information needed by another, however, that information may not be available immediately.
② Wait a fixed time: the second operation is delayed by a chosen amount of time. This is easy to understand, but the delay is only a guess about how long the first component will take to become ready. A delay that is too short may not solve the dependency; a delay that is too long simply adds unnecessary waiting.
③ React to an event: instead of guessing with a timer, the launch system can react to a meaningful launch event. This is useful when the application has a clearly defined event that should trigger the next operation. For data-level readiness, the correct solution depends on the specific ROS 2 components and dependency involved.
What can a launch file actually do?
A launch file is more than a shortcut for opening several terminals. It describes how a complete application should be started and managed.
Start components
- Start multiple ROS 2 nodes
- Start non-ROS processes when required
- Start several components as one application
Configure the system
- Provide ROS 2 parameters
- Describe startup dependencies and events
- Include and reuse other launch files
Think of a launch file as an instruction sheet for bringing up a robot application — not simply a list of terminal commands.
Two helper libraries, two jobs
Writing a launch file uses two libraries. One rule of thumb: one handles the launch file itself, the other knows specifically about ROS 2.
launch
- Runs and manages the launch file itself
- Connects it to the user and to other launch files
- Can start programs that are not even part of ROS 2
launch_ros
- The ROS 2 specific half
- Starts and manages ROS 2 nodes
- Sets ROS 2 parameters for those nodes
Do not put everything in one file
A launch file can hold as many nodes as you want, so it is tempting to put your robot’s entire setup into one giant file. Do not. Keep each launch file focused on one job. One file for visualization, one for navigation, one for a sensor. Then a bigger launch file can simply include the smaller ones, in whatever order they need.
Python, XML, or YAML?
Launch descriptions can be expressed using different formats. This course uses Python because Python gives us the full flexibility of a programming language when launch configurations become more advanced. It also makes concepts such as conditions, substitutions, event handling, and reusable launch logic easier to introduce.
The same idea, three formats
from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( package="robot_state_publisher", executable="robot_state_publisher", ) ])
<launch> <node pkg="robot_state_publisher" exec="robot_state_publisher" /> </launch>
# launch.yaml launch: - node: pkg: robot_state_publisher exec: robot_state_publisher
Python is a general-purpose programming language, so it gives us a convenient way to express more advanced launch behavior as the course progresses. XML and other declarative formats can still be useful when the launch description is simple and structured.