[Documentation] [TitleIndex] [WordIndex

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

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:

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

wiimote:

wiimote_node/params
joy/
imu/

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

ps3joy/priv joy (from ps3joy)

move_base


2023-10-28 12:55