# Why is Parameter\_event being written?

**URL:** <https://discourse.openrobotics.org/t/why-is-parameter-event-being-written/734>\
**Category:** ROS General\
**Created:** [October 26, 2016, 4:22pm UTC](https://discourse.openrobotics.org/t/why-is-parameter-event-being-written/734 "2016-10-26T16:22:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![vdiluoffo](https://avatars.discourse-cdn.com/v4/letter/v/8edcca/32.png) [@vdiluoffo](https://discourse.openrobotics.org/u/vdiluoffo)\
**Post date:** [October 26, 2016, 4:22pm UTC](https://discourse.openrobotics.org/t/why-is-parameter-event-being-written/734/1 "2016-10-26T16:22:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dirk-thomas](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/dirk-thomas/32/4328_2.png) [@dirk-thomas](https://discourse.openrobotics.org/u/dirk-thomas)\
**Post date:** [October 26, 2016, 4:31pm UTC](https://discourse.openrobotics.org/t/why-is-parameter-event-being-written/734/2 "2016-10-26T16:31:45Z")

</div>

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 [Parameter API design in ROS](http://design.ros2.org/articles/ros_parameters.html) The topic you are seeing is used to notify anyone interested about parameter changes.

---

<div class="post-metadata">

**Author:** ![vdiluoffo](https://avatars.discourse-cdn.com/v4/letter/v/8edcca/32.png) [@vdiluoffo](https://discourse.openrobotics.org/u/vdiluoffo)\
**Post date:** [October 27, 2016, 3:36pm UTC](https://discourse.openrobotics.org/t/why-is-parameter-event-being-written/734/3 "2016-10-27T15:36:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dirk-thomas](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/dirk-thomas/32/4328_2.png) [@dirk-thomas](https://discourse.openrobotics.org/u/dirk-thomas)\
**Post date:** [October 27, 2016, 3:49pm UTC](https://discourse.openrobotics.org/t/why-is-parameter-event-being-written/734/4 "2016-10-27T15:49:48Z")

</div>

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.