copying a discussion to the mailing list...

On Wed, 8 Oct 2003, Rachel Smith wrote:

First remark: please use the Orocos mailinglist! So, other people could
profit from this discussion too.

[...]

 >> "controller": It is said (vision.html), "A second advantage is that the
 >> Pattern gives the opportunity to introduce structure into every
 >> implementation of a controller, as well as well-defined terminology for
 >> each of the parts in the controller software." By "controller" in this
 >> sentence, I take it that you do not mean just the "Controller" 
rectangle
 >> in the Control SP diagram,

No... This is the continuous linguistic problem in control theory:
some people use "controller" for the whole thing, some only for the
component in which control algorithms run. I have not done my utmost
best to consistently separate both usages of the word "control"... :-(


 >> algorithm that accepts inputs and produces actuator signals, which
 >> matches the "Controller" rectangle in the Control SP diagram. What,
 >> then, is the "controller" referred in that "second advantage" sentence,
 >> above?

It's the combination of all components, as illustrated in the figure
in the vision.html page.


 >> it is assumed that if one "zoomed into" the Controller rectangle in the
 >> Control SP, we would find another complete instance of the Control SP?

Controllers can be combined in various architectures, the hierarchical
one being the most common. This is _different_ from "zooming in"!

[...]

 >>      * Motion, force and interaction control (are these
 >> Generator/Observer/Controllers? Or just one of these types?)

These are _complete instantiations_ of the control pattern. The
difference is in teh _functional contents_ of the components, but not
in the structure (pattern); that's the same for all of them.


 >>      * Kinematics and dynamics
 >> (Scanner/Actuator/Generator/Observer/Controllers?)

These are algorithms that can be used in all components (well,
basically only in the Generator and the Estimator).

[...]

 >> My question basically comes down to: are there more/less points of
 >> flexibility in the Control SP?

I don't understand this question...


 >> Where grouping of the Control SP
 >> components are occurring above, does it make sense to break the
 >> activities into separate Control SP components, or should there be a
 >> rectangle that combines the parts into one component?


You can combine components in a larger one, but even then it makes
sense to keep the full structure: otherwise one compromises later
scalability or distribution over a network.


 >> Likewise, where
 >> the Control SP components are appearing in more than one place in the

It's _functionality_ that appears in multiple components, not SP
components.


 >> Has anyone tried building a specifically Robotics Control SP out of the
 >> set of the things in the component list above, instead of just using
 >> generic control notions?

Maybe I misunderstand your question, but the Orocos is all about
building the instantioation of the SP in the framework of robot and
machine tool control.


 >> On another train of thought, has there been any work in defining a task
 >> hierarchy?

Not yet. But it is certainly something we are very interested in.


 >> The Orocos component list given above is already somewhat
 >> heading in this direction. "Task planning" and "task specification and
 >> execution" are mentioned as components, but these are support for
 >> describing and executing a task--not for investigating what are the
 >> common tasks that roboticists use and build upon, are they?


I don't quite understand what you mean :-(


 >> a stab at flexibility issues, it seems to me that it would make 
sense to
 >> define "task components" (e.g. "MoveJoint," "MoveMultiJointFinger,"
 >> "Grasp")

These actions are not "components", but just method calls of a
_particular_ task API.


 >> Thus, any lower-level component that provides the necessary interface
 >> for "Grasping," for example, could be "Grasp"-ed by this Grasp task
 >> component. Defining what constitutes "the necessary interface for
 >> grasping" is its own question, but is this approach heading in a
 >> promising direction?


I don't know... Not much work is going on at this moment, AFAIK.


 >>
 >> Components page: "The project is in the phase of defining which
 >> components it needs, and how their interfaces look like." (note: "what
 >> their interfaces look like" might be better)
 >>
 >> Glossary: "Component" definition: "acces" -> "access"
 >>

Thanks for the feedback!

Herman

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