Why is Parameter_event being written?

Next Generation ROS
1

Hi,
I’m running the talker example in alpha 7 with an RTI 5.2 and using the Spy tool to see traffic being generated. The following is being captured by Spy:

1477496933.683665 W +N C0A801C3 parameter_events rcl_interfaces::ms
… g::dds_::Parameter
… Event_
1477496933.684083 W +N C0A801C3 chatter std_msgs::msg::dds
… ::String
My question is why is the parameter_event present and not only chatter?

Thanks
Vince

2

Each ROS 2 node has a parameter API to configure node-specific parameters (similar to dynamic_reconfigure in ROS 1). The details are described in http://design.ros2.org/articles/ros_parameters.html The topic you are seeing is used to notify anyone interested about parameter changes.

3

Hi Dirk,
Thanks for the links It seems that from the articles this is replacing the parameter server logic. I did see Thibault Kruse comments:

Subscribing to param changes via callback services is clumsy, so updates should be sent over topics.
Setting params over topics has the disadvantage that no feedback can be given (such as error codes), so services are to be chosen. The final decision is whether to use a single topic or individual topics for publishing current parameters and updates, and who is responsible for publishing.
A node param will be set using a service of the node. Global params will be set using a service of master. The node, after validating the param, updates it internally. After that, any interested 3rd party needs node to be informed of that change. The node publishes the updated set of its params on its own param state topic.

Is there a design decision for not having this an option (notification topic) and it seems that the topic name should be unique or follow the node name. For example, nodename_parm_event.vs parameter_event as a topic? It seems that generating a separate topic becomes messy when having a lot of nodes/topics in a network. Could the change event or flag be part of the node itself vs separate?

Thanks
Vince

4

There are many questions remaining open atm regarding what names should be global vs. namespaced by each node. So the current approach doesn’t mean it is final. In this specific case I could see both topics as being useful depending on your use case.

Also with the option to remap topics in the future if the node only publishes on one of these topics you could always change the name of the topic when starting the node.