-
Notifications
You must be signed in to change notification settings - Fork 163
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
YAML parser: support mixed types #463
Comments
The error message is somewhat misleading here and there's more preventing the above from working than just the YAML parsing. There is not currently a supported parameter datatype for dictionaries/associative arrays. The supported datatypes are listed in the design doc describing parameters. As a start, improving the user experience so the error text points out the conceptual issue rather than a parser error would be most welcome. Is that something you would consider contributing @christianrauch? If there are additional parameter datatypes that you would like to see, I think a PR to the design article linked above would be a a good start. |
Is it a conceptual issue that this kind of parameter is not supported? I.e. is it possible to support this later or will this never happen? These kinds of parameters definitely worked in ROS1. For example, this: <rosparam param="tag_descriptions">[
{id: 0, size: 0.163513},
{id: 1, size: 0.163513, frame_id: a_frame},
{id: 2, size: 0.163513, frame_id: tag_2},
{id: 3, size: 0.163513},
{id: 4, size: 0.163513},
{id: 5, size: 0.163513}]
</rosparam> could be added to a launch file and represented and used in the node as I am fine with the error message per se, but I think that ROS2 needs an equivalent representation for this kind of heterogeneous key value maps. |
I don't believe there's a conceptual issue. As @nuclearsandwich points out, what needs to be done is to add support for a new datatype to handle dictionaries. In order to do this we should extend the rcl_variant_s struct. It might make sense to define a new array of variant type, A agree that a PR to the design article that @nuclearsandwich referenced is the place to start. |
This would really make things easier, and people should rightfully be able to expect (at least that degree of) YAML support for something that is called a YAML file. |
I was surprised today to find that ros2 supports only basic yaml syntax and had to resort to parsing by myself to avoid changing the whole structure. In addition to complex and mixed type lists it would also be nice to see anchors / aliases supported. Any reason ros2 is using its own parser instead of e.g. yaml-cpp? |
The ROS 2 parameter parser uses the third-party parser from libyaml. I think we are not using yaml-cpp specifically because If you'd also like to see other YAML features supported, feel free open a feature request, or even better a pull request :) |
That makes sense. I must have missed that, sorry. Will open a feature request. |
This comment was marked as abuse.
This comment was marked as abuse.
Just wanted to raise here that the issue still exists (in ROS2 Humble). Below is a minimum example YAML file needed to reproduce the error message:
I wanted to load this YAML file in ROS2 launch file using
|
As a consequence, creating laser filters from parameters seems to be unusable as configuring a filter chain is not possible... |
This is not supported in rolling, https://docs.ros2.org/foxy/api/rcl_interfaces/msg/ParameterType.html. btw, is that supposed to be the following, which can be parsed. root@tomoyafujita:~/ros2_ws/colcon_ws# cat demo_params.yaml
parameter_blackboard:
ros__parameters:
color:
name: red
code:
r: 255
g: 0
b: 0
hex: F00
root@tomoyafujita:~/ros2_ws/colcon_ws# ros2 run demo_nodes_cpp parameter_blackboard --ros-args --params-file demo_params.yaml
[INFO] [1680299494.598974816] [parameter_blackboard]: Parameter blackboard node named '/parameter_blackboard' ready, and serving '10' parameters already!
root@tomoyafujita:~/ros2_ws/colcon_ws# ros2 param list
/parameter_blackboard:
color.code.b
color.code.g
color.code.hex
color.code.r
color.name
qos_overrides./parameter_events.publisher.depth
qos_overrides./parameter_events.publisher.durability
qos_overrides./parameter_events.publisher.history
qos_overrides./parameter_events.publisher.reliability
use_sim_time |
@fujitatomoya Does this work in humble? Also, the issue I saw was with tag in a launch file. I don’t know if there is any difference loading it via command line for a node. |
yes it does. |
FWIW while a list of dicts is not allowed, a dict of dicts is OK
which seems rather counterintuitive as one would expect a dict of dicts to be more complicated than a list of dicts. |
I've implemented this workaroud in my serialization library if someone is interested -> https://github.com/asherikov/ariles/blob/head_2/tests/api_v2/demo_api_v2_ros2.yaml, https://github.com/asherikov/ariles/blob/head_2/tests/api_v2/demo_api_v2_ros2.cpp. |
Bug report
Required Info:
Steps to reproduce issue
__params
)Expected behavior
The yaml parser should parse the YAML structure.
Actual behavior
The parser fails with:
Failed to parse yaml params file '[configuration].yaml': Sequence should be of same type. Value type 'integer' do not belong at line_num [line with "id: 9"], at /tmp/binarydeb/ros-dashing-rcl-yaml-param-parser-0.7.5/src/parser.c:931
I.e. it won't accept that
frame
andid
are of different type (string, int).Additional information
This has been supported in ROS1 (e.g. in the configuration of apriltags_ros) and should be made available for ROS2.
The text was updated successfully, but these errors were encountered: