Use of -r/--remap flags where appropriate.

[hidmic]

Precisely what the title says.

Connected to ros2/rcl#491.

[ivanpauno]

A comment out of the scope of this PR. LGTM!

[ivanpauno]

The change looks good, but I don't like the original motivation of this.

The node name uniqueness problem shouldn't be solved by generating a random name and overriding the command passed in the command line.
If someone wants to launch multiple TransformListener, they should carefully remap the node name.
I'm not sure if that's possible, because TransformListener isn't exactly a node. But in the case it's not possible, I think that problem should be solved instead of doing this.

[hidmic]

I won't weigh into the correctness of the workaround, just to keep this scoped. I'll defer to @rotu and @gonzodepedro, author and reviewer of #129 respectively, for that.

[rotu]

@ivanpauno
The motivation of this is that the sub-node inherits the global node name override (e.g. by setting the node name argument on a launch_ros Node action), which causes it to match the parent node.

How would remapping solve the problem of TransformListener’s name colliding with its parent node’s name? How would it help a parent node with multiple TransformListeners?

Yes this is an ugly hack and I feel dirty for it. I welcome a better solution.

[rotu]

Here’s the offending launch code:
https://github.com/ros2/launch_ros/blob/cb911b9af331c0b17e2c3b0dec375fa95a190548/launch_ros/launch_ros/actions/node.py#L348

The __node argument needs to be more narrowly targeted to the actual primary node in a process and then this hack can go away.

[ivanpauno]

@ivanpauno
The motivation of this is that the sub-node inherits the global node name override (e.g. by setting the node name argument on a launch_ros Node action), which causes it to match the parent node.

How would remapping solve the problem of TransformListener’s name colliding with its parent node’s name? How would it help a parent node with multiple TransformListeners?

Yes this is an ugly hack and I feel dirty for it. I welcome a better solution.

Ok, now I understand the problem better.
Remapping rules can be targeted to specific nodes, see https://index.ros.org/doc/ros2/Tutorials/Node-arguments/#passing-remapping-arguments-to-specific-nodes.
launch_ros.action.Node doesn't do the task very well. At some point we should support a MultiNodeExecutable action in launch_ros, see ros2/launch#114.

For the moment, it can be worked around in the launch file using arguments parameter in the constructor of ExecuteProcess or Node. I don't like much the idea of using a random name.

[rotu]

Remapping rules can be targeted to specific nodes, see https://index.ros.org/doc/ros2/Tutorials/Node-arguments/#passing-remapping-arguments-to-specific-nodes.

Yes, but ideally the node of a TransformListener should be an implementation detail that the caller doesn't need to worry about. If the parent node has to both create a TransformListener object and reach inside to rename its nodes apart, that is terrible OOP design. Ideally, there should be no need for a subnode, or there should be no requirement for node name uniqueness, or you should be able to pass a flag to rclcpp that says "I don't care about the name of this node - make it unique for me".

For the moment, it can be worked around in the launch file using arguments parameter in the constructor of ExecuteProcess or Node. I don't like much the idea of using a random name.

Randomized names seem the lesser evil compared to moving the names of TransformListeners' subnodes to a launch file and manually giving them unique names - a detail that should be completely handled by the node itself.

[hidmic]

@rotu @ivanpauno I'd think this deserves a separate issue. I see valid arguments on both sides, and this is a completely unrelated PR that will hopefully soon be merged.