UP | HOME

Naming in ROS

Naming in ROS

Understanding Names

Overview

  1. Every item in the ROS Computation Graph has a Graph Resource Name (ROS 1)
  2. When creating nodes, subscribers, clients, actions, and services, each of these entities is provided a name as one of the arguments.
    • The name is used by ROS Client Libraries to register objects with the appropriate entity in the ROS graph (e.g., publisher/subscriber with a topic).
  3. Names provided in code are best thought of as placeholder default values: they can be changed by users when the node runs.
  4. Every ROS 2 node exists within a =/namespace/
    • Namespaces are like directories on Linux: they start from the global namespace (called /) and can be nested (e.g., /ns1/ns2/ns3).

Names as Paths

Just like paths on Linux, ROS names can be relative or absolute

  1. An absolute name is any name that starts with a /
    • No two entities in the ROS graph can share the same absolute name
  2. A relative name is any name that does not start with a /.
  3. Relative names are interpreted relative the namespace of the node
    • In some contexts (such as starting a node with ros2 run an absolute name must be used.
  4. The base name is the name of the entity (e.g., node, topic, etc.) without any preceding namespaces.
    • In a sense this is equivalent to the name of a file on a Linux system
  5. A ~ makes a name private.
    • The ~ gets expanded to the full absolute name of the node (including the base name).
    • Private is enforced by convention and just means that the node namespace and name are prepended.
    • The use of this symbol is inspired by its use for the home directory on Linux

Example

Suppose we have a node called /this/is/mynode

  1. The base name of the node is mynode.
  2. The namespace of the node is /this/is.
  3. The is namespace is nested under the /this namespace

Suppose /this/is/mynode creates a publisher on the hello topic and a subscriber on the /foo/data topic and a service server called ~/help:

  1. The node (by default) will publish to /this/is/hello.
  2. The node (by default) will subscribe to /foo/data.
  3. The node will offer a service (by default) on /this/is/mynode/help.

Comparison with ROS 1

  1. In ROS 1, parameters were global and followed the same naming conventions as other entities.
  2. In ROS 2, parameters are always associated with a specific node and within that node can optionally have their own parameter namespace.

Manipulating Names

Name Mapping

  1. Resources can be remapped to any name that you want using Node Arguments
    • Remapping is like an mv operation in the Linux filesystem
    • The ability to remap enables multiple copies of a node to run in parallel but use different topics/services etc.
  2. Any name referred to in the node (including absolute and private names) can be remapped when starting the node.
    • To remap a specific name use ros2 run package node --ros-args -r old_name:=new_name
      • Multiple -r arguments can be passed after --ros-args to rename multiple entities
    • The node can be renamed using -r __node:=new_node_name in the above
    • The namespace can be changed using -r __ns:=/new_namespace.
      • The namespace must start with a /
  3. When the node's namespace is changed, all entities (e.g., topics) that used relative names will be moved relative to the provided namespace, but entities that used absolute names will not move.
    • This behavior makes it easy to remap groups of related names.
    • Namespaces also allow running multiple groups of nodes simultaneously with the same topics
  4. In practice, ROS nodes should be written with remapping in mind:
    • Generally, use simple, relative base names for ROS nodes, the services they offer, and the topics they publish and subscribe to (so do not include the leading /).
      • Following this convention allows your node to easily be run under a different namespace without needing to remap each topic individually
      • Using absolute node names makes your node less flexible and harder for others to use.
    • It is common for users of node to remap topics and place nodes in namespaces

Example

The turtlesim_node supports having multiple turtles. Each turtle's topics are mapped to it's own namespace. For example there is /turtle1/cmd_vel and /turtle2/cmd_vel to control the velocity and /turtle1/pose and /turtle2/pose to get the turtle's pose. Imagine we make a node called control that we use to control the turtles. There are a few options

  • Absolute Paths (Generally Don't Use These)

    Assume control subscribes to /pose and publishes to /cmd_vel. To use two copies of this node we need to

    1. Explicitly name the node two different names (e.g., control1 and control2)
    2. Explicitly remap both topics on both nodes so they control the correct turtle
    3. For complicated nodes this quickly becomes annoying and error-prone
  • Relative Paths and Namespaces (Use These)
    1. The node subcribes to pose and publishes to cmd_vel (both relative names)
    2. We launch one control node in the /turtle1 namespace and one control node in the /turtle2 namespace
    3. Everything connects properly: no renaming of nodes, no remapping.

A Node's ROS API

  • The publishers, subscribers, services, parameters, and actions a node declares comprise it's ROS API
    • They determine how other nodes interact with your node, on a ROS level
  • These ROS inter-process communication mechanisms are how you link nodes together, much like how modules, functions, and classes are used from within python.
  • These items should be documented in a docstring at the top of the file that defines your node.

Author: Matthew Elwin.