All,

I'd like to bring up the subject of having controllers running at lower rates than the controller_manager. I can think of two possible solutions:

1. Frequency divider:
- Individual controller configurations can specify an optional parameter that states the desired frequency, or that work should be done only '1 out of n' manager cycles.
- Pros: Easy to implement. It is specific to a particular controller implementation, hence does not need to be part of the controller_manager library. See [1] for an example.
- Cons: Desired controller update period is subject to an error of up to one controller manager control period.

2. Individual/grouped controller updating:
- The controller manager allows the option of updating single controllers, or groups of them. Triggering these updates is not handled by the manager.
- Pros: Desired controller update period is unaffected by the controller manager's update period.
- Cons: This solution requires significant changes to the existing controller_manager codebase:
  - Extending the API to allow not only batch update()s, but also updates to a subset of the running controllers. Resolving which controllers to update should be a constant-time operation.
  - Add protection against concurrent access to data (eg. simultaneous read() and update()), possibly with lock-free data structures.
  - Because of the above point, the chosen concurrency handling mechanism might render reusing the existing standard hardware interfaces impossible (lock-free structures usually expose data through accessors, not raw pointers).

At the moment I'm leaning towards the frequency divider as it is sufficient for our use cases. I wonder if someone has a use case that does not fit well with this approach.

[1] https://github.com/willowgarage/ros_controllers/blob/master/joint_state_controller/src/joint_state_controller.cpp#L78