Re: Some questions about the Esterel primer...

On Fri, 7 Dec 2001, Eric Rutten wrote:

> Herman Bruyninckx wrote:
> > - p.14 ``As of now, there is no completely satisfactory way of
> >   unifying the data- flow styles of Lustre and Signal and the control
> ...
> >   Where can I find more information about these differences?
>
> data-flow (i.e., block-diagrams, equations) and control (i.e.,
> imperative sequencing, FSM) are quite different structures for
> programming constructs, and work quite differently:

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

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?

> work on Mode Automata by Florence Maraninchi e.a.
> (http://www-verimag.imag.fr/~maraninx/MATOU/index.html)

Thanks! I hope this will answer my quest for the holy grail of
faithful and efficient representation of hybrid systems :-)

> Reactive systems are mainly about Discrete Event systems; they can
> describe "continuous" dynamics once it is discretized as an endless loop
> 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?

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

> > - p.25 ``Valued Signals Versus Variables''
> >   I learn from this Section that it is not a good idea to make events into
> >   objects that can carry data: if two processes generate the same event
> >   but with different data in the ``event object'', this will sooner or
> >   later lead to indeterministic behaviour because different processes
> >   will handle the events in different order. Is this a correct conclusion?
>
> 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.

> > Can you explain in what sense it can harm? Can you share some of your
> > experience and thoughts on this Maestro approach?
>
> 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.

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

> > maybe there happens to be a similar event (organised at your
> > lab or somewhere else) in the not so far future
>
> 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.

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

Herman