Re: [Fwd: Mini meeting Toulouse 22-23 april / ExecutionEngine]

Herman Bruyninckx wrote:

> I've been discussing with Takis and Peter about your `configuration
> pattern', and we came more or less to the conclusion that that is part
> of what we need; what we need more is the `external state
> sequencing' that we described above. The difference with the
> configuration patters (as described by Schmidt) is that we want to be
> able to send the stateClient a complete description of states it has
> to cycle through, separated by events, such that the stateServer need
> only signal the events and all its stateClients go to there next
> state. It is important for our real-time stuff that this can happen by
> means of an event only, because that is fast and synchronous. Much
> faster than the asynchronous ``suspend-reconfigure-resume'' of the
> configuration pattern. The only difference is that I want to send a
> bunch of configuration information in advance, and that the
> stateClient has that bit more of functionality that it is able to do
> the sequencing withing this bunch of information. It's the job of the
> stateServer to subdivide the complex task that comes from the `user'
> into simpler tsk for each of the stateClients that it needs to get the
> job done.

Absolutely ! The state pattern is only the prerequisite in a component to
ensure that a component allows for interruption, for selective activity etc. It
provides (completely in compliance with the communication patterns) the
functionality which is needed at least and you now can put on top of it several
mechanisms which use the state protection / state abortion mechanism etc. One
possible way to do it is to use a finite state automaton, another way is to use
a task-net interpreter etc.

If you want to send a bunch of configuration information then you focus on an
automaton inside the receiving component and not on the automaton coordination
several components. Even then there are several states resulting in external
events. Only those external events are visible to the next component (like a
task net interpreter or another automaton etc). All other states of a component
are simply private and since they react to internally manageable events there
is no need at all to make those states available externally. Therefore, there
is absolutely no inconsistency in the different views. One idea is to always
have "cognizant" components which means that a component "knows" (by the
implementer) which events etc. can be handled internally and which ones have to
be made visible. In this sense, a component always knows which kind of failure
is such critical that it can't be handled solely. With this idea you try to
manage as much as possible locally, but inform other components on more complex
problems which require global coordination e.g.

>
> Again I see nothing but consistency :-) Think about the stateClient
> as being a separate thread; think about what I called above the `bunch
> of information sent a priori' from the stateServer to the
> stateClient(s) as the codels these stateClients have to execute,
> together with the event-driven sequencing of their execution. And then
> both pictures match, don't they?
>
> The granularity of the whole thing sits only in the task semantics, as
> it should be.

Yes

> [...]
> > As soon as Boris is back, we will provide a technical note on a
> > finite state automaton used for task execution (implemented as
> > generic C++ class). This automaton is used to control a table
> > cleaning task where vision and a manipulator is involved.
>
> This sounds like the staeServer-stateClient library I sketched above :-)
> (Or nearly so.)

Exactly, only one example at the level where full-fledged task-nets are an
overkill. The automaton gets a specification of states, of transitions and of
events leading to a transition and of actions to be executed with a state
transition (e.g. sending parameters to a component, setting its new state,
activating the next events etc.). The interesting thing is that the
implementation uses the SmartSoft communication patterns (event, state, query
etc.) to coordinate several components. It therefore is an interesting starting
point for automaton based component coordination.

> Great! I understand :-) And this brings me to the other important
> point for the Toulouse meeting: how are we going to describe the
> semantics of robotic tasks? Your suggestions about the `task net' and
> the `stateServer' and the `stateClients' as the ones that _interpret_
> and _adapt_ these task nets is appealing to me. At least, as the
> _implementation_ part of the problem. Describing these tasks and their
> nets in a formal way is another thing (which we should tackle too).

Absolutely and that is what I am currently very interested in ....

Christian

>
>
> Herman
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos

--

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