[JTC] ⏰ remove state publish rate parameter and logic and publish on each update.

[destogl]

No description provided.

[arne48]

I assume this is implementing the changes mentioned in #473.
To me the changes look good and complete.

Edit: I don't know if there is an intended pattern for this already, but maybe it could be considered to add an RCLCPP_INFO message that the parameter was removed if we still find it in the yaml file.
This could help users who don't read the docs too often (or don't remember the log output) explicitly why after an update a parameter has no effect anymore.
This could reduce the cluttering of config files in the field.

[jaron-l]

It seems like the only time when it would be useful to change the time in the header from now to a specified time would be in testing. Would it be better to just leave it as is and then create a standard test function that uses this publish state function correctly?

[destogl]

This is still good to have in any case. We are getting time from controller manager to have it consistent. So I would keep this as it is sinc this is the control time

[destogl]

I don't know if there is an intended pattern for this already, but maybe it could be considered to add an RCLCPP_INFO message that the parameter was removed if we still find it in the yaml file.
This could help users who don't read the docs too often (or don't remember the log output) explicitly why after an update a parameter has no effect anymore.
This could reduce the cluttering of config files in the field.

We will do that for Humble. On the Rolling we just kick it out for the simplicity. People using Rolling should follow what is happening. Is this reasonable, or you think that would confuse too many people?

[arne48]

I don't know if there is an intended pattern for this already, but maybe it could be considered to add an RCLCPP_INFO message that the parameter was removed if we still find it in the yaml file.
This could help users who don't read the docs too often (or don't remember the log output) explicitly why after an update a parameter has no effect anymore.
This could reduce the cluttering of config files in the field.

We will do that for Humble. On the Rolling we just kick it out for the simplicity. People using Rolling should follow what is happening. Is this reasonable, or you think that would confuse too many people?

This addresses my question pretty well. And I agree that "Rolling" users are (should be) more likely to keep track on the changelogs.
If an information will be prompted to the "normal distribution" users I think that would be totally sufficient.
Thank you @destogl.