Re: A working document

On Sat, 15 Dec 2001, Anthony Mallet wrote:

[...]
> 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'.

I think I understand your vision and definitions now. And I don't
disagree with them. So, I think the final discussions will be based on
the implementations :-)

[...logical layer...]
>Do you have any document/paper that precises your notion of that layer ?
Not yet...

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

Well, I think there _are_ active components possible in the logical
layer: you might want to work with a logical sensor that gives you the
position of an object you are interested in, but tracking this object
or collecting missing information can be an active activity, i.e., one
that requires its own decision making and planning. Of course, the
scope of these is much more restricted and deterministic
(``real-time'') than on the layers you are working on.
One thing I think I learned is that the same kind of
sensing-planning-control pattern comes back at all levels of robot
software. Only the kind of algorithms, the time-scale, the complexity
are of a different scale.


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

What I think is that at _every_ level one needs decision making as
well as execution support. They form an unity with the real functional
parts.


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

No, I don't think so: we don't talk too much in terms of layers,
because we don't want to impose a strict hierarchy. We do think in
terms of cooperating components (the application builder will connect
these components together in an architecture that suits him best), and
each of these components has ``everything''. That's what makes it into
a component: in order to be a component, it has to be independent, and
in order to be independent, it has to have decision and support
capabilities. But all this is just a matter of wording and
terminology: I think our code would look very similar, and that's what
really matters :-)

> |   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?
There is! Some examples: the component that takes care of the
simulatiuon of the dynamics of a complex robot will have to have its
own scheduler in order to schedule all the required calculations in
the appropriate order; an active stereo camera system will have to
have its own scheduler in order to get all the information it can get
about a certain feature (finding this information could involve
changing the viewpoint, or interacting with another, complementary
sensor).  Of course, one could look at these examples as robotics
tasks in themselves, and then, indeed, everything is built on top of
the OS :-)

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

I think one will want to do this. But don't imagine too fancy things
here; one example would be that you add a sensor to a robot, without
bringing the robot off-line; or a robot is put into a workcell or
fleet of other robots. These things will involve changing
functionality, if one want the group of robots to perform better than
the set of individual robots.

I don't think, however, that this is a ``Version 1.0'' requirement :-)

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

This _is_ a ``Version 1.0'' requirement :-)

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

Indeed!

> |   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 'runtimé feature you are missing is the control flow,
> which is defined by the decision level. Besides this, I think we do agree
> :)
So we agree :-) Although we use different words.

[...]
> 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 ?

Okay, I'm fully with you now.

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

I'm not so sure: the difference with typical transactions (in
databases) is that in robotics the program doesn't have full control
over all what is happening, because the environment cannot be fully
controlled; hence, the ``rollback'' property of a transaction cannot
be guaranteed, in general, I think.

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

Ok. And then the ``executive'' of the service gets to handle the
problem?

[... communication with ``external'' components...]
> In think this code should be part of the component's execution engine,
> but should not appear in the codels.

Ok.

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

Voila, once again a proof that we think along the same lines :-) We
also have this functionality in our ``runtime'': our event handler is
the only one with the global view; all others just do their thing,
through well-defined interfaces. So, the `decision level/vent handler'
is application/task-dependent (and couples the different components),
all the rest isn't.

>
> | - The ``inter'' codel is what we call an exeption handler, I guess. It
[...]
> True. 'inter' is an exception. But exception is more general.
> Have you got other exceptions than 'interruption' ?

This is probably purely a matter of terminology...
execption/event/interrupt, what's in a name?

[...]
> I don't think that components connected together form a new component (?)

They do, _if_ well designed :-) In the following sense: a component
has a well-defined interface, so a group of components together, with
a well-defined interface, are again a component. So, if Orocos could
deliver this kind of components, it will be a success :-) And, for
example, your logical sensors are examples of what I say above: you
use them as components, because you expect them to have an interface
that allows you to forget how they work internally, even if this
internal working requires a lot of other components.

[...]
> And I also hope you will find information in my answers.
yes!!

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

Expect one this week...!

Herman