(no subject)

Reply to Hrman's comment about switchable control laws.

MRROC++ has two kinds of control law switching incorporated into it:
1. Switching of parameters for a control law with a fixed structure
    - this is fairly easily done, as the algorithm functions on the same variables - only its parameters change.
2. Switching the control law structure
    - this is complicated, as new control variables are introduced and they have to be properly initiated. 
    For example: if the currently used control law was PD and we are switching to PID an integral term has to be introduced and initiated    (in   this case it would be initiated to 0, but if other control laws are utilised the situation is usually much more complicated.)  For this case I have only the solution for simple cases, where all the control laws are known in advance. How to deal witha a case where the control law is not know in advance I don't know. Nevertheless I am not sure that such a need will arise.

Obviously the description of control laws is usually done in functional form. No need for FSM or PN in this case. FSM are of use when considering the controller as a whole (e.g. including exception handling). PNs are of use when in a multi-robot system eof of the robots performs partially independently and their actions have to be synchronised in time ans space from time to time. In other words each robot's FSM has to be synchronised withe other ones. Merging PNs, FSMs and functional description is not very difficult and quite useful.

Whether the control law should be visible to the user is another question. I assume that we are anticipating, among others, also users from the research community. Under this assumption the answer to this question should be - yes. There is quite a lot of research regarding diverse control laws and we should address those needs as well.

Cezary

On Mon, 3 Dec 2001, Daniel Simon wrote:

>[... I'm also answering to Cielinski's reply...]
>> We have such kind of reconfiguration in Orccad, where the whole running
>> control law can be stopped and replaced by a new one during task execution.
>> Thus control laws are encapsulated in a logical behaviour stating starting,
>> stopping and exception handling. As hand writting of FSMs by hand  is
>> difficult and error prone, this logical behaviour is specified with Esterel,
>> thus most of the job is done by the strl compiler. Obviously this model can
>> handle control tasks running in parallel.

>Thanks for the insights! Seems that there is quite some prior
>experience in this point, which is great. One question I still have is
>this: 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.)

Herman