roslaunch - pass through command-line args to the xmlloader when using the API

[sputnick1124]

Using the roslaunch API to manage multiple launch files, it seems logical that you would be able to specify arg:=value pairs; however, the documentation does not seem to hint that this is possible. After digging, it is indeed impossible in the current API to do so. This is due to the fact that there is no mechanism to pass any arguments to the XML loader from a ROSLaunchParent. The XML loader currently just looks at sys.argv for arguments. This is obviously fine for command-line usage, but breaks any usage from the API.

The way to do this is a question occasionally from users as it is natural to think it is possible:

• http://answers.ros.org/question/237109/passing-arguments-to-launch-file-from-python-api/
• http://answers.ros.org/question/198910/how-to-set-args-with-python-roslaunch/

Simple usage examples.

• Single launch file with args:

import roslaunch

uuid = roslaunch.rlutil.get_or_generate_uuid(None, False)
roslaunch.configure_logging(uuid)

cli_args = ['pkg', 'file.launch', 'arg1:=arg1', 'arg2:=arg2']
roslaunch_file = roslaunch.rlutil.resolve_launch_arguments(cli_args)
roslaunch_args = cli_args[2:]
parent = roslaunch.parent.ROSLaunchParent(uuid, roslaunch_file, roslaunch_args=[roslaunch_args])

parent.start()

• Multiple launch files with args:

import roslaunch

uuid = roslaunch.rlutil.get_or_generate_uuid(None, False)
roslaunch.configure_logging(uuid)

cli_args1 = ['pkg1', 'file1.launch', 'arg1:=arg1', 'arg2:=arg2']
cli_args2 = ['pkg2', 'file2.launch', 'arg1:=arg1', 'arg2:=arg2']
roslaunch_file1 = roslaunch.rlutil.resolve_launch_arguments(cli_args1)
roslaunch_args1 = cli_args1[2:]

roslaunch_file2 = roslaunch.rlutil.resolve_launch_arguments(cli_args2)
roslaunch_args2 = cli_args2[2:]

roslaunch_files = roslaunch_file1 + roslaunch_file2
roslaunch_args = [roslaunch_args1, roslaunch_args2]
parent = roslaunch.parent.ROSLaunchParent(uuid, roslaunch_files, roslaunch_args=roslaunch_args)

parent.start()

[luator]

This feature is really needed, I hope it gets merged soon!

[dirk-thomas]

Please add new arguments at the end of the signature since existing code might call keyword arguments as positional which would break.

Same below.

[sputnick1124]

Fixed position of new arguments to be at the end of the signatures.

[dirk-thomas]

Currently this requires roslaunch_args to be either None or at least have the same length as roslaunch_files. It would be good to support the usage where roslaunch_args contains less items than roslaunch_files since a user might only pass fewer roslaunch_args since the other launch files don't need arguments.

[sputnick1124]

I agree that the interface is not very pretty or ideal, but I'm having trouble seeing any way to determine which roslaunch file should get an arg list apart from 2 equal-length lists. Otherwise, if the user gives multiple launch files, but only one arg list, how do we decide which file to give the list to? Can we just document that any launch files w/o args must pass in a None?

[sputnick1124]

e.g.:
ROSLaunchParent(uuid, [file1, file2], roslaunch_args=[['args', 'for', 'file1'], None])

[sputnick1124]

Or perhaps we pass that args in as a dictionary with roslaunch filenames as keys and arglists as values? That would remove all ambiguity... And dict.get already plays nice by defaulting to None for nonexistent keys. I'll work on that tack and see how the interface feels.
Update:
Didn't consider the fact that the dictionary would not allow the user to launch the same file multiple times with different arguments if using the filename as a key. Unfortunately, this is one of the main use cases I foresee. If launching a swarm of robots, one might want to launch the same instance with e.g. different namespaces as arguments. Any other ideas?

[dirk-thomas]

How about just allowing the roslaunch_args list to be shorter. That avoids that the user needs to append None for launch files at the end which don't have arguments.

[sputnick1124]

That's an option. What are your thoughts on my later commits using a dictionary? Seems to give the best of both worlds to me, but maybe I've got blinders on. I can revert those commits and go with this instead.

[dirk-thomas]

Having two lists which are correlated by their index is certainly not very elegant.

But with the current dict I do see two downsides:

• the repetition of the launch file

• the changed semantic when using arguments for launch files which appear more than once

  • Before calling it with [foo, foo, bar] was straight forward. But when passing arguments those need to be grouped by the file name {foo: [args-for-first-foo, args-for-second-foo], bar: [args-for-bar]} which seems rather unintuitive.

Another alternative might be to pass the filenames and their arguments in a single parameter. Each item in the list could be either a plain filename or a tuple where the first element is the filename and the second element contains the arguments. That might provide a nicer API while still being backward compatible?

[sputnick1124]

I like your last idea. It's intuitive and should be easy to implement as well as understand for users. I'm on it.

[sputnick1124]

Allow for one launchfile with multiple distinct calls by allowing the args itself to be a list of arglists. The file will be launched once for each arglist in args. Otherwise, just launch the file with args as normal.

[sputnick1124]

Updated per suggestion from @dirk-thomas . Fully backwards-compatible and minimal changes made to add new functionality. Calling the api with launch arguments is a little clunky as you now have to build a list of tuples, but it's no worse than any of the alternatives.

New API:

cli_args = ['pkg', 'file.launch', 'arg1:=arg1', 'arg2:=arg2']
roslaunch_args = cli_args[2:]
roslaunch_file = [(roslaunch.rlutil.resolve_launch_arguments(cli_args)[0], roslaunch_args)]
parent = roslaunch.parent.ROSLaunchParent(uuid, roslaunch_file)

The same can be done for multiple launch files. Launch files with and without arguments can be freely mixed in a list. If it has args, it is a tuple, ("/path/to/launchfile.launch", ["arg:=arg", ...]). otherwise it is sent as normal; ["/path/to/launchfile.launch"]

Multiple launchfiles will look something like:

launch_files = ["/path/to/file1", ("path/to/file2", ["args", "for", "launch2"]), "/path/to/file3", ...]

where file1, file2, and file3 may be the same or different files.

[sputnick1124]

@dirk-thomas, have you had a chance to look at this? I know it's pretty low-priority, but just wondering if this was going to make it in or if it should be closed.
If it merges, I can update the documentation to reflect the new capabilities.

[dirk-thomas]

The current patch looks good to me. Please update the docblock of the function to mention the new possible values for roslaunch_files.

[sputnick1124]

Done. Let me know if that's not clear enough.

Also, would it break the API to change roslaunch.rlutil.resolve_launch_arguments to handle arguments differently? For example:

# current behavior. would remain unchanged.
roslaunch.rlutil.resolve_launch_arguments(['pkg', 'file']) #==> returns ['/path/to/file']

# current behavior with args. same return value as above
roslaunch.rlutil.resolve_launch_arguments(['pkg','file','arg:=arg']) #==> returns ['/path/to/file']
# suggested modification
roslaunch.rlutil.resolve_launch_arguments(['pkg','file','arg:=arg']) #==> returns [('/path/to/file', ['arg:=arg'])]

Thoughts? This would change the way all roslaunch arguments are handled internally, but the change is innocuous (args would be passed through as function arguments via the new tuple interface instead of being read in from sys.argv). I'm just not sure if resolve_launch_arguments is used elsewhere with expected behavior.

If interested, I can open a new PR to explore this. Or you can tell me to leave well enough alone and I'll drop it. :)

[dirk-thomas]

would it break the API to change roslaunch.rlutil.resolve_launch_arguments to handle arguments differently?

As far as I understand your example I would say since you are changing the return value. Callers expecting a plain list with launch file names would fail then if each item in the list is a tuple.

I'm just not sure if resolve_launch_arguments is used elsewhere with expected behavior.

Since it is a public function you have to assume that it is used somewhere.

---

I rephrased the docblock a bit in d9cd550 to clarify that the item is either a launch file name or a tuple with exactly two elements.

I think this is good to be merge now. Thanks for the quick update.

[sputnick1124]

Sounds good to me. Thanks for getting this through!