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

Herman Bruyninckx wrote:

> On Fri, 19 Apr 2002, Christian Schlegel wrote:
>
> [...]
> > > The communication patterns form a framework since they assist the
> > > component developer and the component user in building and using
> > > distributed components in such a way that the semantic of the
> > > interface is predefined by the patterns.
>
> Indeed. This is the clearest description about these things that I've
> seen till now. I add it to the glossary on the web page.
>

Fine !

>
> > > However, the communication
> > > patterns do not help the component developer in structuring the
> > > internals of a component. However, communication is related to the
> > > internal component structure since the communication patterns provide
> > > blocking calls which must be interruptable independently of what the
> > > component developer is doing inside his component.
>
> Your ``is related to'' I would rephrase as: ``supports the
> specification and implementation of''.

Ok ....

>
>
> > > The configuration class provides a thread level activity control and
> > > leaves it to the user what he is doing inside his threads as long as
> > > he uses the configuration class to lock / unlock states in critical
> > > blocks.
>
> 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.

>
> > > Methods to set states, to abort locked states and
> > > pending communication calls etc. are all provided in the configuration
> > > class.
>
> That's what I thought would be in the ``configuration class''. We've
> discussed a bit here about how to call it `correctly' but we don't
> find a more appropriate name... I do think the ``execution'' would be
> part of the name, because what one does is to influence what a
> certaint component/thread is doing at a given moment, and will be
> doing at the next moment. So, ``execution configuration'' is more
> appealing to me.

See above remark ....

>
>
> > > This now is exactly the place where Genom provides another approach.
> > > As far as I understand, the user does not put its calculations and
> > > activities into several interruptable threads (as in SmartSoft) but
> > > splits calculations / activities into codels. The execution engine of
> > > Genom now organizes the different codels in such a way that various
> > > criterions like interruptability etc. etc. are ensured. I can imagine
> > > that the Genom approach is better suited for components where one has
> > > to meet realtime constraints since the Genom execution engine gives
> > > you probably much more control on the way how codels are interleaved.
>
> 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 also know many people thinking in threads (like myself) and I don't like
fine-grained
functions too much.....

>
>
> > > The SmartSoft approach is not as fine grained and seems to be easier
> > > applicable if you have more time intensive calculations (even cyclic
> > > calculations) which you do not want to split into several codels.
>
> Where does the granularity of your activity shows up in the patterns?
> Or in Genom?  Nowhere, I think...

Look at the "smartExampleComponent20", "smartExampleComponent21" of my
sources, where
you can find a component with its internal structure. The communication
patterns do not show
any of the granularity aspects. However building a component shows this
(independently of
the used communication patterns). We are talking about two things:
communication and
internal structure / architecture of a component ....

>
>
> > > The difference between the SmartSoft and the Genom view therefore is
> > > the level of assistance and comfort (and therefore of course the level
> > > of constraints) to structure the activities within a component. Both
> > > approaches have the same goal, namely ensuring specific demands on the
> > > behavior of a component. Even though both approaches are very similar
> > > they follow a different programming paradigm influencing the way a
> > > component developer has to think on the internal activities of his
> > > component.
>
> I would like to understand better what you mean... Or I fail to
> understand the real meaning (or you fail to explain it to me:-), or
> there is no _fundamental_ difference between both approaches, only
> differences in terminology.

No fundamental difference at all ! I think, the ideas behind Genom with
respect to
an overall architecture of their robotic systems is very close to what I am
doing
at FAW. Therefore, we are very compatible with respect to our ideas. The
differences
are very marginal and I think can be seen only when looking into components
and
how they are structured internally etc.

>
>
> > > Completely independent of that level is the task execution level. Of
> > > course, one can use finite state automatons to control complex task
> > > sequences, it is often not very convenient do this since exception
> > > handling etc. is very troublesome if you have to expand every possible
> > > state sequence into the automaton.
>
> Can you give an example?

Some of my colleagues are currently at the hannover trade fair and exhibit a
robot system.
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.

Short example:

If you have a task agenda with "bring a cup of coffee into room A" and "bring
a cup
of coffee into room B", it is very unconvenient to implement a state
automaton handling
all different kinds of execptions like closed doors etc. Using task nets, one
can simply
expand the task net to drive to room A at run time considering the current
knowledge
of the environment. One can even merge both tasks to save time and energy by
getting two cups of coffee and then move to A and B etc. Think of an
automaton
handling all those different execution scenarios ....



>
>
> > > Therefore task nets (which are
> > > interpreted and can therefore be expanded depending on the current
> > > knowledge about the environment etc.) are much more suitable at this
> > > level.
>
> What is the difference with hierarchical state machines? (Where a
> transition brings you to a new state, which is in fact an FSM in its
> own, but about whose internals the external states don't want to
> know.)

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.


Christian

>
>
> Herman
>
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480
>
> _______________________________________________
> 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/
---------------------------------------------------------------------