components list/Control SP interaction

On the Components page, is the use of the word "component" there equal 
to the use of the word "component" in vision.html as it describes the 
rectangles in the Control SP? Maybe that's where part of my confusion is 
stemming from.

What is the relationship between the list of Robotics libraries on the 
Vision page and the list of components on the Components page? These 
lists are different, but have some overlap.

>>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"!

By this, you mean that you could have a complete instantiation of the 
Control SP that handles RT processing and works directly with the 
hardware, another complete instantiation one level of abstraction higher 
that uses the first layer and does the local planning and task 
execution, and on top of both of those, a third complete instantiation 
that does global planning, error recovery, and possibly incorporates AI?

Thus:

UI Level: graphical and non-graphical user interfaces, geometric modelling

Top Level: motion, force, and interaction control applications, map 
building and object localization

Mid-Level: task specification and task sequencing, processing of sensor 
data, trajectory generation, kinematics and dynamics

Lowest-Level: Servo control algorithms, device drivers for robotic hardware

Motion control applications are at all levels, it just depends on the 
level of abstraction assumed in the internals of a given application 
which level in the hierarchy it belongs? Communication and 
synchronization at all levels? Task specification and task sequencing at 
the top level _and_ the mid-level? Processing of sensor data at 
mid-level _and_ lowest level? Can we have "really high-level sensors," 
like aggregate or virtual sensors, which could be processed at the top 
level? Geometric modelling at UI level _and_ top level?

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

So is determining the patterns for combined used of these three levels 
of complete instantiations outside the immediate scope of Orocos? In 
other words, if we've got three levels of the Control SP layered in a 
hierarchy, how does communication between and usage of lower-level 
components between the layers work? Is it a direct connection (top-level 
Controller-rectangle only talks to second-level Controller-rectangle, 
e.g.), or is it more complex and flexible than that?

I'm trying to figure out how to superclass and subclass things, and 
even, really, what the hierarchy of the classes should be based on. 
Which characteristic of the software components should be the dimension? 
The component's role in the Control SP (or, more simply, the component's 
role in the Sensing-Planning-Control model given in patterns.html)? The 
component's function (e.g. kinematics, servo control, communication)? A 
cross-product of the two? Something else entirely?

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

So there is some notion that if we have an application at the mid-level 
of the three-level hierarchy which has a Generator that uses kinematics 
to generate setpoints, if we "zoom into" that Generator rectangle, we'll 
see at least one complete instantiation of the Control SP in the 
kinematics support inside of it? If only the Generator and the Estimator 
are really relevant to this kinematics-and-dynamics functionality, then 
we're getting a hint that a very-high-level robotics control application 
would be built out of the types of functionality given in the list of 
components on the Components page, and the functions *would* fit into a 
specific subset of the rectangles in the Control SP?

And thus, would a chunk of code that implements a kinematics and 
dynamics control application be said to be multiply-inheriting from 
types Generator and Estimator, even while that chunk would probably have 
within it its own Generator(s) and Estimator(s)?

ooh, this is giving me a headache. :)

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

I think I was trying to say:

Could we imagine constructing a robotics control application that uses 
all of the pieces in the list of components on the Components page? 
(These are what I'd been referring to as "functionalities" or 
"functions" above.)  In that big picture, do the functionalities fit 
naturally into certain places in this very-high-level instantiation of 
the Control SP?

Or is Orocos only interested in implementing each of the functionalities 
at their own level?

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

This is another dimension along which a class hierarchy could be defined...

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

So I imagine a "task hierarchy" would be a list along the lines of:

MoveJoint
MoveMultipleJointsInAFinger
MoveMultipleFingersInSomeMeaningfulPattern
UseMoveMultipleFingersInThatMeaningfulPatternToDoSomeStillHigherLevelTask

etc., where each "task" in that list would assume a certain interface of 
the lower-level things that it uses to achieve its end. (See the 
"grasping" example below, where "grasp" would be a "meaningful pattern 
of movement" with an interface that has a postcondition that means that 
an object of interest is within the grasp of a robot.) Thus, any 
physical configuration of actuators that could "grasp" something (i.e. 
provide the grasp interface) would be able to be plugged in under a 
higher-level task that requires that an object be grasped in order to 
achieve itself.

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

But why couldn't they be a kind of component in and of themselves? (I 
realize that by this point, we're probably overloading "component" with 
_three_ different definitions: Control SP rectangle, functionality, and 
action concept.) If we limit ourselves to just adding more methods 
whenever we want to do something more complex, we'll end up trying to do 
something like defining a Ball object and then adding a new method for 
each of the infinite variations of things one could do *with* a ball. 
Why not call "MoveJoint" a task ("action concept"?) in its own 
independent right, and any piece of hardware that can achieve this task 
can be plugged in underneath it, thus giving you the flexibility of 
doing higher-level things with it and not having to worry about which 
joint-actuator is being asked to do it?

Doing high-level task planning based on a set of available lower-level 
tasks...

Just out of curiousity, what would you imagine would be the particular 
task API that would be able to handle those three examples? Maybe my 
mental notion of "task" is just completely out of synch with yours.

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

It may just be another way of thinking about what the software 
components do and how they could fit together...

Rachel