roslaunch: scope of machine tag with default=true not respected

[peci1]

From roslaunch/XML/machine docs:

default="true|false|never" (optional)

Sets this machine as the default to assign nodes to. The default setting only applies to nodes defined later in the same scope. NOTE: if there are no default machines, the local machine is used. You can prevent a machine from being chosen by setting default="never", in which case the machine can only be explicitly assigned.

I've a pair of launch files:

a.launch

<launch>
  <node name="a" pkg="rostopic" type="rostopic" args="pub -r 1 /a std_msgs/Int32 'data: 1'" />
  <include file="b.launch" />
  <node name="c" pkg="rostopic" type="rostopic" args="pub -r 1 /a std_msgs/Int32 'data: 1'" />
</launch>

b.launch

<launch>
  <machine name="b" address="robot" user="robot" password="robot" env-loader="/home/robot/env.sh" default="true" />
  <node name="b" pkg="rostopic" type="rostopic" args="pub -r 1 /b std_msgs/Int32 'data: 1'" machine="b" />
  <node name="b2" pkg="rostopic" type="rostopic" args="pub -r 1 /b std_msgs/Int32 'data: 1'" />
</launch>

With this setup, when launching a.launch, nodes b, b2 and c are launched on the remote machine.

So it seems that the "scope" the docs are talking about are the whole "include-resolved" launch file, which is highly undesirable and unintuitive. Even enclosing the nodes in b.launch doesn't limit the scope.

What I'd expect would be nodes b and b2 launching on remote machine, while a and c being launched locally.

And I'm not alone with this expectation: https://answers.ros.org/question/206699/what-is-scope-in-roslaunch-default-machine-not-changing/ .

Why I'd like to do this is to be able to specify an arg in a launch file that would allow me to select to launch the node either without any machine tag, or, if the arg is nonempty, with a machine tag belonging to the selected machine. But with https://github.com/ros/ros_comm/issues/274 still unresolved, I cannot pass an empty machine attribute to node, so the only way to allow configurable remote/local launching is by typing the whole node code twice. That's not really nice...

[git-afsantos]

I second this. A minimal example showing this behaviour could be:

<launch>
  <group>
    <machine name="willow" address="blah.willowgarage.com" default="true" />
  </group>

  <node name="a" pkg="rostopic" type="rostopic" args="pub -r 1 /a std_msgs/Int32 'data: 1'" />
</launch>

In the example, node a is launched on the willow machine, resulting in:

RLException: cannot resolve host address for machine [blah.willowgarage.com]

[peci1]

https://github.com/ctu-vras/scoped_roslaunch is a package that fixes this issue (it is a workaround until #2059 gets merged).

[130s]

@ros/ros_comm-maintainers @sloretz Assuming no new capabilities should be accepted to any ROS1 core any more, this sounds worth filing as a bug to me though I'm not entirely sure. If this is a bug, there's a potential fix suggested https://github.com/ros/ros_comm/pull/2059. Is it something ROS core team still review, merge and make a release when reasonable?

[peci1]

Assuming no new capabilities should be accepted to any ROS1 core any more

That's weird, https://github.com/ros/ros_comm/pull/1937 got merged quite recently into Melodic and Noetic roslaunch.

[130s]

My opinion was personal, sorry if that wasn't clear. Looks like https://github.com/ros/ros_comm/pull/1937 was merged into ROS Noetic before its initial release?, but it looks also backported to then-already-released Melodic, so yeah, I'm now not sure the policy. And if new features can still be merged into already-released distros, it's kind of good news to me as I wanted to suggest some new small features, but we need clarifications unless that's already documented.