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

On Fri, 19 Apr 2002, Christian Schlegel wrote:

[...]
> > I see (I think). But the name ``configuration class'' seems a bit odd
> > or too general to me.
> 
> Yes, same with me. In my current implementation, I renamed it to
> "stateServer" and "stateClient". Perhaps even a better naming would
> be "stateMaster" and "stateSlave" for both parts of the pattern. The
> master is that part which has the setState etc. methods and the
> slave is the one getting the main state set from outside and
> acquiring substates etc.

Ok, I see we are thinking along exactly the same lines here! And
talking about implementation, I belief more and more that this
functionality belongs in its own library; and thinking consistently
with what you say above this would be a GSM (Generalised State
Machine) library, with the FSM and Petri nets as the activity within
the stateServer and stateSlave, andthe extra functionality of
externally sequencing the state originating from the stateServer.
If I read my own description again, I am quite sure we will find
somewhere a class library that implements this already exactly...

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.

[...]
> > Why should Genom be better suited for these purposes?
> 
> Don't know really but I know some people (working on
> microcontrollers and with realtime requirements) who mostly think in
> functions and I think they are very happy with Codels.

I see no reason why codels are impossible in your
stateServer-stateClient patterns: the stateServer sends out its
synchronization events, and it's up to the stateClients to decide
whether or not they execute their currently running activity
atomically or not.

Probably I am too optimistic now, but I think we just solved the
implementation questions that I had about the Genom stuff: their
``control flow'' is what we would do with the stateServer-stateClient
pattern, and their ``data flow'' is what the semantics of the task
requires the stateClients to do. 
Maybe this interpretation is wrong, of course :-)

> I also know many people thinking in threads (like myself) and I don't like
> fine-grained functions too much.....

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.

[...]
> 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.)

[...]
> Yes, more or less the same thing as soon as you allow for dynamic
> reconfigurations of the state engine. However using an automaton
> normally is very complex at some level of abstraction since YOU have
> to think on every state transition. Using a task net interpreter allows to
> separate task specification from the task net interpretation engine.
> Of course, every task net can be fully expanded into an (hierarchical)
> automaton.

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

Herman