conditional tag does not work

[pitosalas]

I have tried this and many variations.

  includes:
    - file: $(find-pkg-share my_package)/launch/optional_components.launch.yaml
      condition:
        value: $(var use_optional_component)
        type: 'boolean'

I have trolled the source code (e.g. ros2/launch_yaml) and can't figure out where the relevant code is. But I would be happy to offer support for condition if it is not already provided.

[christophebedard]

Could you provide more information? For example:

• How you're launching the launch file
• What you expect to happen, what actually happens
• The full launch file + the full included launch file (optional_components.launch.yaml), or a minimal subset of it that allows someone to reproduce the issue
• Which ROS 2 distro you're using
• Any other relevant information

Some info that might help you when looking at the source code:

• The code for the IncludeLaunchDescription action is here: https://github.com/ros2/launch/blob/bdf124d83c847b5205c204932e9f86daccc0c747/launch/launch/actions/include_launch_description.py
  • Note that the name of the action for frontends is include and not includes (see the @expose_action() decorator)
  • You can find some examples here: https://docs.ros.org/en/rolling/How-To-Guides/Launch-file-different-formats.html#launch-file-examples
• The condition feature is part of the base Action class (not specific to IncludeLaunchDescription), and is parsed here for frontends:

  launch/launch/launch/action.py

  Lines 64 to 72 in bdf124d

  	if_cond = entity.get_attr('if', optional=True)
  	unless_cond = entity.get_attr('unless', optional=True)
  	kwargs: Dict[str, Condition] = {}
  	if if_cond is not None and unless_cond is not None:
  	raise RuntimeError("if and unless conditions can't be used simultaneously")
  	if if_cond is not None:
  	kwargs['condition'] = IfCondition(
  	predicate_expression=parser.parse_substitution(if_cond)
  	)

  • Note that the name of the attribute is if and not condition. condition is the name of the corresponding Python class constructor arg
  • You can find an example here if you switch to the "YAML" tabs and search for if:: https://docs.ros.org/en/rolling/Tutorials/Intermediate/Launch/Using-Substitutions.html (in this case, there are 2 examples with executable:)

I believe it should look like this:

launch:
# ...
- include:
    file: $(find-pkg-share my_package)/launch/optional_components.launch.yaml
    if: $(var use_optional_component)

I agree that, if you're not used to the launch system, it's a bit hard to make sense of the source code and figure out how the actual launch file is supposed to look, especially since there aren't a ton of examples.

[pitosalas]

Thanks. I went with condition: because I found a couple of places where that was in an example ros2.,yaml launch file. Your suggestion, after quoting all the strings, which I think is required, worked.

  - include:
      file: "$(find-pkg-share hls_lfcd_lds_driver)/launch/hlds_laser.launch.py"
      arg:
        - name: port
          value: "/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0"
      if: "$(var lidar)"

I will study the code and come back maybe with a proposal. Thanks

[christophebedard]

Great! If you can point me to the examples you looked at, I can try to see if they need to be updated/fixed.

[pitosalas]

Hi Christopher By the way are you the committer for the launch stuff? And are you the designer? I am using the yaml launch file because it is far simpler although the syntax can sometimes be confusing. The python launch file is powerful but boy oh boy is it involved. It doesn’t seem pythonic more like Java. I don’t know the launch mechanisms nearly enough to propose how to change it but it is an unnecessary steep learning curve really early in one’s experience with ROS2 (although it’s better to have the python format than not like ROS1.) This is not a rant, just a question about the history of how we got to this particular design. Pito

…

