Re: FSM vs. Petri nets for component modelling...

>I would imagine that one needs _more_ than a logical behaviour,
>in the sense that many control laws have _dynamic_ implications, such
>that time and smoothness constraints are, in general, important. Any
>experience with including these into Esterel (or other) descriptions?
>Any idea how much of this functionality can/should be visible to the
>`normal' user? (That is, not the designer of the framework, but the
>guys that implement the control law and trajectory generation
>components.)

The control law is assumed to be designed and tuned by an automatic control 
expert. There are three steps in the control law life:

init code, used to initialize variables and parameters, e.g. recursive 
filters, memory allocation, checking for pre-conditions
periodic computation of control (infinite loop),
end code, for exporting post-conditions, memory deallocation etc...

The periodic infinite loop computes the control, but also the observer 
functions used to trigger exceptions (joint limits, sensor failure..) and 
synchronisation events (e.g. to synchronise the motion of several robots 
sharing a same workspece). All these functions are predefined, and the 
structure of the control task is static, in particular because it is very 
difficult to predict the real-time behaviour of a dynamically reconfigurable 
control scheme.

The "normal" user (at the application level I guess?) uses these well tuned 
control tasks through their event based bahaviour. He must have knowledge 
about the functionnality of the control algorithm and about the defined 
exceptions, and also he have access to the set of parameters.

At the application level it is easy to combine these events to design the 
behaviour of the application, e.g. to define what must be the new control 
according to the exception which has been raised. In particular the Esterel 
compiler nicely combines the basic bahaviours of control tasks and end-user's 
specification in a single FSM at the application level (at least if the 
application supervisor is centralized).

It should be useful to also have application level observers (functions like a 
Kalman filter, not only discrete events combination): this is far more 
difficult to implement (specially in an automatic code generator providing a 
safe real-time behaviour).

Smooth control tasks switching is another difficult problem. From the control 
side, hot switching with a well controlled transient needs that some 
regularity condition between successive controls holds (e.g. the task 
functions must have the same size). In some cases it may be necessary to run a 
transient task to glue the two main ones.

From the computing side, it is necessary to minimize the transient duration, 
run the init code, maintain the robot under control and avoid a computer 
overload... This painful problem is only partially (but automatically) solved 
in the current Orccad release (single processor and single loop).
 
	Daniel