Re: A working document

Herman Bruyninckx wrote :

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

Just one thing: I feel like I use the word 'component' for something much
more precise than you (i.e. components are what the functional layer is
made of). Maybe I should reuse the term 'module' instead?


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

In my opinion, these would _typically_ be 'modules' (i.e. component of
the functional layer). The logical layer provides low-level functions to
acquire an image or move a pan-tilt unit (much like a driver) and the
functional layer provides the encapsulation of the high level task you
mention. 


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

Yes. We also use the 'perception-decision-action' pattern.


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

Yes, you are right. But I would make a distinction between the three
layers (and that's the reason why we distinguish between those layers):
the decision procedure that appear within modules (components of the
fucntional layer) is _local_ to the module, and does not imply other
components (context independ wrt. the whole robot). Whereas the decisions
procedures that occur at the decision level take the whole robot into
account.

This makes the functional layer completely modular, wheras the components
of the decision layer are less portable. Of course, you will be able to
exhibit reusable components in the decision layer also (and in my mind
there is a need for such components --- something that does not appear in
the working document).

Actually, I think the only difference between your views and mine is that
you want to spread our three layers into each component, while we want to
spread our components into the three layers. I don't know if it's only a
'presentation' artifact or if this makes real differences :)
(I would say that it can impact the implementation)


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

Yes! If you do not impose a hierarchy, you do have a single layer :)

I really think that you can't simply connect independant components
together, and hope they work: you need at least one component on top of
all the above that will have the 'knowledge' of the whole robot and the
other components.

But that's an endless discussion. I think there isn't a 'right' way to
put things together. That's why I "focused on the functional layer",
because obtaining a good spec for that one (i.e. something that let
implement different architectures) is really what is important for orocos
(at least today).
:)


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

Ok, I had a more OS-oriented view of 'scheduling' :)
And do you think the notion of 'codel' is ok to implement what do you
have in mind?


| > 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 think the second example is really different from the first :)
The first one if much like a 'technical' problem (which is useful but
does not provide functionality), whereas the second is
more challenging (and provides a new functionality).

A question on which I would like to work is "how to make two robots
cooperate without telling them to do so" (because, for instance, they did
not know they would meet). How to make them use the functionalities of
each other? This task goes into the decision layer ;) 


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

Maybe 1.0a ? ;)


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

I would say: the procedure that invoked the service handles the problem.
The executive should only be a more or less 'transparent' component that
connects two things together.


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

Yup!


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

Well I see 'interrupt' as a particular event/exception.
Maybe we should consider this for the description language. It sounds
like an interresting idea.
I already see at least another event: 'suspend'.


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

I understand your vision. I really don't know which approach is best
suited to robots. On one hand, I have the felling that building
meta-components can be very powerful. On the other hand, I am affraid
of things that perform hidden tasks (which is systematically the case
with such meta components).

For instance: is it always possible to prove that a system with
meta-component will work in _every_ situation? I think it is much more
difficult than for a 'flat' approach.
On the other hand: will we always be able to build machines with hundreds
of components with a 'flat' approach?


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

Great!