# Revision history [back]

From a really high-level: remapping makes the ROS middleware return a different resource when a graph participant asks for something with a certain name.

In other words: if there is a remap from name_a to name_b and node_x asks for name_a, it will actually be returned whatever is registered with name_b.

To make it more concrete (with two examples):

• for a publisher: if node_x wants to publish to topic chatter, but there is a remap chatter->other_topic, then it may advertise a chatter publisher, but it will actually be publishing to topic other_topic
• for a subscriber: if node_x subscribes to chatter, but there is a remap chatter->other_topic, it will request a subscription to chatter, but in reality it will subscribe to other_topic

These remaps are completely transparent (ie: invisible) to node_x, they are processed by the ROS middleware.

The "only requirement" is of course that chatter and other_topic are of the same message type. Remapping is not magic, it changes names, not types (that would be message transformation).

The power here is that I can write a node_x and you can write a node_y and we can both hardcode the topic names we want to use.

If we used different topic names, but one of our users wants to "connect" our two nodes together, they only have to provide a remapping. Either:

• make node_x use the topic name that node_y expects
• make node_y use the topic name that node_x expects
• remap both to a third name, different from what node_x and node_y use internally

From a really high-level: remapping makes the ROS middleware return a different resource when a graph participant asks for something with a certain name.

In other words: if there is a remap from name_a to name_b and node_x asks for name_a, it will actually be returned whatever is registered with name_b.

To make it more concrete (with two examples):

• for a publisher: if node_x wants to publish to topic chatter, but there is a remap chatter->other_topic, then it may advertise a chatter publisher, but it will actually be publishing to topic other_topic
• for a subscriber: if node_x subscribes to chatter, but there is a remap chatter->other_topic, it will request a subscription to chatter, but in reality it will subscribe to other_topic

These remaps are completely transparent (ie: invisible) to node_x, they are processed by the ROS middleware.

The "only requirement" is of course that chatter and other_topic are of the same message type. Remapping is not magic, it changes names, not types (that would be message transformation).

The power here is that I can write a node_x and you can write a node_y and we can both hardcode the topic names we want to use.

If we used different topic names, but one of our users wants to "connect" our two nodes together, they only have to provide a remapping. Either:

• make node_x use the topic name that node_y expects
• make node_y use the topic name that node_x expects
• remap both to a third name, different from what node_x and node_y use internally

Edit: you've probably already seen it, but just for completeness: see the Remapping Arguments on the wiki for some more information.

And although it's an article about ROS 2, the Remapping Names article on the ROS2 design website might provide some additional background. It also has a section on ROS 1 remapping.

From a really high-level: remapping makes the ROS middleware return a different resource when a graph participant asks for something a resource with a certain name.

In other words: if there is a remap from name_a to name_b and node_x asks for name_a, it will actually be returned whatever is registered with name_b.

To make it more concrete (with two examples):

• for a publisher: if node_x wants to publish to topic chatter, but there is a remap chatter->other_topic, then it may advertise a chatter publisher, but it will actually be publishing to topic other_topic
• for a subscriber: if node_x subscribes to chatter, but there is a remap chatter->other_topic, it will request a subscription to chatter, but in reality it will subscribe to other_topic

These remaps are completely transparent (ie: invisible) to node_x, they are processed by the ROS middleware.

The "only requirement" is of course that chatter and other_topic are of the same message type. Remapping is not magic, it changes names, not types (that would be message transformation).

The power here is that I can write a node_x and you can write a node_y and we can both hardcode the topic names we want to use.

If we used different topic names, but one of our users wants to "connect" our two nodes together, they only have to provide a remapping. Either:

• make node_x use the topic name that node_y expects
• make node_y use the topic name that node_x expects
• remap both to a third name, different from what node_x and node_y use internally

Edit: you've probably already seen it, but just for completeness: see the Remapping Arguments on the wiki for some more information.

And although it's an article about ROS 2, the Remapping Names article on the ROS2 design website might provide some additional background. It also has a section on ROS 1 remapping.