Re: answers cntd.

> > The sensor input implements high level feedback - not the servo
> > level one. Usually those generators generate trajectories, which can
> > be modified by sensor readings. To be strict they generate the next
> > target position. As our servo sampling rate is either 1 or 2 ms the
> > generator usually performs at the rate of 6 or 8 ms (for the 2 ms
> > sampling rate), so its influence on the trajectory is fairly rapid.
> >
> This is an interesting remark, because I think the way you present it
> (which is the `classical' way) doesn't cope well with things like
> `adaptive control': the controller changes its parameters based on
> feedback through the sensors; and also the next target position can
> depend on _instantaneous_ sensor feedback, not on a change in setpoint
> that comes 5 sample periods later...

I personally distinguish internal and external sensors. Internal sensors are
those that supply information on the current state of the ar or whatever
(e.g. position encoders), external ones are the ones that gater data from
the environment of the robot. In MRROC you can try to do adaptive control on
both levels - either supplying another servo control algorithm or a new set
of parameters for it, or on high level using eternal sensors to modify
either the set points or the regulator parameters (e.g. using a force sensor
to detect the weight of the carried object so that the regulator adapts to
this new circumstance). Of course there must be a delay, but that can be
taken into account in mathematical expression of the algorithm.

>
> Probably we are again saying the same things but using underdefined
> terminology :-) I mean: if you need this instantaneous feedback, it
> has to be part of the servo controller, isn't this what you mean?

Yes. Usually you want everything to be as fast as possible.

>
> IF it is, this brings me to another related question/problem, i.e.,
> that of the functionality of the trajectory generator: if one uses
> sensor feedback to let the servo adapt setpoints, _and_ also in the
> generator, how can one make sure that both are not fighting each
> other? As far as I see now, this can only be done if the generator
> also has to ability to adapt to the sensor results. But then whose
> responsibility is it to keep both in sync? These are (some of) the
> kinds of problems we are now trying to find a satisfying software
> engineering answer to in Leuven...

I am not sure that I understand the problem fully. What I think you are
saying that the same set of sensor readings is used both for servo control
and trajectory generation and thus there might be oposing reaction of both
levels. If my understanding of the problem is correct, then my answer is
that you are probobly right - there will be a conflict. Nevertheless I am
not proposing such a thing. My intension was that each level uses its own
set of sensors which will provide readings that will not produce conflicting
modifications. But you are completly right that this problem requires
investigation - especially of stability of each such solution.

Cezary

>
> Herman
>
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos