TL;DR:
A launch file starts many nodes at once and says how each one is configured.
Parameters are named settings, such as a serial port or a speed limit, kept in a YAML file so code does not change.
Namespaces put a prefix on names so two copies of the same node, like two cameras, do not collide.
A small robot might need a motor driver, a LiDAR driver, a camera driver and a controller. Opening four terminals and typing four long commands every time you test is slow, and one forgotten option sends the robot the wrong way. Launch files fix this.
What a launch file does
A launch file is a short program that starts a set of nodes together and gives each one its settings. In ROS 2, launch files are usually written in Python, though XML and YAML forms also exist. One command, ros2 launch <package> <file>, then brings up the whole robot.
The launch system also watches the processes it started. You can ask it to restart a node if it exits, and Ctrl+C in the launch terminal shuts everything down together.
Parameters: settings that are not in the code
A parameter is a named value that belongs to a node: a serial port name, a baud rate, a maximum speed, a frame name. The node declares it with a default and reads the value when it starts. A node can read different values in different runs without being edited and rebuilt.
Parameters have types such as integer, floating point, string, boolean and lists of these. Setting a float parameter to a string is an error, so mistakes show up at startup instead of mid-drive.
Worked example: launching a driver with a parameter file
Say you have a motor driver node called motor_driver in a package called my_robot. It reads a serial port, a wheel radius and a speed limit. First the parameter file, motor.yaml:
motor_driver:
ros__parameters:
port: "/dev/ttyUSB0"
wheel_radius_m: 0.04
max_speed_mps: 0.30The top key must match the node's name, and ros__parameters is required by the format. Now the launch file, bringup.launch.py:
from launch import LaunchDescription
from launch_ros.actions import Node
from ament_index_python.packages import get_package_share_directory
import os
def generate_launch_description():
params = os.path.join(
get_package_share_directory('my_robot'), 'config', 'motor.yaml')
return LaunchDescription([
Node(
package='my_robot',
executable='motor_driver',
name='motor_driver',
parameters=[params],
output='screen',
),
])Run ros2 launch my_robot bringup.launch.py. The driver starts with those values. To check, run ros2 param get /motor_driver max_speed_mps and you should see 0.3.
Check the numbers make physical sense. A wheel of radius 0.04 m has circumference 2π × 0.04 ≈ 0.251 m. A top speed of 0.30 m/s needs 0.30 / 0.251 ≈ 1.19 revolutions per second, about 72 revolutions per minute. If your motor and gearbox cannot turn at that rate, the limit is meaningless, and if the motor can go far faster, this limit is what keeps a first test slow and safe.
Safety: Set a low speed limit in the parameter file for first tests, and put the robot on blocks so the wheels spin freely. Only raise the limit after the robot has behaved correctly at low speed.
Namespaces: two of the same thing
Suppose the robot has a front camera and a rear camera, both running the same driver. Both would publish on /image_raw and clash. A namespace adds a prefix to the node and its topics. Add namespace='front' to one Node(...) and namespace='rear' to the other, and you get /front/image_raw and /rear/image_raw.
The parameter file key then changes too, because the node's full name becomes /front/camera_driver. Another option is to write /**: as the top key, which matches any node name. The same file can then configure both cameras.
You can also remap a topic, changing the name a node uses without changing its code, so a driver that publishes /scan can feed a node that expects /lidar/points.
Where it goes wrong
Wrong node name in the YAML. The file loads, nothing is set, and the node quietly uses its defaults. Print the parameter to confirm.
Forgot to install the config file. Launch files find the YAML from the installed package directory, so rebuild and source the workspace after adding it.
Wrong units. A parameter has no unit attached. Put the unit in the name, as in
wheel_radius_m.Start order assumptions. Nodes start at about the same time. A node that needs another to be ready should wait or retry.
Port permissions. On Linux, a serial device may need your user to be in the right group before the driver can open it.
How real robots use it
Real robots layer launch files. A top-level file includes one for the hardware drivers, one for localization and one for navigation, and passes arguments such as whether to use a simulator. The same launch file then works on a real robot and in a simulator, which is a large part of why roboticists test in a simulator first.
Try it yourself
Take the demo talker and listener nodes that ship with ROS 2. Write a launch file that starts both, once in a namespace called a and once in a namespace called b, then list the topics. You should see two separate sets. Then give one of them a parameter file and read the value back with the parameter tools.
Frequently asked questions
Can I change a parameter while the node is running?
Yes, if the node allows it. Use ros2 param set. The node decides whether to accept the change, and the value is lost when it restarts unless you also edit the file.
Launch file or just a shell script?
A script only starts processes. A launch file also handles parameters, namespaces, remapping, conditions and shutdown, which is why it is the standard choice.
Get started
