Currently used naming patterns

power_board/   --> Single name per component, same as node name
  params
  state
  command

pr2_controller_manager/   --> Single name per component, different from node name
  params
  load_controllers
realtime_loop (node)

imu/  --> Name for public api and name for private params
  data
  calibrate
imu_node/
  params


camera/  --> One name for public api shared by multiple nodes. Private params in node
  image_raw (from wg100_node)
  image_rect (from image_proc_node)
wg100_node/
  params
image_proc_node/
  params


base/ --> Name for public api and NodeHandle for private params
  cmd_vel
pr2_base_controller/
  params



== Use cases ==
 1. When two nodes that communicate (peers) are brought up with their default settings, they connect automatically on the right topics. Dangerous when running full robot (with imu on default topic) and someone brings up a wiimote (which provides imu and joy) in its default configuration.
 2. When two peers are pushed into the same namespace, they still connect automatically. 
 4. There are two lasers.  The user wants to connect a laser odometry node up to the base laser.
  * The laser_odom should look in laser/ by default.  Remapping laser/ to base_laser/ will point the laser_odom at the correct place with only one remap.  This leads to the following layout:
{{{
base_laser/
  scan
  some_laser_service
tilting_laser/
  scan
  some_laser_service
In laser_odom: laser/ --> base_laser/
hokuyo_node_tilt/
  param
hokuyo_node_base/
  param

1. Write a launch script to bring up move_base. Now, using remapping/namespaces, bring up two versions of move_base that talk to all the right things.
2. Bring up prf and prg. Both should listen to the same map server, and there should be some node that listens to all of their lasers.

  remap from="prg/mapserver" to="mapserver"
  ns="prg"
    include prg.launch

  remap from="prf/mapserver" to="mapserver"
  ns="prf"
    include prf.launch

  lasernode
    remap from laser1 to prg/laser
    remap from laser2 to prf/laser

Proposal

• Interface: a layout of topics and services...
• An interface should be contained in its own namespace
  • Pro: Can remap the entire interface at once.
• Private parameters belong in the node name's namespace.
  • Generally agreed upon
• The interfaces of a node should be contained in the node name's namespace (hokuyo_node/laser)
  • Con: Can't connect automatically anymore. The interfaces must be remapped
  • Pro: explicit remapping avoids accidental connections (wiimote providing an imu interface)
  • suggestion: no
• The interfaces of a node should be peers of the node(handle) name's namespace

  • Note: the peer of a NodeHandle is not defined. Can't move over one level. Can only descend (or ascend all the way to the node).

  • Pro: Pieces can connect automatically
  • Con: Renaming a node is not enough to change its interfaces' namespace. Changing the camera node to "r_camera_node" doesn't move the place where the images are published, so the interface(s) will still conflict with the left camera.
• The node namespace and the interface namespace(s) should be different
  • Pro: Allows a node to provide multiple interfaces
  • Con: More namespaces. User wants to use am imu sensor, and uses rostopic list to get a list of the available imu sensors. Rostopic list gives: imu_node/... and imu/... How does the user know which one to use? It gives the appearance of having two imu sensors.
  • Pro: Allows you to create a pipeline where multiple nodes write into the same pipeline interface.
  • Pro: The base controller has found this to be desirable.
• If the node has a single interface, it should be the node namespace.
  • Pro: Fewer namespaces
  • Con: The API gets services that aren't generic (the laser/ namespace will contain hokuyo-specific things)
• image_proc should provide a part of the camera interface

If you make the node name and the interface name the same, then the node is the interface. This only makes sense for nodes with a single interface.

Most controllers are not compatible with what we're laying out here. They're interface is inseparable from the node(handle) namespace. The base controller gets around this by subscribing to "/cmd_vel".

image_proc shows up in the camera interface

forearm_r/
  camera_info (from camera node)
  image_raw  (from camera node)
  image_rect (from image_proc)
forearm_l/
  camera_info (from camera node)
  image_raw  (from camera node)
  image_rect (from image_proc)

Both camera_node and image_proc publish in camera/, so they both get remapped.

Stereo

wide_stereo/  (remapped from camera/ for stereo_image_proc)
  left/  (from camera/)
    image_raw, etc...  (from camera_node)
    image_rect         (from stereo_image_proc)
  right/  (from camera/)
    image_raw, etc...  (from camera_node)
    image_rect         (from stereo_image_proc)
  points  (from stereo_image_proc)
stereo_image_proc/parameters
wge100_wide_left/parameters
wge100_wide_right/parameters

Controllers:

• Remapping isn't available, but that can be fixed/hacked

Trajectory controller.  Controller and the node.  Let's pretend it's image_proc
r_arm_controller_node/params
r_arm_joint_traj_action_node/params
r_arm/
  joint_trajectory/
    goal...
  command
  state

By default:
joint_trajectory/
  "joint_trajectory_action/" or "action/"
    goal
    cancel
    feedback
  command
  state
Pro: Can have a number of generators inside "r_arm/"
Con: The names of the action topics are really long.
Pro: The top-level namespace is much cleaner

• Name all the nodes "node_" so they all fall together, or filter them out with rostopic.

wiimote:

wiimote_node/params
joy/
imu/

• The IMU on the PR2 should not come up in the default location.
• Should always be able to push down a launch file with a namespace and remap up topics that are needed.

wiimote/priv joy (from wiimote) imu (from wiimote)

ps3joy/priv joy (from ps3joy)

move_base

• costmap_local costmap_global