On Thu, Jan 31, 2013 at 6:55 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo.rodriguez@pal-robotics.com> wrote:
> 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
So this also seems like it's a decision between serial (1) or parallel (2)
computation of different components of the final output signal. Is that
correct?
On Fri, Feb 1, 2013 at 3:48 AM, Carles Lopez <
carles.lopez@pal-robotics.com>
wrote:
> My two cents: maybe allowing single controllers to return the expected
> time they want to be updated given their own internal state. With this
> information control manager will adapt its own rate depending on the
> earliest deadline of the controllers it manages.
>
I like this bottom-up strategy, since it would also help debug
timing-related problems since the system will know at what rates each
components needs to run.
-j
--
Jonathan Bohren
PhD Student
Dynamical Systems and Control Laboratory
Laboratory for Computational Sensing and Robotics
The Johns Hopkins University
(707) 520-4736
jbo@jhu.edu
(text/plain)