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

>>   while (true)
>>   {
>>      robot.read();
>>      cm.update(getTime(), period);

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

We pass in two times into the update method to deal with the
difference between the system clock and the monotonic realtime clock.
The first argument is the (estimated) non-monotonic system time, which
the controller can use to stamp data it sends out to other components,
and to compare with timestamps of incoming data from other components.
 But since the system time is non-monotonic (it can be modified by
e.g. an ntp daemon), it can't be used to compute e.g. the time
difference between different update cycles. So therefore the
controller also need access to a monotonic clock. To make it very
difficult to mix up the system clock and the monotonic realtime clock,
we pass the system time in as a ros::Time, and the monotonic realtime
time as a ros::Duration -- which maps on two common uses of the two
clocks: stamping data and computing the time difference between two
update cycles.


> 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.

Sounds like a good plan for now.

> 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.

I'm very much in favor of keeping the controller manager sequentially.


> 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.

+1

-Wim

--
Wim Meeussen
CTO, hiDOF Inc.
650-529-4522
http://hidof.com
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev