roslaunch
Contents
SIG Coordinator: Dan Lazewatsky
Topics: roslaunch
Members:
- Dan Lazewatsky
- Lorenz Mösenlechner
- Bhaskara Marthi
- Nico Hochgeschwender
- Jonathan Bohren
- Christian Dornhege
- Isaac Saito
- Jack O'Quin
Mailing list:
Proposed New Features
<launch> tag: adding 'name' and 'description' attributes
- From Bill Morris's email:
I would like to propose modifications to the <launch> tag by adding a 'name' and 'description' attributes or elements. Icon information might also be nice as well, but isn't really as important. These will help make it easier to figure out what your launch files do in a way that is machine readable for other applications. For example, one idea is to be able to double click on a launch file have it start without a terminal, then it could call libnotify with the name and description of the launch file that was started. This would provide helpful feedback to the user as some launch files take a while to actually start. One issue I see is that libnotify/dbus seem designed to work on the local machine and multi master will probably fail. One fix for this might be to have roslaunch broadcast the Name and Description of each launch file it starts on a topic. Another node could then bridge this topic to libnotify. tl;dr launch file as a desktop icon, click it, too long to start. What is the easiest way to fix?
Similar: Support custom meta-tag to roslaunch file (https://code.ros.org/trac/ros/ticket/3515), (https://groups.google.com/forum/?fromgroups=#!topic/ros-sig-roslaunch/A1INolWm0Z4)
- From Bill Morris's email:
- Dependencies: "launch prog X once Y is running"
- This would need us to define what "Y is running" means. Is it just that the process has been launched? That certain initialization code has executed?
Adding 'machine' attribute to <include> and <group> tags
'machine' attributes are currently an undocumented (unstable?) feature in <include> tags. See the answer to this question. It currently works by launching all nodes listed in a locally-found launchfile specified by the 'file' attribute. This should definitely be standardized.
Introspection and interaction (https://groups.google.com/forum/?fromgroups=#!topic/ros-sig-roslaunch/9FPkrhkUlD0) - enable to talk to a running roslaunch, querying information about launched nodes, changing the launch, restarting, etc.
- Bubbling up/passing through args
If a.launch includes b.launch, and b.launch has arg foo, making it possible to run roslaunch a.launch foo:=bar and automatically passing foo to b.launch. There will need to be a way to deal with any naming collisions. This helps, for example, in situations where someone wants to change a single parameter in a launch file buried under a bunch of other launch files without having to create their own, almost identical set of launch files.
- Parameters: this is possibly a separate topic, but parameters and the parameter server are a part of the launch process that account for a lot of wasted developer time in practice.
- Would be nice if roslaunch files have a mode where they clean up after themselves by removing any parameters they set. This would decrease bugs caused by stale state on the parameter server.
This is similar, and potentially less dangerous alternative to the 'clear-params' attribute in the <group> tag.
- Would be good to have a way of telling that a certain parameter was not used. This would decrease bugs caused by misspelling a parameter name, or putting it in the wrong namespace.
- Would be nice if roslaunch files have a mode where they clean up after themselves by removing any parameters they set. This would decrease bugs caused by stale state on the parameter server.
'description' or 'doc' attributes for <arg> tags
completed in https://github.com/ros/ros_comm/pull/379
- Automatic CLI documentation for launchfile arguments and tab-completion.
Add topic remapping to <include> tags.
Currently, if one wants to remap topics in an included launchfile, one has to have <arg> tags for each remapping argument. See an example here. This creates excessively verbose and complex launchfiles, and makes it harder to figure out what is being remapped where.
Add respawn attribute to <include> tags to relaunch the include if any nodes it launched die.
Add something similar to inclusion guards like a <once> tag to prevent a given block of launchfile markup from being evaluated multiple times.
Allow binaries that are not in ros packages to be roslaunched
- Generate wiki documentation for launch files (show args, nodes launched, remappings, etc.)
All roslaunch errors should provide their origin (https://groups.google.com/forum/?fromgroups=#!topic/ros-sig-roslaunch/3lwAWAt5NLQ) [Not really a feature, unless some refactoring or similar would be required, might also be just a bug report]