[CM] Remove support for the description parameter and use only ~/robot_description topic

[destogl]

Part of the #1237.

Has to be adjusted after #1354 is merged.

[fmauch]

May I raise the question (has probably been discussed elsewhere, but I couldn't find a note in #940): Why do we subscribe to ~/robot_description? Isn't the usual workflow that we have /robot_state_publisher and /controller_manager, where /robot_state_publisher publishes /robot_description? This would leave everyone having to remap controller_manager/robot_description in their launchfiles. Am I missing something or is this intended behavior?

If we instead subscribed to robot_description there would not necessarily be any migration necessary, once we merge this, as CM will silently use the description topic from the joint state publisher instead of the parameter that people might still send to the CM node. In that case they just would have to remove the parameter and that's it.

[destogl]

May I raise the question (has probably been discussed elsewhere, but I couldn't find a note in #940): Why do we subscribe to ~/robot_description? Isn't the usual workflow that we have /robot_state_publisher and /controller_manager, where /robot_state_publisher publishes /robot_description? This would leave everyone having to remap controller_manager/robot_description in their launchfiles. Am I missing something or is this intended behavior?

This is intended, but soley by myself :)

The idea was to work with the local namespace. Reading your comment, you are right. for the cases where one has multiple controller managers, one should remap those instead making people to do remapping by default.

[fmauch]

so... should we change that?

[destogl]

so... should we change that?

I'll adjust!

[saikishor]

So when using multiple controller managers, we remap the topic within the launch file like this?

remappings=[
            ('/robot_description', '/custom_1/robot_description'),
        ]

Am I right?

[destogl]

So when using multiple controller managers, we remap the topic within the launch file like this?

remappings=[
            ('/robot_description', '/custom_1/robot_description'),
        ]

Am I right?

That's the idea.

[mergify[bot]]

This pull request is in conflict. Could you fix it @destogl?

[fmauch]

This pull request is in conflict. Could you fix it @destogl?

I'll make a PR to this PR's branch as mentioned in #1410

---

Edit: Looking into the conflicts present, my changes seem to be causing only minor issues so I think we should wait for #1354 and then fix all conflicts at once.

[mergify[bot]]

This pull request is in conflict. Could you fix it @destogl?

[bmagyar]

Now conflicting

[fmauch]

I've resolved the conflicts on my fork: https://github.com/fmauch/ros2_control/commit/7418dbbb540e041d043888b5a6c7dfe820a5c9c7 I could either make a PR to this PR's branch, or I could make a new PR replacing this or a maintainer could push my merge commit to this PR's branch. I think the latter is the best option, as then the history of this PR will be retained and git history will stay somehow understandable.

The tests run fine and I tested the UR driver against this locally.