Nested remapping of topics for plugins

[stwirth]

I've been trying to find a solution for the following use case: I have a gazebo simulation with multiple, namespaced robots that use ros_control (/robot1/joint_trajectory_controller/follow_joint_trajectory_action, /robot2/joint_trajectory_controller/follow_joint_trajectory_action, etc.). Spawning the robots into their namespaces by putting the spawn_model node inside a namespace in the launch file works well and the node handle seems to be passed to the ros_control plugin with that namespace as expected. However, when I want to use remapping I found that there is only one not very flexible solution: To be able to remap a topic that is used inside a gazebo plugin (gazebo_ros_control in my case), the only way I found is to create a top-level <remap> tag in the top-level launch file of my simulation. When the node handle of the gazebo plugin resolves a topic name, it then falls back to the "global remappings" (see line 228 here and can resolve the name. To continue my use case, what I want to achieve is that the robots adhere to the ROS-Industrial standard topic names, so I need to remap e.g. /robot1/joint_trajectory_controller/command to /robot1/joint_path_command. And I want to be able to do that in my robot.launch (which runs spawn_model) instead of my top-level launch file.

A possible solution would be to somehow pass remapping arguments that are given to the spawn_model script to gazebo (like it is done for robot_namespace in the service call) and add those remappings to gazebo's internal node handle (which is then used to create the robot specific model and plugin node handles).

[stwirth]

/cc @jonbinney

[jonbinney]

@j-rivero des this sound reasonable? Are we early on enough in melodic to add the field to the service (would require people to recompile code since the message definition would change, but would not require them to change code to keep the same behavior). If so we'll implement and send and PR review.