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

>A `pre-condition' is an event? Strange. How does this work?
They are events in the event-based external view of the control task. Some of 
them are user-defined (e.g. Run-Control-SE3) and can be associated with 
measurements (initial-position,timeout). Many others are hidden at system 
level (e.g. Init_OK, rt_tasks_resumed...) and are automatically generated. 
Anyway, these evnts can be elaborated by functions (observers), at the control 
task level (current implementation) or at the procedural level.

>What is ``transient cpu overload''?
During the transition the two control laws overlap potentially leading to 
overruns if nothing is done (decreasing the sampling rate, playing with 
priorities...). We also designed a simplified transition process, usable e.g. 
to schedule vision tasks where nothing have inertia.

>What are the system calls in your current implementation?
All tasks (control, FSM, clocks) are under control of the RTOS (VxWorks and 
soon RTAI, also solaris and linux for soft rt). Thus system calls are e.g. 
pthread_create(), SemGive() to unlock a control task, msqQSend to send a event 
and awake the automaton...

>Esterel...Can you explain in what sense it can harm?
OK, not harm, but difficult. It requires experience to avoid some subtle 
traps, e.g. instantaneous loops and circuits (something well understood by 
people coming from digital hardware). Also, even if the compiler checks for 
many things, it cannot detect your specification errors, even if formal 
verification can also help at this level. A end-user oriented language like 
Maestro handles higher level structure (which are called robot-tasks for 
historical reasons, but we could call them control-tasks) and hide the low 
level details (which can be anyway checked in the generated strl if necessary, 
but this is normally useless as a lot of work as been done in the design and 
implementation of the tasks).

>about Esterel and Signal: my personal experience is that problems which are 
easyly stated with Esterel are very difficult to handle in Signal and 
conversely. Also, they are very useful to design event-based controllers but 
they are not general purpose languages. In particular the non elementary 
numerical computations are extern functions handled by the host system.

>about UML: a statement I've seen on a developper's page: UML is fine for 
managers, not for engineers...
Besides it is mainly a tool for design, not for implementation, I think that 
the first step (partitioning the application domain into classes) definitively 
impacts all the design... but I understand that it is the goal of Orocos?

	Daniel