Roslaunch Creates Unexpected Private Parameters

[git-afsantos]

I came across a bug on the implementation of roslaunch. I have tested it both in Indigo and Kinetic, and it is also present in lunar-devel from what I can see.

Consider the following example launch,

<launch>
  <node name="driver" pkg="drivers" type="driver">
    <param name="param1" value="1" />
    <param name="~param2" value="2" />
  </node>
  <node name="controller" pkg="controllers" type="controller" />
</launch>

As you would expect, roslaunch creates two parameters:

• /driver/param1
• /driver/param2

Consider yet another simple example.

<launch>
  <param name="~param" value="1" />
  <node name="driver" pkg="drivers" type="driver" />
  <node name="controller" pkg="controllers" type="controller" />
</launch>

Again, two parameters, as expected.

• /driver/param
• /controller/param

If we combine both features, the second node inherits the first node's private parameters, when it should not.

<launch>
  <param name="~param1" value="1" />
  <node name="driver" pkg="drivers" type="driver">
    <param name="param2" value="2" />
    <param name="~param3" value="3" />
  </node>
  <node name="controller" pkg="controllers" type="controller" />
</launch>

This results in six parameters, instead of four.

• /driver/param1
• /driver/param2
• /driver/param3
• /controller/param1
• /controller/param2
• /controller/param3

I have tried variations of isolating either the first or second node in <group>, but the result is the same.

From my understanding of the code, the problem lies in line 172 of loader.py and line 320 of the same file.

When parsing the first private parameter, the parameter is added to the root context.

if is_private(name) or force_local:
    p = Param(name, value)
    context.add_param(p)

When parsing the node tag right after, a child context is created, and this is where the problem lies. The child context does not start with its own list of parameters, it simply reuses the same list, over and over.

def child(self, ns):
    ...
    return LoaderContext(..., params=self.params, ...)

The result is that param1 is added to the list, and param2 and param3 are added to the same list as well, because the child context is using the same reference as its parent context. When parsing the second (third, fourth, ...) <node>, it will create not only param1, but the other parameters as well, since they were wrongly appended to the root list.

Why does this work as intended if the first parameter is not present? It works because the list is empty when the first <node> is parsed. When creating the child context, an empty list (the root list) is passed to the LoaderContext constructor. As seen in line 172, if the received list is empty, it does not pass the logical or, and a new parameter list is created. Since a new list is created, it isolates the parameters properly.

self.params = params or []

I have a few ideas to solve this issue, but I am not sure of the impact of each, and what is the intended behaviour. If one of the following is the clear solution, I can submit a pull request.

1. Change LoaderContext constructor. Simply create a new empty list for self.params every time.
2. Change the child method to pass down either an empty list or a copy of the current list.
3. Change XmlLoader to overwrite param_ns.params with an empty list (l. 372).

[mikepurvis]

Thanks for the detailed report! Looks like this is an issue with the tilde param functionality, since the following:

<launch>
  <param name="param1" value="1" />
  <node name="driver" pkg="drivers" type="driver">
    <param name="param2" value="2" />
    <param name="param3" value="3" />
  </node>
  <node name="controller" pkg="controllers" type="controller" />
</launch>

Gives the expected result:

$ roslaunch test.launch --dump-params
{/driver/param2: 2, /driver/param3: 3, /param1: 1}

The documentation says:

You can also set private parameter across a group of nodes by using the ~param syntax (see ROS names) in a tag. The declared parameter will be set as a local parameter in the tags that follow that are in the same scope (i.e. group or ns tag).

So I agree that this behaviour is absolutely a bug.