Re: [ros-users] [Orocos-users] Joint controller manager

On Mon, Feb 4, 2013 at 4:22 AM, Wim Meeussen <[email protected]> wrote:
>> 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:
>> ...
>
>> 2. Individual/grouped controller updating:
>> ...
>>
>> 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.
>
> Some comments specifically targeted at the current implementation of
> the controller manager:
>
> While I see the frequency divider approach has a number of
> limitations, it makes it very easy to implement the realtime loop
> around the controller manager.  It basically looks something like
> this:
>
> main()
> {
>   MyRobot robot;
>   ControllerManager cm(&robot);
>
>   while (true)
>   {
>      robot.read();
>      cm.update(getTime(), period);

what is the role of the additional period parameter above?.

>      robot.write();
>      sleepRemainingPeriod();
>   }
> }
>
> When judging other approaches, it would be great if we can look back
> and see how they affect the usage pattern of the controller manager.
>
> When applying this test to the approach where each controller
> specifies its required update rate, at first glance it looks like we
> could keep the realtime loop pretty simple. Based on all the desired
> update rates, the controller manager could compute the desired
> sleep/wakeup time between different controller runs, and expose this
> duration/time to the person writing the realtime loop.
>  I'm not sure yet what the exact implementation details would look like
for
> different realtime OS's, or when using the controller manager with
> RTT.

I'd stick with the current controller_manager design and not deal with
clock/timer issues, but rather push this responsibility downstream. It's
not trivial to provide a solution that works well across different
(realtime) OS's and simulation environments. Reference implementations of
common controller_manager use cases can be made available in the
documentation to assist prospective users in this respect.

As an alternative, I was thinking of adding an accessor to the
controller_manager that returns some sort of handle to a controller, which
allows to update it from the outside. One can then attach timer triggers to
controller updating callbacks. Code-wise, this could look like:

// Get handle: To be done at configuration time, as it's likely a
non-constant time operation
handle = cm.getControllerHandle(controller_id);
assert(handle && "Controller handle KO!");

//...

// Use handle: alternative 1
handle.update(time);

// Use handle: alternative 2
cm.update(time, handle);


Could someone shed some light on how they intend to use the
> controller manager with RTT?

I'll detail a bit more (my view of) the timer approach suggested by Herman.
Consider a system with two Orocos components (two threads):
- The controller_manager, whose thread is non-periodic, and has n
event-triggered input ports. When a port is triggered, it executes some
work (update a controller, read hardware ,etc.). Without external triggers,
the controller_manager component does nothing.

-  An OCL Timer component [1] configured with n timers which trigger the
ports of the controller_manager. Note: You could also setup non-periodic
update policies here if it made sense to your application.

An important thing to note with this setup is that although triggers come
from outside  the controller_manager, the actual work is executed _in_ the
controller_manager thread, so no concurrency handling is required. I
overlooked this benefit in my previous post (!!!). Relating to Jonathans's
question on parallelism: there is none here, work is still done
sequentially inside the controller_manager.

Another relevant remark is that with such a setup, the controller_manager
and its controllers remain agnostic of the update policy (periodic, batch
or individual update, ...), which IMO is good.

Now, if someone comes up with a different setup in which external thread(s)
not only trigger controllers, but actually execute controller update code,
then you _do_ need concurrency handling, and you can have parallel code
execution. At any rate, the controller_manager implementation should stay
simple and not do any concurrency handling itself, but clearly document its
guarantees.

[1]
http://www.orocos.org/stable/documentation/ocl/v2.x/api/html/classOCL_1_1TimerComponent.html

Adolfo.

>
> Best,
> Wim

-- 
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
[email protected]
http://www.pal-robotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
Skype: adolfo.pal-robotics
Facebook - Twitter - PAL Robotics YouTube Channel

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.

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev