RE: API discussion...

My comments follow Herman's.
Cezary 


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Herman
Bruyninckx
Sent: Thursday, March 18, 2004 10:04 PM
To: unlisted-recipients:; no To-header on input
Cc: 'Open RObot COntrol Software'
Subject: RE: [Orocos] API discussion...

On Wed, 17 Mar 2004, Cezary Zielinski wrote:

> It is sufficient to have only two motion instructions: 
> Wait - waiting for an initial condition to be satisfied (a condition that
> enables the motion to start),

Is this "busy waiting"? In the sense that the motion control is
already active, but the setpoint is "zero motion"? If not, than this
does not belong in the motion API, but in the startup/shutdown procedure.
("execution flow", "PLC" activities, whatever you want to call it)
If it is, it is a normal Move, but with a "zero motion" setpoint. Or
maybe you mean something else...?

----> This is simply waiting for a certain condition to be fulfilled. During
that time the servos obtain a 0 increment, so the robot is static. The
condition can be tested at the sampling rate or a low multiple of that. You
can call it busy waiting, but it does not have to be implemented that way.

> Move - executing the motion according to a certain pattern (provided by a
> motion generator) simultaneously monitoring the terminal condition.

How would you provide the desired end position as a "terminal
condition"? I see some problem here, because the generator must get
somehting to satrt producing interpolated setpoints, and I don't
immediately see how this is done semantically with a termination
condition. Maybe some examples could help.

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

> Thus the programmer needs to provide for the Wait instruction a function
> describing the specific initial condition and for the Move instruction two
> functions - one, describing the specific termination condition and the
> second is a function generating the next motion step 
But this function also needs setpoints, doesn't it? 

----> Yes, the motion generator produces them. As the user delivers that
generator the program executes exactly what he/she wants, i.e. task at hand.

> Those functions form three hot spots.
Yes, we call it the "plug-in functionality" of the Generator, and the
other components. (So, we have a maximum of more than three "hot
spots".)

----> Exactly.

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

> two lists have to be provided. One is the list of effectors (robots) and
the
> other is the list of virtual sensors (aggregated data from real hardware
> sensors). As this are lists it is not important how many robots are
> controlled simultaneously and it is not important how many sensors we use.
I think it _is_ important for the functionality plugged in in the
Generator and the other components, isn't it? Probably I misunderstand
what you mean, but this short description of yours creates an image of
"the ultimately flexible" Generator :-)

----> This was my intension. Actually the list of effectors and the list of
virtual sensors are the lists of certain images (models) of those artefacts.
Each such artefact contains the current state of the effector or the current
reading from the sensor. Moreover the generator introduces into them either
the new (computed) setpoint or a demand for a new sensor reading (in the
simplest case) or a sensor reconfiguration command (in a more complex case)

> For the general semantics of those instructions the type of robots and
> sensors is also irrelevant. 
I agree.

> Obviously the three functions (initial
> condition, terminal condition and setpoint generator) will differ both
with
> number and type of sensors and effectors - well, but this are the hot
spots.
> If you are interested in the flow charts of those instructions you can
find
> a more detailed discussion in:
> http://www.ia.pw.edu.pl/~zielinsk/ROMOCO99.pdf
> I can also provide the C++ code for them.
A short stand-alone example on the mailinglist would do :-)

----> Please see the attached paper, namely section 7. of it. If this will
not suffice I'll provide the full code of whatever part you need.

What I get from your posting is that you say with me that a very small
interface is all we need (for the motion specification at least), but
that we have currently a little different semantics?
(Anyway, the Orocos infrastructure has no problems with more than one
"non-realtime user API" on top of the same C++ realtime code.)

----> 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. 
----> I do not fully understand the remark about the real time. The Wait and
Move are used for real time control of MRROC++ based robot controllers. 

Herman
Cezary

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

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