Glossary

Fictionlab > Glossary > ROS 2 launch file

ROS 2 launch file

ROS 2 launch file – definition

A ROS 2 launch file is a configuration or programmatic description that starts, configures, and coordinates multiple ROS 2 nodes as one application. It describes which nodes shall run, their parameters, namespaces, remappings, environment variables, conditions, and event-driven startup sequencing. Launch files are processed by the ROS 2 launch framework and commonly use the launch_ros package for ROS-specific actions.

In mobile robotics, a launch file provides a repeatable way to start a UGV software stack. A single command can bring up motor control, wheel odometry, sensor drivers, robot state publication, localization, SLAM, and navigation. This is important for Leo Rover and Raph Rover deployments because autonomous operation requires several independent ROS 2 processes to use consistent frames, parameters, topics, and namespaces.

ROS 2 supports Python, XML, and YAML launch descriptions. Python is the most flexible format because it supports programmatic conditions, substitutions, event handlers, and reusable launch descriptions. XML and YAML formats are useful where a declarative configuration is preferred. Source: ROS 2 documentation: launch file formats.

How ROS 2 launch files work

A launch file generates a LaunchDescription. This description contains actions evaluated by the ROS 2 launch system at runtime. Actions can start ROS nodes, include other launch files, declare arguments, set environment variables, or react to process events.

For a mobile robot, the launch process usually separates hardware-facing components from higher-level autonomy components. This makes it possible to start the base driver without starting navigation, or to replace a physical LiDAR driver with a simulator while preserving the same topic interface.

  • Node actions start executables from ROS 2 packages.
  • Launch arguments expose configurable values such as a map file, simulation mode, namespace, or parameter file.
  • Parameter files provide node-specific runtime settings in YAML.
  • Remappings connect a node’s expected topic name to the topic used by a specific sensor or robot driver.
  • Namespaces isolate multiple robots operating in one ROS graph.
  • Included launch files allow a project to compose hardware, perception, and navigation subsystems.

The following Python example starts a robot state publisher and a differential-drive base node. It also passes the robot description from a URDF or Xacro-generated file and uses a parameter file for the base controller.

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',
            name='robot_state_publisher',
            parameters=[{
                'robot_description': '<robot URDF content>'
            }]
        ),
        Node(
            package='leo_bringup',
            executable='base_driver',
            name='base_driver',
            output='screen',
            parameters=['config/base_driver.yaml'],
            remappings=[
                ('cmd_vel', '/cmd_vel'),
                ('odom', '/odom')
            ]
        )
    ])

A launch file is normally executed with the ROS 2 CLI:

ros2 launch my_robot_bringup rover.launch.py

Key interfaces in a UGV launch configuration

A launch file does not define the semantics of ROS messages, but it determines which nodes publish and consume them. The interfaces selected in the launch configuration must be compatible across the UGV stack.

Function Typical ROS 2 interface Purpose in a mobile robot
Velocity command geometry_msgs/msg/Twist on /cmd_vel Sends linear and angular velocity commands to a differential-drive base.
Wheel odometry nav_msgs/msg/Odometry on /odom Provides estimated motion for localization and navigation.
Laser scan sensor_msgs/msg/LaserScan on /scan Supports obstacle detection, mapping, and localization.
Transform tree tf2_msgs/msg/TFMessage on /tf and /tf_static Connects frames such as map, odom, base_link, and sensor frames.
Global position sensor_msgs/msg/NavSatFix on /fix Provides GNSS data for outdoor localization workflows.

Message definitions are maintained in the ROS 2 common interface packages. Source: ROS 2 common interfaces documentation.

Launch files for Leo Rover and Raph Rover

Leo Rover uses a four-wheel differential-drive chassis and supports ROS 2 deployments on its integrated Raspberry Pi compute unit. A launch configuration should start the platform driver and ensure that dependent components wait for required hardware or services when necessary, then expose standard mobile-robot interfaces such as velocity commands, odometry, joint states, and transforms. The exact driver package and parameters depend on the installed Leo Rover software image and attached peripherals. Source: Leo Rover technical documentation.

For a Leo Rover navigation stack, a top-level launch file commonly includes the following subsystems:

  • a base driver publishing odometry and accepting /cmd_vel;
  • a LiDAR or depth-camera driver publishing obstacle data;
  • robot_state_publisher for the URDF frame tree;
  • a localization or SLAM node publishing the map to odom transform;
  • Nav2 servers and lifecycle management for planning, control, behavior, and costmaps.

Raph Rover follows the same ROS 2 launch principles, but its larger payload capacity can support additional compute hardware and sensor payloads. A project may launch camera perception, GNSS/RTK processing, LiDAR mapping, and telemetry nodes in separate included launch files. Keeping these modules separate reduces coupling and makes field debugging easier.

Parameters, namespaces, and reproducibility

Launch files should pass operational settings through version-controlled YAML parameter files rather than hard-code them in node executables. This is particularly important for sensor extrinsics, wheel geometry, controller limits, frame names, and navigation costmap settings.

base_driver:
  ros__parameters:
    wheel_separation: 0.28
    wheel_radius: 0.0625
    odom_frame: odom
    base_frame: base_link
    publish_tf: true

The values above are an example only. Wheel separation and wheel radius must match the physical platform configuration and should be verified against the applicable hardware documentation. Incorrect values cause systematic odometry errors.

For multi-robot experiments, launch files should apply a unique namespace to every robot and use relative topic names or explicit remappings. This prevents collisions between topics such as cmd_vel and scan. TF topics and frame identifiers require additional care: frame IDs are not automatically isolated by ROS namespaces and need a consistent prefix strategy.

ROS 1 and ROS 2 differences

ROS 1 commonly uses XML launch files processed by roslaunch. ROS 2 uses the separate launch framework and supports Python, XML, and YAML front ends. ROS 2 launch files also integrate with ROS 2 parameters, lifecycle nodes, DDS-based communication, and composable nodes. A ROS 1 .launch file cannot be assumed to work unchanged in ROS 2.

ROS 2 package metadata is declared in package.xml according to the package manifest specification. Packages must install launch files so that they can be discovered by ros2 launch; for CMake packages, this is commonly done with a CMake install rule. Source: ROS 2 launch documentation and REP-149: Package manifest format.

See also