On Mar 4, 2025, at 10:28 PM, Christophe Bedard ***@***.***> wrote: Great! If you can point me to the examples you looked at, I can try to see if they need to be updated/fixed. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***> christophebedard left a comment (ros2/launch#832) Great! If you can point me to the examples you looked at, I can try to see if they need to be updated/fixed. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[christophebedard]

Sorry for the delay.

By the way are you the committer for the launch stuff? And are you the designer?

I'm just one of the people helping maintain launch. Over the years, I've come to learn how it all works.

I am using the yaml launch file because it is far simpler although the syntax can sometimes be confusing.

The python launch file is powerful but boy oh boy is it involved. It doesn’t seem pythonic more like Java. I don’t know the launch mechanisms nearly enough to propose how to change it but it is an unnecessary steep learning curve really early in one’s experience with ROS2 (although it’s better to have the python format than not like ROS1.)

This is not a rant, just a question about the history of how we got to this particular design.

You are definitely not the first person to say this!

I think the main answer is: the Python "interface" was never meant to be the main interface. It's the backend. The YAML and XML launch frontends should be used instead of Python. The Python interface should only be used if someone wants to go deeper and hopefully if they know what they're doing.

Now, this doesn't really help. What's missing is:

1. Point users to YAML and XML launch files in the docs first, not Python
   • Currently, Python seems to be the default option:
     • https://docs.ros.org/en/rolling/How-To-Guides/Launch-file-different-formats.html
       • We may want to revisit the Python, XML, or YAML: Which should I use? section to lean more towards XML and YAML
     • https://docs.ros.org/en/rolling/Tutorials/Intermediate/Launch/Creating-Launch-Files.html
     • https://docs.ros.org/en/rolling/Tutorials/Intermediate/Launch/Launch-system.html
     • https://docs.ros.org/en/rolling/Tutorials/Intermediate/Launch/Using-Substitutions.html
   • I believe this is because the YAML and XML frontends were not fully implemented when the documentation was first written, but now they should be ready. If they're not, then we can work to improve them.
2. Improve the launch API documentation:
   1. Properly document the names of the actions/substitutions/etc. and their attributes in frontends, since they differ from the corresponding names in the underlying Python classes
      • Users should not have to look at the source code to know that the frontend attribute name of the condition param for an action is if
   2. Add examples for all actions/substitutions

Some relevant issues:

1. Document names of frontend action arguments launch_ros#404 + Document names of frontend action arguments launch_ros#409
   • I had started working on this because of situations similar to yours. I want to pick this back up when I get more time.
   • Once we have this, I want to add more examples to docs.ros.org and link to the relevant launch/launch_ros docs.
2. Proposal for reshaping Launch tutorials ros2_documentation#4453
3. launch file undocumented "args" option? ros2_documentation#4188

[pitosalas]

Interesting. I am surprised I guess that the "backend" is the python api. I thought (maybe this is out of date) that most of ROS2 is in C++ and python is just a patch to allow non-C++ programmers (e.g. like students and early adopters) to use a simpler language.

There are advantages obviously in using Python because everyone knows it and you don't have to reinvent concepts like arguments, conditionals, and also it opens possibilities in terms of customization and flow control.

But IMO the current Python API is definitely (unnecessarily) hard to use.I wonder if a new one could be built (on top of this one) that simplifies and makes the api and the default launch file more pythonic.

Here is a .yaml launch file:

launch:
  - arg:
      name: 'fox'
      default: 'false'
      description: 'launch foxglove?'
  - arg:
      name: 'camera'
      default: 'false'
      description: 'launch camera?'
  - arg:
      name: 'lidar'
      default: 'true'
      description: 'Launch lidar?'
  - arg:
      name: 'imu_apply'
      default: 'false'
      description: 'Launch imu correction?'
  - include:
      file: "$(find-pkg-share linorobot2_bringup)/launch/bringup.launch.py"
      arg:
        - name: base_serial_port
          value: "/dev/ttyUSB0"
        - name: micro_ros_baudrate
          value: "921600"
  - include:
      file: "$(find-pkg-share hls_lfcd_lds_driver)/launch/hlds_laser.launch.py"
      arg:
        - name: port
          value: "/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0"
      if: "$(var lidar)"
  - include: 
      file: "$(find-pkg-share dome)/launch/imu_apply.launch.py"
      if: "$(var imu_apply)"

Here is the same logic in a made up python DSL. I'm sure there are things here that conflict with the architecture and are impossible to do just like I have it. Just an outside-in view.

launch_arg("lidar", true, "Launch lidar")
launch_arg("imu_apply", false, "Launch imu")

bringup = include_launch_file("linorobot_bringup","bringup.launch.py")
bringup.arg("base_serial_port", "/dev/tty/USB0"
bringup.arg("micro_ros_baudrate", 921600)

launch_print("About to launch lidar process")
if lidar: 
    lidar_launch = include_launch_file(pkg="hls_lfcd_lds_driver", launch="hlds_laser.launch.py"
    lidar_launch.arg("port", "/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0")
    lidar_launch.execute()

launch_print("about to launch imu")
if imu_apply:
    imu_launch = include_launch_file(pkg="dome", launch="imu_apply.launch.py"
    imu_launch.execute()

[christophebedard]

There have been attempts at creating a "simpler" Python launch interface, like this one: https://github.com/oKermorgant/simple_launch. It's simpler, but it means it's limited if you're trying to do more complex stuff.

Before trying to "improve" the Python ROS 2 launch system, I'd recommend trying to understand its design and capabilities. Yes, it's complex, but it's also very powerful. And, again, users are meant to use the YAML and XML frontends.

Since there's nothing actionable here, I'll close this issue. Feel free to keep discussing.

[pitosalas]

Thanks. I am interested in the topic but I don't want to waste your time.

"And, again, users are meant to use the YAML and XML frontends." -- that may be the case in the develoeprs' minds, but it doesn't come through in the doc, code examples, and functionality available to json and xml launch files.

I will take a look at the link you sent. Thanks for engaging on the topic.

[christophebedard]

"And, again, users are meant to use the YAML and XML frontends." -- that may be the case in the develoeprs' minds, but it doesn't come through in the doc, code examples, and functionality available to json and xml launch files.

I will take a look at the link you sent. Thanks for engaging on the topic.

You are definitely right, which is why I'm hoping to change/improve the docs. First step: ros2/ros2_documentation#5093.

Thanks. I am interested in the topic but I don't want to waste your time.

You're not wasting my time 😁 If you want to help (we're always looking for help!), I think the best way to help here would be to get familiar with the launch system and then help improve the docs like I've outlined above in #832 (comment). For some actions/substitutions/etc., YAML/XML support might be incomplete, which is part of why there aren't a ton of YAML/XML examples, so improving that would be great too.

[pitosalas]

As an example, I am trying to do this:"

launch:
  - node:
      pkg: nav2_costmap_2d
      exec: costmap_2d_node
      name: local_costmap
      output: screen
      include: "$(find-pkg-share obstacle_perception/config/local_costmap_params.yaml)"

How do I do it correctly? And where in the launch source code should I have looked to see if that include is a valid submode of node, or whether I should have a param: key first?

[christophebedard]

You'd need to understand/find that include and node are two separate actions, so they're two separate structures. As for arguments of each action (e.g., node's pkg/exec/etc.), they are parsed with entity.get_attr() in the action class' parse() function: https://github.com/ros2/launch_ros/blob/d3e2350b29d279ba4b9cbecfdc0db47dfb073e98/launch_ros/launch_ros/actions/node.py#L306 (but you might have to look at the parent class to find the attributes that it parses).

But, again, I know you shouldn't have to know this/look at the source code to figure this out. We're working on improving the docs.

As for your actual question, you can refer to the example you included in your comment above (#832 (comment)) or here: https://docs.ros.org/en/rolling/How-To-Guides/Launch-file-different-formats.html#launch-file-examples (select the YAML tab)