Re: A working document

Herman Bruyninckx wrote :

| - The Executive ``controls and coordinates the execution of the
|   functions distributed in the components of the functional layer,
|   according to the task requirements'', and ``the decision layer [...]
|   supervises the execution of the task''.
|
|   At first sight, this seems to be twice the same thing...?

Yes, maybe the sentence is not very clear :)

A task is typically more complex than just a sequence of service
calls. For instance, a task could be 'goto x,y' where x,y is a
position. This task will involve many services of the functional layer:
path planning, motion generation, localization, etc. (these are just the
obvious ones). Supervising the execution of this task will require some
decision capabilities, to be able to react to any abnormal situation (a
failure in the functional level, or an external event such as someone in
front of the robot).

On the other hand, the Executive does not include those decision
capabilities: it connects the 'decision layer' to the 'functional
layer'. Despite the simple aspects, this still implies some mandatory
tasks such as those listed in the figure (consistency checks, data flow,
resources management ...).

The ambiguity in the sentence you quoted comes from the fact that some
tasks are sometimes quite simple, and can be written only as a sequence
of service calls. Whether to put those simple tasks in the 'Executive'
layer or in the 'Supervision' layer is not yet very clear to me.


| - I agree with your focus on ``the functional layer, since Orocos
|   focuses only on it as of today''.
|   But I think the ideas in your draft apply to the other levels also.
|   They do apply at least to what we've been doing in Leuven the last
|   months with the real-time motion control components :-)
|   And they apply to what we have in mind with our sensor processing
|   components too.

In my mind, components are located only within the functional layer.
(maybe one could define components for the decision layer also).
But the lowest layers look more 'classical'.

The component notion is really needed because the functional layer of a
robot is something new compared to a standard worksation. This layer
provides a set of perception and action capabilites to the machine
(something that a workstation does not need). We use the component model
to provide robustness: for a given functionality, we will need several
component that will perform roughly the same task, in different
situations.

The logical layer, for instance, is completely 'deterministic'. For
a given robot, the set of sensors and effectors is fixed and is not
likely to change. Whereas the fucntional layer must be able to react to
unpredictible changes in the environment in which the robot is put.
I think this makes a big diffence.


| - How do you think the designs of Leuven and LAAS will best meet, in
|   order to implement the ``logical sensors''? What support do you
|   expect/need from the real-time/kernel drivers and components?
|   Do you consider these logical sensors to live already on top of the
|   CORBA layer that Stockholm is preparing? (This layer could be
|   short-circuited, if things are running on the same CPU, of course.)

As of today, the logical layer is a set of high-level libraries that
control the devices. We have image acquisition library, which can control
several acquisition boards, an 'axis' library that implements basic
servoing for motors, etc.

The true 'abstraction' if done thanks to components (as defined in our
document). For instance, we would have a couple of components to
implement stereo-vision, and on the other side a single component that
would acquire an image from a 3d laser camera. Both would produce a 3d
image of the world.

Depending on the hardware on a particular robot, you would launch the
appropriate set of components, which can then be used transparently by
the decision layer.

Thus, I would have put a CORBA layer at the 'executive' level, rather
that in the logical layer. But I might be wrong, or misunderstand how do
you see the 'logical layer'. Do you have any document/paper that precises
your notion of that layer ?


