You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I realise this may have been discussed before, but after searching ROS Discourse, ROS Answers and the trackers of both ros2/launch and this repository and not having any luck finding relevant posts, I figured I'd try posting here.
Feature description
It's currently possible to load parameters from .yaml files using <param from="..."/> in the XML frontend. Those files need to follow a specific syntax:
# also supports wildcards/some_namespace:
perhaps_a_node:
ros_parameters:
...
this works well, but imposes a rather significant limitation: files without this layout are not accepted.
Applications that would like to consume .yaml files from external sources can only do so after updating them to the required layout, something which may not be possible or perhaps be undesirable.
It would be great to be able to have (limited) support for loading 'arbitrary' YAML files using either the existing <param from="..."/> support, or a new element or attribute.
Implementation considerations
The Python implementation in ros2/launch does support loading arbitrary YAML, and this is frequently used by existing packages.
The XML frontend does not appear to support this, as coerce_to_type(..) errors out with "output type is not allowed, got dict".
A quick test which returns early from coerce_to_type(..) in case the loaded value is a dict seems to suggest it can work, although of course only for types the parameter subsystem supports.
If it would make integration easier, perhaps a new element could be added which accepts "bare" .yaml files, prefixes the required elements (ie: ros_arguments, etc) and then proceeds to load the updated version of the .yaml file (without changing the original). That would not seem to need changes on the side of the consuming (ie: existing) infrastructure.
Having written all of that: there are likely good reasons why the current approach is the only one supported by the XML frontend, I just wasn't able to find them.
It would be great though if launch and/or launch_ros could be extended to allow loading arbitrary YAML files, as this appears to currently be the main blocker to use XML launch files for more than just really trivial applications.
The text was updated successfully, but these errors were encountered:
Feature request
I realise this may have been discussed before, but after searching ROS Discourse, ROS Answers and the trackers of both
ros2/launch
and this repository and not having any luck finding relevant posts, I figured I'd try posting here.Feature description
It's currently possible to load parameters from
.yaml
files using<param from="..."/>
in the XML frontend. Those files need to follow a specific syntax:this works well, but imposes a rather significant limitation: files without this layout are not accepted.
Applications that would like to consume
.yaml
files from external sources can only do so after updating them to the required layout, something which may not be possible or perhaps be undesirable.It would be great to be able to have (limited) support for loading 'arbitrary' YAML files using either the existing
<param from="..."/>
support, or a new element or attribute.Implementation considerations
The Python implementation in
ros2/launch
does support loading arbitrary YAML, and this is frequently used by existing packages.An example would be most MoveIt configuration packages which load various
.yaml
files from the config directory using custom code which in the end merges a set of.yaml
files into a single Pythondict
which then gets loaded as node parameters directly.This is used for files like config/joint_limits.yaml and config/ompl_planning.yaml.
The XML frontend does not appear to support this, as coerce_to_type(..) errors out with "output type is not allowed, got
dict
".A quick test which returns early from
coerce_to_type(..)
in case the loaded value is adict
seems to suggest it can work, although of course only for types the parameter subsystem supports.If it would make integration easier, perhaps a new element could be added which accepts "bare"
.yaml
files, prefixes the required elements (ie:ros_arguments
, etc) and then proceeds to load the updated version of the.yaml
file (without changing the original). That would not seem to need changes on the side of the consuming (ie: existing) infrastructure.Having written all of that: there are likely good reasons why the current approach is the only one supported by the XML frontend, I just wasn't able to find them.
It would be great though if
launch
and/orlaunch_ros
could be extended to allow loading arbitrary YAML files, as this appears to currently be the main blocker to use XML launch files for more than just really trivial applications.The text was updated successfully, but these errors were encountered: