Re: Configuration: a service needed in OROCOS

Herman Bruyninckx wrote:

> On Fri, 6 Apr 2001, Christian Schlegel wrote:
>
> I completely follow your reasoning ! However, in the past I have tried
> and sat down with a couple of people in our lab to come up with this
> configuration specification for the motion control part of a general
> robot controller; we didn't succeed in obtaining a concrete
> specification.... Do you have more concrete suggestions in this
> particular area? Or, in another relevant area of robotics: the task
> execution?

Yes, the task execution (or how we call it: sequencing layer) was the reason
to deeper examine this topic and we ended up with a pragmatic but
nevertheless very useful specification.

>
> Or do you have a design document draft you would like to post for
> discussion? (I can put it on the WWW, or just provide a link.)
>
> My rough ideas:
> - a motion controller has different subtasks (`threads''), such as:
>   user command interpretation, trajectory generation, servo control,
>   signal filtering, etc. Modelling this by means of a FSM is not so
>   easy, except for the most trivial cases such as for single axis
>   CNC machining.
> - there is an existing analogous world which has already 50 years of
>   experience with similar problems: the operating system of a computer.
>   However, I fear the analogy doesn't run deep enough in order to be
>   really useful...

I can provide a draft document which describes our configuration class. Give
me some more time but I will post it next week.

A short answer:

The idea is not to have a finite state automaton to handle the complete
module acitivity but to provide a framework. This means different threads
within a module can run as long as a macroscopic state like "active" is
given. Several substates which can be activated in parallel under the main
state "active" might be "build long term map", "build actual map" etc. Each
map is built within a different thread which runs as long as the
main/substate is set appropriately. Changing from main state "active" to
"deactivated" results in an ordered termination of the concerned threads.
After this has been done successfully, the configuration class can
acknowledge the requested state "deactivated". In this framework it is up to
the user what he is doing within his threads and how the threads interact
via a factory model, a command queue or semaphores. But it is the task of
the configuration class to enforce reaching different global states within a
module regardless in which state a thread is (for example waiting in a
blocking query).

Christian


--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------