Re: (no subject)

----- Original Message -----
From: "Herman Bruyninckx" <[email protected]>
To: <unlisted-recipients:>; <no To-header on input>
Cc: "Open RObot COntrol Software" <[email protected]>
Sent: Tuesday, December 04, 2001 10:49 AM
Subject: Re: [Orocos] (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''?
>

No, we did not check the range of parameters as we new what we were doing.
Anyway, if we made a mistake we heard it - the robot started shaking
vigorously making a lot of noise - and then the panic button came in handy.
Here we have come to a phylosophical question: how much safety has to be
built into a research system. If you are experimenting with control laws you
have to know what you are doing (you are the author of the law, and thus its
code, and hence all the safety features). The range of parameters depends on
the control law. Otherwise you are limiting the control laws to a certain
class - then you can impose some constraints on the parameters. We assumed
that not many users shall be using this kind of feature, and those who will
be using it will be holding their hand somewhere near the panic button
anyway.

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

If we are designing a library rather than a specialised robot programming
language, even if we don't include this feature not much damage is done, as
the source code of the controller can be compiled once again (with a new
control law). Usually you don't switch control laws while the motion is
performed. MRROC++ has this possibility, but it was not used. Anyway if you
need such a feature you can have instead of a few control laws one but
complex.

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

This code is in the servo-loop anyway. The two approaches differ only by the
fact that you either need to recompile the code or not. If control law
switching feature is included you do not have to recompile the code to
switch algorithms - otherwise you have to do it. While experimenting with a
new control law you usually just change its parameters and not he control
law structure, so perhaps we should go half way - just let the user change
the parameters, and when he/she wants to change the control law let him
recompile the servo code.

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

You are completly right, but still you can have a swapable, but known,
simple control laws or a unswapable but complex control law composed of the
simple ones. The first approach seems simpler and more elegant, but need
provisions for continuity while switching.

> > 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 each 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 with the 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 :-)
>

As I understand, you want to use PNs to attain consistency in the parameters
of the switched control laws. I don't think that PNs are good at that. Here
we want the consistency of values and not consistencies of time instants
that something happens. I think a different kind of tool would be needed
here, but nothing comes to my mind.

> > 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
>
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos