What to put in app.launch

In RWS, you should theoretically include all the dependencies your app needs (databases, websocket/video servers, sound nodes) in your app.launch. However, this is problematic in practice, because if another app launches the same dependencies, it can lead to unexpected behavior.

This is because in ROS, starting a node with the same name as another node will shut down the old node. This causes the first node to lose state. For example, if a node launches the websocket server, and then another node launches the websocket server, then all clients who were connected to the first websocket server will be disconnected.

This can also lead to race conditions. The websocket server serves again as an example: it listens on a particular port number. When a second websocket server shuts down the first one, the second server might fail to listen on the appropriate port number because the first server hasn't finished shutting down yet. As a result, neither application will have the websocket server available. Similar bad behavior has been seen with sound_play, which can have distorted sound when one app relaunches it.

One solution is to put all your nodes in a namespace, so that they never conflict with the names of any other app's nodes. This solves the first problem of maintaining state. However, it doesn't solve the second problem, where two apps may compete over the same resource (e.g., a port number). Also, it's wasteful for each app to run its own version of a heavy-duty system, such as MoveIt!

The other solution is to promote dependencies that are used by two or more apps to the robot's bringup file. Instead of including them in app.launch, apps can just assume these dependencies exist. The downside to this is that the robot will always run these dependencies, even if none of the running apps need them. Another con is that if one of these dependencies is under active development, then it will be cumbersome to stop the robot and bring it up again to run tests. An example of this might be pr2_pbd, which is needed by both PbD and CodeIt.

A third solution, for hacky research purposes, might be to always remember which dependencies are launched by which app, and to launch them in a particular order. An example of this might be pr2_pbd. For example, the PbD app would launch the PbD backend. Then, before using CodeIt! users would remember to run PbD first. As a result, CodeIt programs could use the PbD backend without having to launch it, and the PbD backend wouldn't need to be in the robot's launch file, either.

We use a combination of solutions for the UW's robot.

What NOT to put in app.launch

Already in pr2_bringup (robot start)

• sound_play
• robot_pose_ekf

Common dependencies that are promoted to RWS's common launch file

• freenect_launch (Kinect)
• tuck_arms_action
• mongo_msg_db
• ros_web_video (web_video_server is technically the newer version but ros_web_video is needed for visualizing Kinect data on the web)
• rosbridge_websocket (This is actually embedded in RWS itself currently)
• tf2_web_republisher
• MoveIt!

Remembering extra steps

• Since pr2_pbd is under active development, we don't include it in the RWS bringup file. Instead, it runs as a dependency of rws_pr2_pbd, but not as a dependency of code_it. As a result, if you want to run PbD actions using CodeIt!, you must remember to visit the PbD app first.