ROS Launch System

The launch system uses a declarative XML or Python syntax to specify which ROS nodes to start, their executable names, and their command-line arguments. This abstracts the manual process of running multiple ros2 run commands. Key elements include:

• <node> tags (XML) or Node descriptions (Python) define each process.
• Package and executable references are resolved automatically.
• Namespace assignment allows logical grouping of nodes.
• Output configuration controls where logs (stdout, stderr) are directed (e.g., to the console or a log file). This composition enables the definition of a complete, multi-process application as a single, reusable entity.

Launch files centralize runtime configuration by injecting parameters and remapping communication channels.

• Parameter Loading: Static or dynamic parameters can be loaded from YAML files or set directly via <param> tags or Parameter declarations. This ensures all nodes start with a consistent, version-controlled configuration.
• Topic/Service Remapping: The remap attribute allows you to redirect a node's published or subscribed topic names at launch time. For example, you can remap /camera/image_raw to /front_camera/image_raw without modifying the node's source code. This is essential for integrating nodes from different packages or avoiding namespace collisions in multi-robot systems.

Complex systems are built by composing smaller, modular launch files. The <include> tag (XML) or IncludeLaunchDescription action (Python) allows you to embed one launch file within another.

• Modularity: Break down a system launch (e.g., for an entire mobile robot) into sub-launches for perception, navigation, and manipulation.
• Parameter Passing: Arguments can be passed downward into included launch files, enabling flexible, parameterized compositions.
• Reusability: Common launch patterns (e.g., starting a sensor driver with standard configurations) can be written once and included across multiple projects. This promotes a DRY (Don't Repeat Yourself) principle in system orchestration.

The system supports runtime decision-making through arguments and conditional tags, making launch files adaptable to different robots or environments.

• Launch Arguments: Define variables (e.g., use_sim_time, robot_model) that can be set via the command line (ros2 launch my_package launch_file.py use_sim_time:=true) or programmatically.
• Conditional Execution: Use <if>, <unless> (XML) or IfCondition, UnlessCondition (Python) to start nodes or include other launch files based on the value of an argument. For example, you can conditionally launch a simulator-specific node only when use_sim_time is true.
• Substitution Evaluation: Use substitutions like $(var name) to evaluate arguments, environment variables, or Python expressions within the launch description, enabling dynamic string generation for node names or file paths.

The launch system is not just a static script; it is an event-driven process that can react to node lifecycle events.

• Process Monitoring: The launch system tracks the state of launched processes. It can be configured to restart nodes on exit or to shut down the entire launch if a critical node fails.
• Event Handlers: In Python launch files, you can define actions triggered by specific events (e.g., OnProcessStart, OnProcessExit). This allows for sophisticated startup sequences, such as waiting for a sensor node to advertise a topic before starting a perception node.
• ROS 2 Lifecycle Node Support: It provides native actions for starting and configuring ROS 2 Lifecycle Nodes, managing their state transitions (Unconfigured → Inactive → Active) in a deterministic order during system bring-up.

ROS 2 introduced a powerful, programmatic Python API for writing launch files, moving beyond the purely declarative XML format used in ROS 1.

• Programmatic Control: The launch and launch_ros Python modules allow you to use full Python logic (loops, conditionals, calculations) to generate launch descriptions dynamically.
• Action-Based Model: Launch descriptions are built by instantiating Action objects (e.g., Node, SetParameter, EmitEvent). This object-oriented approach makes complex launch logic more readable and testable.
• Introspection and Debugging: The Python API provides better tools for introspection, allowing developers to programmatically inspect the generated launch description before execution. This is a significant advancement for debugging large, parameterized robotic systems.

A ROS Node is the fundamental executable process within a ROS graph that performs computation. The launch system's primary function is to start and configure these nodes. Each node is typically designed to perform a single, modular function (e.g., sensor driver, planner, controller).

• Key Characteristics: Communicates via topics, services, actions, or parameters.
• Launch Role: Defined in a launch file using the <node> tag, where you specify the package, executable name, and configuration like remappings or parameters.
• Example: A lidar_driver_node publishes point cloud data to a /scan topic.

A ROS Parameter is a configuration value stored on a centralized parameter server that nodes can retrieve at runtime. The launch system is the standard tool for setting these parameters globally or for specific nodes.

• Static vs. Dynamic: Can be set at launch (static) or changed dynamically via services during operation.
• Launch Role: Defined using the <param> tag (for global parameters) or the <node> tag's parameters argument (for node-private parameters). Parameters can be loaded from YAML files for complex configurations.
• Use Case: Setting a robot's wheel diameter, maximum velocity, or sensor calibration offsets.

The ROS Graph is the runtime network of nodes, topics, services, and actions that represents the communication topology of a robotic system. A launch file is a blueprint for instantiating a specific graph.

• Visualization: Tools like rqt_graph can visualize the graph created by a launch file.
• Launch Role: By starting a collection of nodes and defining how they connect (via topic remapping), a launch file constructs the desired graph.
• Importance: Understanding the graph is essential for debugging communication issues and system architecture.

A ROS 2 Launch Argument is a variable defined in a Python launch file that allows for parameterization of the launch configuration. This makes launch files reusable and adaptable without modification.

• Declaration: Defined using DeclareLaunchArgument.
• Usage: Arguments can be used to conditionally include nodes, set parameter values, or modify topic names based on command-line input or other arguments.
• Example: Creating an argument use_sim_time that defaults to false for real robots but can be set to true when launching with a simulator.

A ROS 2 Component is a node packaged as a shared library (e.g., a C++ .so file) that can be dynamically loaded into a component container process at runtime. This is a key ROS 2 feature for efficient resource management.

• Launch Role: The launch system uses the ComposableNodeContainer and LoadComposableNode actions to compose multiple components into a single process, reducing inter-process communication overhead.
• Benefit: Improves performance and latency for tightly coupled nodes (e.g., a perception pipeline).
• Contrast: Differs from a standard node, which always runs in its own process.

Colcon is the primary meta-build tool for ROS 2. It is used to build packages in a workspace and is closely integrated with the launch system, as it handles the environment setup required for launch files to find packages and executables.

• Workflow: After building packages with colcon build, you must source the setup script (e.g., source install/setup.bash). This script configures environment variables like ROS_PACKAGE_PATH.
• Launch Dependency: The launch system relies on this sourced environment to locate the executables and resources defined in launch files.
• Command: colcon build --packages-select my_robot_launch