Re: [ros-users] [Orocos-users] Joint controller manager
Wim Meeussen <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <CAAq7VdBYuOrhaPYwvPrbcxm8G1ePp_QPex8BCCvpiRDFfYsbAA@mail.gmail.com> |
> 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);
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. Could someone shed some light on how they intend to use the
controller manager with RTT?
Best,
Wim
--
CTO, hiDOF Inc.
650-529-4522
http://hidof.com
--
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev