original message

I'm trying to more clearly grasp how the components described in

http://www.orocos.org/documentation/components.html

fit into the Control SP described in

http://www.orocos.org/vision.html

Below is the list from the Components page, and my attempts at 
classifying what sort of component they might be in the Control SP. I 
realize that the internal design of each of these types of components 
would probably fit their own appropriate SP, but I'm interested in where 
they may or may not fit into the Control SP framework, and perhaps push 
at some definitions.

"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, because you seem to be referring to the 
larger framework. On the 'Motion control applications' page 
(motioncontrol.html), the "controler" (sic) is defined to be an 
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? Is it a particular Application? Is an Application thus a 
high-level kind of Controller? Is this a hierarchical definition where 
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?

Part of my questions about the completeness of the Control SP (and a 
large part of my attempt to understand how to practically instantiate 
it) is in understanding how each of the types of components in this list 
fits into the types of components given in the Control SP. There are 
obviously different levels of abstraction in this list. My attempts to 
classify the list in terms of the Control SP are in parentheses:

     * Motion, force and interaction control (are these 
Generator/Observer/Controllers? Or just one of these types?)
     * Kinematics and dynamics 
(Scanner/Actuator/Generator/Observer/Controllers?)
     * Sensor and actuator device drivers (Scanners/Actuators)
     * Sensor processing (Scanners/Observer/Generators)
     * Trajectory generation and interpolation 
(Generator/Controller/Observers?)
     * Component communication ("Mediator"?)
     * Task planning (Generator/Controller?)
     * Task specification and execution
     * Graphical and non-graphical User Interfaces (Command 
Interpreter/Reporter)
     * Map building and object localization (Generator/Observer? 
Something else entirely?)
     * Geometric modelling (Generator/Observer? Something else?)

My question basically comes down to: are there more/less points of 
flexibility in the Control SP? 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? Likewise, where 
the Control SP components are appearing in more than one place in the 
list above, should the rectangles be split into multiple parts that are 
specific to robotics control?

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? Draw a diagram with those things in the list 
above as the rectangles (and Component Communication rectanges between 
all of the other rectangles? The communication between each type of 
component could be unique, configurable, different...) How well does 
this new diagram match up with the generic Control SP, or is it just a 
completely different perspective on a working robotics system?

--------------------------------------
On another train of thought, has there been any work in defining a task 
hierarchy? 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? Just making 
a stab at flexibility issues, it seems to me that it would make sense to 
define "task components" (e.g. "MoveJoint," "MoveMultiJointFinger," 
"Grasp") and make them such that they:

- provide services to higher-level task components
- assume that they have access to either some lower-level task component 
or a hardware controller (perhaps the "lowest-level task 
component"--direct wrapper around hardware?) that provides the interface 
needed to achieve the current task

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'm an SE grad student working on helping our 
department's Robotics group adopt SE principles, so I'm trying to find 
out what might work in this domain.

Thanks,

Rachel

--------------------------------------
A couple of side notes:

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"