Question: How to dynamically configure a controller's `update_rate` during `on_configure()`?

[skywoodsz]

Hi, I have a question about the intended design of per-controller update_rate in ros2_control.

Currently, a controller can specify its own update frequency through YAML:

controller_manager:
  ros__parameters:
    update_rate: 1000

stand_static_controller:
  ros__parameters:
    update_rate: 50

This works when the update rate is known before configuration. However, for some controllers, the actual update frequency may only be known during on_configure(), after reading and validating other parameters.

My concern is that update_rate seems to be treated as a static parameter used by the controller manager for scheduling. Therefore, changing the controller's update_rate parameter inside on_configure() may not reliably affect scheduling.

Questions:

• Is per-controller update_rate intended to be known before on_configure()?
• If a controller sets its own update_rate in on_configure(), will controller manager use the updated value?
• Is there a recommended API for dynamically setting a controller's update rate during configuration?
• If not supported, should controllers instead run at the manager frequency and implement internal timing/decimation using the period argument?

Thanks!

[saikishor]

Hello,

Unfortunately, right now there is no way to set the update_rate from the controller directly. The problem is this might open a rabit hole of the controllers changing the rate on the fly.

Can you give an example of your usecase like how this is determined etc. we can see if there is a way to fit in.

Thank you

[skywoodsz]

Hi, @saikishor

Thank you for the explanation.

My use case is from RL deployment. In our controller setup, we usually have:

• a high-frequency low-level PD controller, and
• a low-frequency policy inference loop.

The relationship between these two rates is defined by decimation. The high-frequency control timestep is determined by a user-specified physics_dt.

So conceptually:

low_level_pd_rate = 1 / physics_dt
policy_rate       = 1 / (physics_dt * decimation)

In this setup, the user normally only specifies physics_dt and decimation. I would like to avoid requiring the user to manually calculate both controller frequencies and then write them statically into the controller YAML every time.

Ideally, the controller could determine its own effective update_rate from these parameters when it is loaded/configured. This is especially useful for experiments, because physics_dt and decimation may be changed through parameters to compare different control frequencies.

Currently, I implemented this in on_init() by reading physics_dt and decimation, then setting the controller update rate accordingly. It works in my test, but I feel this may not be the most elegant or intended way to adjust the controller frequency.

So the main goal is not to let the controller arbitrarily change its rate at runtime, but to derive the rate deterministically from other controller parameters during initialization/configuration, so that the YAML remains less error-prone and easier to maintain.

Do you think there is a recommended pattern for this kind of use case? Or would it make sense to support deriving update_rate from controller parameters before configuration?