Re: Some questions about the Esterel primer...

Hello,

Herman Bruyninckx wrote:
> Okay, I see where my confusion came from: ``control'' in my vocabulary
> _is_ the same thing as what you build with block diagrams etc. While
> you are using the term for what I would call ``programming''.
> One more of these terminology ambiguities :-)

ok, you're right:-) "control", for computer scientists, is related to
control structure, i.e., sequencing, which is what I meant here.

> I also consider this separation to be the same one that one has in
> hybrid systems: the continuous part is the ``data flow'', the discrete
> part is the ``control''. Or am I misunderstanding again?

you're exactly right.

> > sampled implementation. A data-flow reactive language can then handle
> > these control equations as calls to elaborate numerical computation
> > functions (themselves written in another langage, e.g. C, for
> > efficiency).
> 
> So, this means that they are perfectly suited for _simulation_ systems
> such as Dymola or 20Sim?

I must say I don't know these systems;

> > StateCharts is a hierarchical-parallel-FSM language, a bit different
> > from the synchronous languages (cousin rather than brother/sister), so
> > it handles sequential control well. One of its dialects is StateFlow in
> > Mathlab/Simulink.
> 
> What is your opinion about the suitability of these languages for
> robot control software?

The advantage of StateFlow is that it is fully integrated in
Mathlab/Simulink;
on the other hand, semantics of the language is not so clear, and it
seems the code produced is quite unefficient, compared to that of
synchronouslanguages. And also, they are expensive, and not open at all.


> > Actually, it will not be non-deterministic: if you have two source
> > producing values for the same variable or signal, you will have to
> > define how they should be combined in order for the global result to be
> > coherent, which seems a good thing.
> 
> This would require ``global knowledge'' about your system, I guess...
> Which I think is not realistic in a distributed control environment.

well, does it have to be so global? at each place where you have a value
which can come from several sources, you have to make a choice, simply:
isn't that part of the programming anyway?

> > IMO, Maestro is meant for end-users not willing to go into detaild event
> > treatment in Esterel;
> 
> Okay. That's a Good Thing(TM) :-) We need such a level of
> specification.

ok; but you might also want to go deeper sometimes, and then Esterel is
quite manageable actually.

> > for designers, Esterel is a bit more complex and
> > technical, but then it offers the right techniques to handles precisely
> > those details.
> 
> Comparison to the above-mentioned StateCharts/StateFlow? (As far as
> suitability for robot control is concerned.)

I would say they are of the same class: states and events, with actions
attached to them ...
It is the Maestro kind of specialized language which is simpler.

> > We would be happy to present Orccad at an Orocos meeting, and interested
> > people are certainly welcome to come and visit our robotics lab where it
> > is used.
> >
> Great! Let me know when there is an event at your lab where these
> topics are presented.

As Daniel says, it may be combined with an Orocos event, or it can be
put up especially if people in the Orocos list show interest.

> Thanks for the insights! (And don't forget to answer the new questions
> I have :-)

you're welcome:-) we are happy to participate in a discussion on these
topics.

Eric

-- 
Eric Rutten                  INRIA Rhône-Alpes                projet BIP 
ZIRST, 655 avenue de l'Europe, MONTBONNOT, 38334 ST ISMIER Cedex  FRANCE 
tel:+33 (0)4 76 61 54 02                        fax:+33 (0)4 76 61 54 77 
e-mail: [email protected]       web: http://www.inrialpes.fr/bip/