Re: (no subject)

On Tue, 4 Dec 2001, Cezary Zielinski wrote:

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

Have you ever felt the need to monitor/check the range of change of
the variables? Or do you rely on the exception handling to make sure
the change doesn't lead to wild excursions of the robot motion in case
the parameter changes are ``too large''?


> 2. Switching the control law structure
>     - this is complicated, as new control variables are introduced
>     and they have to be properly initiated.

This is indeed the major problem, I know. But what I would like to do
as this moment is to find out (more or less) what the real problems
are, in order to see whether or not such flexibility should/could be
included in the ongoing design. If we have _some_ clue about how to do
this, my suggestion is to include the necessary ``hooks'' into the
design, but in such a way that this overhead need not be taken along
by somebody who doesn't need these advanced features. I was looking
for answers on the following questions: what parts of the
GenoM/MRROC++/Orccad/...  approach are essential/useful for the
required flexibility, what more is needed, and what would be a good
design?

>     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

These are indeed relevant cases. My doubts are on how to offer this
feature: relay it to the user's servo loop code, or offer support for
it in the framework we are designing? For example, in the form of a
FSM/Petri Net in which the user ``only'' has to fill in a minimum of
information. The latter apporach is only valid _if_ we find a proven
``Pattern'' for the problem :-)

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

There are different levels of needs. I call them ``hot swappable,''
``warm swappable'' and ``cold swappable'' flexibility:
 - hot swappable: one wants to go from one control law to the next in
   one (or a limited, deterministic) number of samples. We have this
   need in our force-controlled systems, where a detected change of
   contact situation requires an ``appropriate'' change in the control
   law.

- warm swappable: similar as hot swapping, but now the motion of the
  system can be stopped, and the switch to the new controller
  initiated. The new controller is only allowed to have a ``compatible''
  state with the running controller; that is, the new state is a very
  simple function of the old one. In practice: the same state, or a
  subset or a superset.
  We have this need when we want a ``soft interrupt'' to an ongoing
  motion: the speed is reduced to a fraction of the nominal speed.

- cold swapping: the motion is halted completely, and a new controller
  is started. The only advantage of this approach is that no reboot of
  the software is needed.

(The fourth possibility is reboot/recompile, but this doesn't deserve
to be names ``swapping'' :-) )

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

I also had these considerations in mind. But I think we have to go a
bit further: a ``control law'' in my opinion is not just a function,
but also a number of constraints (maximum errors, maximum
accelerations, etc.), which, in software terms would be called the
``interface contract'' of the control object/component. And that
object could have an internal FSM/Petri Net for controlling the
transitions in the switch to another controller, _with_ a check of the
constraints, and possible an action to get the constraints in sync. I
think this is not too straightforward, but, again, there is a
difference between _foreseeing_ such a possiblity (what I would like to
do) and _implementing_ it :-)

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

Indeed! The first and major ``clients'' of Orocos will be academia :-)

About `visibility': we think to foresee two levels of
authentication/authorisation for the control components: the normal
user (which is the one who runs/programs, for example, a control law
routine, to be executed in the framework), and the supervisor, who is
allowed to do reconfiguration etc in the framework.
Each component will have a different interface for each of the user
levels.

herman