-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propagate launch arguments in included launch descriptions #313
Comments
@wjwwood What do you think about this? |
Based on this issue, @ivanpauno, @hidmic, and I had an offline discussion. This is a summary of our conclusions: We think that the
The first point basically means we don't need to automatically propagate declared arguments from launch files included in the "root" launch file. However, we still will allow declared arguments in the "root" launch file to be "non-deterministic" or "dynamic", meaning that they might not be resolvable without running the launch file. Therefore, we cannot check that the arguments given by the user match, exceed, or fall short of what is declared, as the second point says, without actually running the launch file. Arguments given by the user will continue to be set as if the For example, After discussing the ramifications of this, we wanted to address some use cases that were impossible or inconvenient. First, since we're only considering the arguments declared in the "root" launch file, it becomes inconvenient if you need to include a complex launch file with many arguments in a simple "wrapper" launch file. Therefore we'd like to have a way to "promote" any arguments in a launch file to the current launch file when including it. The second under served use case is having control over which launch configurations are available to an included launch file. This also deserves its own issue. Because we're still allowing substitutions in the name of declared arguments and conditionals, we still need some of the behaviors @ivanpauno proposed as part of the "best-effort" nature of This will also be needed when trying to implement the first convenience feature described above (promoting arguments from one launch file to the next). @ivanpauno and @hidmic please add to this in case I missed anything. |
Just to leave a breadcrumb, @ivanpauno removed this from the patch release queue since it's a feature request without anyone allocated to fulfill it. If work is done toward this feature we can still consider it for backport. |
I apologise for bringing back an old issue, but I believe this would greatly improve usability. In our use case we'd like to expose an easy to use launch file to spawn a robot in the gazebo simulator, while being able to specify all the launch arguments for gazebo as well as for the robot configuration. An example in ROS1 would be this; https://github.com/pal-robotics/tiago_simulation/blob/kinetic-devel/tiago_gazebo/launch/tiago_gazebo.launch#L4 The solution in ROS1 as discussed here is I was under the impression that the describe/execute duality of the new launch system would be ideal for these situations.
I would ask that there's a version of If I understand correctly, there are some launch files that may not be known until execution? Could we have a best effort implementation ignoring those? I'd like to contribute in any way possible, although I just have user level experience with the new launch system. |
@v-lopez That's great! I'll forewarn you that this isn't trivial to solve though. Yes, I'd suggest you submit a design document that outlines how you intend to solve which problem (the first ramification discussed by @wjwwood, if I'm not mistaken). There we can discuss the approach. |
I agree with @hidmic, specifically this is the ramification he was talking about:
So the idea would be to have you (or anyone interested) describe how that promoting mechanism would work and how to handle "dynamic" include actions (I think a best effort solution is better than none). |
I merged #556 which I don't think closes this, but it's worth mentioning. |
Feature request
Feature description
There have been some previous discussion in #252 #249 too.
I've been discussing this a little with @hidmic, here are some of the items we discussed:
IncludeLaunchDescription
action. Launch arguments of nested launch descriptions are ignored in the process. We're also only showing those arguments when executingros2 launch -s <PACKAGE> <LAUNCH_FILE>
. But we're not checking in ros2 launch if the passed arguments were declared by the launch description or not. So currently, the launch arguments are "automatically propagated" to nested launch files, though they aren't showed to the user.IncludeLaunchDescription
action, including the arguments in nested launch descriptions, is hard, because some information may not be available at that moment:IncludeLaunchDescription
may not be known.SetLaunchConfiguration
action may satisfy the requirement before the nestedIncludeLaunchDescritpion
is visited. If we do the verification anticipated, we can't be aware of that.IncludeLaunchDescription
actions aren't scoped (as is currently happening), we can run in the following problem:There are a lot of others similar issues. In general, considering that the included launch description will possible be maintained by another person, defaulting to scoped would be better (and only using non-scoped include actions when the user consciously ask for it).
I think that one possible solution to this is just showing the arguments in a different way, but keeping everything else as-is:
ros2 launch -s <PACKAGE> <LAUNCH_FILE>
(not showing arguments of nested launch descriptions). Add a...
at the end, or something similar, meaning that the arguments of included launch descriptions weren't showed.ros2 launch -s <PACKAGE> <LAUNCH_FILE>
. In case a path can't be resolved, show a message notifying that to the user.The idea of this, is that all arguments that aren't re-declared, aren't directly visible to the user without digging in the documentation. But though not visible, they can still be specified by the user when running the launch file.
The text was updated successfully, but these errors were encountered: