On Fri, Feb 1, 2013 at 6:08 PM, Jonathan Bohren wrote: > > On Thu, Jan 31, 2013 at 6:55 AM, Adolfo Rodríguez Tsouroukdissian > 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 > 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. Indeed, that was the main reason for this approach in our motors manager, for instance when the hardware is not responding fast enough or your bus is not reliable. Also this event driven approach needs only one single thread so (i) no concerns about concurrent access, (ii) it serves controllers as fast as they require and (iii) it yields the CPU if you set the appropriate timeouts in your I/O operations (i.e. a little bit before your next deadline) > > -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 > > -- > Orocos-Dev mailing list > Orocos-Dev@lists.mech.kuleuven.be > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev > -- Carles Lopez Software Engineer carles.lopez@pal-robotics.com http://www.pal-robotics.com Pal Robotics, S.L. c/ Pujades 77-79, 4t 4a 08005 Barcelona Tel: +34 93 414 53 47 Fax: +34 93 209 11 09 Skype: carles.pal-robotics Facebook http://www.facebook.com/palrobotics1 Twiter http://twitter.com/#%21/palrobotics PAL robotics http://www.youtube.com/user/PALRobotics channel AVÍS DE CONFIDENCIALITAT: Aquest missatge i els seus documents adjunts poden contenir informació privilegiada i/o confidencial que va dirigida exclusivament al seu destinatari. Si vostè rep aquest missatge i no és el destinatari assenyalat, o la persona encarregada de l'entrega a la susdita persona, si us plau, notifiqui-ho immediatament i remeti el missatge original a l'adreça de correu electrònic indicada. Qualsevol còpia, ús o distribució no autoritzats d'aquesta comunicació és estrictament prohibida. AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida. CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.