RE: API discussion...

On Fri, 19 Mar 2004, Cezary Zielinski wrote:

> My comments follow Herman's.
[...]
I have the impression that we are thinking very much along the same
lines, only using somewhat different terminology. The discussion we
had very quickly went into talking about _how_ to implement the API,
so even though this is interesting, it is a "detail" which is not
important for the API. (Unless the semantics of the different
implementations (yours and ours) are too different, but I think they
are not...)

So, what do other people think about the (very) small motion interfaces
that we suggest?

[...]
> ----> The motion generator is a function that the user provides, thus
> anything can be coded. In the majority of cases the following suffices. The
> generator generates consecutive geometrical trajectory points one at a time
> (e.g. like a linear interpolator). Thus it knows the endpoint not from the
> terminal condition, but from the geometrical description. The termination
> function delivers extra information from sensors for a premature stop. In
> rarer cases the end-point might not be known. 

I give these "rarer cases" and explicit name: "Move". While the case
you describe above is our "MoveTo" semantics.

> The sensors deliver the
> information for the generation of the next trajectory point. The termination
> function might tke into account both the information obtained from sensors
> and the current end-effector position (this is available from the list of
> effectors).
On the Orocos design, this is the job of the "estimator" which raises
the termination event(s).

[...]
> > Both Move and Wait instructions must know what are the sources of
> > information (eteroceptors and interoceptors)
> Can you define these concepts, please?
> 
> Exteroceptors are in my newspeak receptors (sensors) delivering information
> from outside the robot, i.e. the environment, e.g. cameras. Ineroceptors are
> the sensors that provide the information about the internal state of the
> robot, e.g. encoders providing information about the position of the motor
> shafts, and thus the links and consequently the end-effector. I got the
> names from biology, so I hope that they are all right for our community.
> 
They are! (They have been used before in mobile robotics literature,
if I am not mistaken. At least, I have used them in my robotics course
notes some years ago :-)

[...]
> ----> I agree that there are many possible interfaces and OROCOS might
> benefit from the multitude, however such a multitude might be frustrating
> for newcomers to the field. 
Yes, and that's the reason why we are working towards "applications":
each application has its own small and easy-to-grasp interface, but
implements it on top of the "big-and-frustatingly-rich" code base that
Orocos (will) have. It's the Application Builders' job to find their
way in the "chaos", not their application users' job :-)

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480