| - In your Figure 1, I would add also `events/reports' between the
|   logical layer and the functional one.

Yes, reports and events might also be needed at that level. But (again)
we don't see the logical layer as an 'active' layer.
I think I really need to read either what you have defined already or
what Henrik is currently doing :)

|   (There is also a small typo: ``Consitency checks'' -> ``ConsiStency
|   checks''.)

Ooops :)


| - You have ``Consistency checks,'' ``Resource management,'' and
|   ``Data flow management'' in the ``Execution control layer'': in our
|   design, we consider these to be supporting functionality of the
|   functionality layer, and call it the layer's ``runtime''. (By lack of
|   a better name...)
|   Is this indeed what you mean also?

Yes, that's it :)

| I.e., in one layer, one has
|   functional components (those that really perform the interesting work)
|   and supporting components (that help the functional ones to achieve
|   their goals, and that hide the details of event/exception handling and
|   data flow/communication).

I think what you call 'supporting' components should rather go in our
'decision layer'. The details of event, data flow etc. is hidden thanks
to the 'executive' level.

|   (Our motivation to put these together is that they cannot live
|   without each other anyway...)

Well, you will end up with a single layer :) Everything is needed
to make the robot work!


|   If the above interpretation of mine corresponds to your
|   interpretation, then I miss a ``runtime'' feature which is
|   ``scheduling'' and (dynamic) re-configuration of the active functional
|   components. Or maybe that's include in what you call ``Resource
|   management''?

scheduling is hidden by the operating system. I don't think (at the
moment) there is a need to redefine some scheduling strategies?

About dynamic reconfiguration... do you mean 'dynamically changing the
set of running functionalities' ? If so, I don't think that it is
something you really want to achieve on a robot.

There is a need to develop interoperable components, but once you have a
given robot, and a given mission for it, the set of functionalities is
given. Of course, for almost every missions, there is a need of
'redundancy': several components implement the same functionality, with
different means. That's why there is a need of a 'dynamically
configurable' data flow and control flow. This is done by the decision
level.

'resource management' and 'consistency checks' ensures that the decision
level does not want to do things that it is not possible to do: trying to
move cameras while another task require that they remain fixed (that's a
consistency check) or trying to launch a service that requires, for
instance, more memory (or power, or cpu, ...) than what is currently
available (resource management).


|   I think you mean the same thing as what I mean, because, on page 3,
|   you write ``A consequence is that both the control ow and the data ow
|   must be defined outside the components. For instance, in the LAAS
|   architecture, this is done at the Executive level.''

I think that the 'runtime' feature you are missing is the control flow,
which is defined by the decision level. Besides this, I think we do agree
:)

|
| - I do not fully understand the sentence (page 3): ``The code
|   contained in the components thus becomes naturally independent of
|   the particular robot on which it will execute.''
|   The thing I don't quite understand is the ``thus''... It refers to
|   the previous sentences, which are cited in the previous paragraph of
|   this mail. How does the separation between execution and functional
|   layers make sure that your functional layer becomes independent of the
|   robot system?

Because we don't _allow_ both the data and the control flow to be done by
the 'codels' (which are the active part of components).
The component relies (at most) on the sensors interface (which should be
robot-independant). The component does not 'know' who will ask for its
services, nor to whom it will send its data, nor _how_ the service will
be requested, nor how the data it has produced will be used.
I think this makes it robot-independant ?


| - Codels. Reading the first paragraph of this section reminds me of
|   the ``Monitor'' software pattern: the events are ``serialized''
|   before they are given to the functional component, and hence each
|   codel should worry only about the event that caused this codel to
|   become active. In still other words: a codel is the actions done in
|   one single node of the FSM (or other synchronization tool).
|   Is this a correct understanding of the message you want to convey in
|   this section?
|   If so, I would prefer to use the Software Pattern names, because
|   that's what software patterns are good for :-)

I think a 'service' can be a software pattern (it's not clear to me what
a software pattern is :).
Services receive events (or requests) and perform action. Codels are only
a mean to structure an algorithm. Structuring is important for the
component's reactivity, but this is useful for the component only. Other
compoents do not see codels. They only see services.


| - A related question: are your codels the same thing as
|   ``transaction'', i.e., things that take place atomically, or not at
|   all? Probably not, because it is impossible to guarantee the four
|   classical ACID conditions for transactions, I guess?
|   A brief definition of ACID can be found on
|   <http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci213756,00.html>

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/transaction_management/properties/

The url does not seem to work, but I found the four properties anyway :)
I'm not sure if codels can be seen as a transaction but they should have
the four properties of ACID. It is impossible to garantee that in the
general case, but for a given component and its set of codel, I think it
is possible.
For now, I would say that a service _might_ be a transaction, and codels
would then be atomic operations of that transaction. It is not needed
that all codels of a service execute, but if one fails, the whole service
fails.


| - Page 4: ``codels should be totally independent of the communication
|   libraries.'' And also of the FSM, isn't it?

Well, the engine that executes the FSM will have to retrieve the
(external) data needed by the codels. So there will be some code that
will perform this. But this code should not be inside the codels.

| They encode the smallest
|   parts of functionality, and this does not depend on how their
|   sequencing and synchronization is being done. Or does it?

sequencing order is important, but besides this a codel should actually
not rely on anything :)


| - I don't quite understand ``Note that this is much stronger
|   than simply relying on standard libraries (and defining standard
|   functions for communication).''...

There are two ways of being independant of -- say --- communication (but
this is true for anything else). Either you write a standard interface,
and you rely on this interface which must stay the same, or you _don't_
put the code that do the communication into the codels.

In think this code should be part of the component's execution engine,
but should not appear in the codels.


|   Or ``codels should only interface libraries with the component's
|   structure.''

That's almost the same as above :)

|   Or ``a prototype is naturally defined, and all data
|   can be directly passed to the function.''

A prototype is defined because in the component description, the data
that codels need is also described. If a codel want 'a and b', il will be
called with 'a and b' as arguments, and then it does not have to fetch
the data itself. The codel works on 'a and b' and that's it :)


| - Stop the execution of a service: you mention three situations, but
|   isn't there a fourth one: the codel itself raises an ``exception''
|   that requires immediate servicing (by the runtime/executive).

Codel can stop itself, that's true.
But it should _not_ require something new (like a service
execution). This task goes into the decision level, which is the only
level that has a 'global view' of the robot and the tasks it is
performing.


| - The ``inter'' codel is what we call an exeption handler, I guess. It
|   would be nice to reach a common terminology... In our design, we
|   have an ``exception handler component'' at each layer, whose
|   responsibility it is to bring the whole layer in a consistent state
|   again.

True. 'inter' is an exception. But exception is more general.
Have you got other exceptions than 'interruption' ?


|   When writing down these sentences, I realise that what you call a
|   ``layer'' we call a ``framework component''. Both names are not
|   sufficiently expressive, I think... We need a better (i.e., more
|   specific) name. What it is is a set of components that are connected
|   together in one particular architecture, and, in this form and
|   together, make up a new component. Calling this a layer is too
|   suggestive for a hierarchical architecture.

I don't think that components connected together form a new component (?)
Besides this, I agree on that the functional layer is a set of
components. It is less true for the 'decision level' (at least, we do not
have defined components in this layer).


| - Page 5: I do not quite understand the exact difference between a
|   ``description language'' and a ``programming language''. (At least
|   not in this codel context; I do understand the difference between,
|   say, an XML file and a Pascal program :-)

I think you've got it :)
The interface description language only tells other components 'what'
a component does, and the codels implement the 'how'.
For instance, there is no control structures in the description file.

|   Or do you mean that the language described the data structure
|   (``object'') that is exchanged through the interface of the component?

Actually the language does not that (it relies on the '#include' keyword
for the structure definition).

|   This is the way we describe it in our motion control framework. That
|   is, all communication between component takes place through
|   ``objects''.
|   I place ``objects'' between parentheses, because it are objecs
|   without any ``methods'': just data structures. And hence, fully
|   specifiable by a description language such as XML. As shown by your
|   figure on page 5.

Yes I think it a good idea to use structures (objects without methods) in
this context: it's up to the components to implements the actual
methods.


| Enough comments for now: I go to bed :-)
| More will follow later one, but also now already I get a warm feeling,
| because I think we are designing along very compatible ways; this
| should lead to the synergies in implementation and code maturity that
| we've been hoping to reach in this project.

I hope so!

And I also hope you will find information in my answers. It was sometimes
not easy to answer precisely your questions, because it's difficult to
imagine how you actually understand our framework. I think we agree on
much points, but I also guess that there are some points for which it is
less clear.
Again, if you have papers that explain some of the work you've already
done, please tell me :) (even if it's not finished or incomplete).