roslaunch was designed to fit the ROS architecture of complexity via composition: write a simple system first, then combine it with other simple systems to make more complex systems. In roslaunch, this is expressed through several mechanisms:

1. <include>s: you can easily include other .launch files and also assign them a namespace so that their names do not confict with yours.

2. <group>s: you can group together a collection of nodes to give them the same name remappings.

3. aliased <machine>s: you can separate machine definitions and node definitions into separate .launch files and use aliases to define which machines get used at runtime. This allows you to reuse the same node definitions for multiple robots. For example, instead of saying that a laser_assembler runs on 'foo.willowgarage.com', you can say that it runs on the 'tilt-laser' machine. The machine definitions then take care of which host is the 'tilt-laser' machine.

roslaunch also contains a variety of tools to help you write your .launch files as portably as possible. You can use the <env> tag to specify environment variables that need to be set for a particular machine or node. The $(find pkg) syntax let you specify file paths relative to a ROS package, instead of specifying their location on a particular machine. You can also use the $(env ENVIRONMENT_VARIABLE) syntax within include tags to load in .launch files based on environment variables (e.g. MACHINE_NAME).

Local processes

roslaunch launches local processes using popen and kills them using POSIX signals. roslaunch does not guarantee any particular order to the startup of nodes -- although this is a frequently requested feature, it is not one that has any particular meaning in the ROS architecture as there is no way to tell when a node is initialized.

Remote processes

Remote processes are different from local processes in how they are treated by roslaunch, so it is important to understand the differences when you are writing your .launch files. Some high-level differences include:

1. Your shell initialization scripts (.bashrc/.tcshrc/etc...) are ignored. In order for a launch file to be portable between users and systems, the configuration needs to be fully specified within the launch file. This includes settings like environment variables, which are often hidden in shell initialization scripts.

2. Remote processes do not forward their stderr/stdout to your local console. In general, nodes should be reporting important information using ROS' builtin logging mechanisms (i.e. rosconsole for roscpp, logout/logerr for rospy, etc...). This allows you to view this important information via the rosout tools.

Otherwise, remote launches look very similar to local launches. In fact, in order to remotely launch processes, roslaunch creates a new .launch file that contains the nodes you wish to launch on the remote machine. It then sshes into the remote machine and launches a roslaunch child process with that new .launch file.

It is highly recommended that you setup your computers to use SSH keys so Roslaunch can SSH into machines without having to provide an explicit user name and password.

If you are having trouble launching remote proceses, you should verify that you can ssh into each of your remote machines using the machine names that you specified in the launch file. You should also verify that each of the remote machines can ping the original machine using its hostname.

Tutorials

For a better understanding of how all these pieces come together, please see roslaunch tips for larger project.