RE: 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...?

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

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

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

> Both Move and Wait instructions must know what are the sources of
> information (eteroceptors and interoceptors)
Can you define these concepts, please?

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

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

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

Herman


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