Re: A working document

On Sun, 16 Dec 2001, Anthony Mallet wrote:

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

Maybe :-) Anyway, it's high time to get to an agreement about
terminology. So, you could try to define terms you need, compare them
to the ones that are already on the webpage (and which aren't
perfect!), and come to a ``final'' version. I am open to motivated
discussions about terminology :-)

[...]
> The logical layer provides low-level functions to
> acquire an image or move a pan-tilt unit (much like a driver)

If it is a device driver (and I think it is), let's call it a device
driver. Whether or not it contains active components is not very
important, only its interface. And device drivers should have quite
straightforward interfaces.

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

Indeed. Because it really _is_ a Software Pattern, i.e., a recurrent
solution to a common problem, having multiple working implementations
already. So, I might express the essence of Orocos as follows:
``Develop as many perception-decision-action (PDA) components as possible in
the context of advanced robotics.''
This could be a good approach to explain and document the code:
starting from this PDA pattern, the implementations and the ``user
manuals'' of Orocos could become much simpler to understand.

> | 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 is a good insight! (It's obvious once you write it down, but that
is what all good insights have in common :-)
I now realize that the distinction we are making in the real-time
motion control components between synchronous and asynchronous
components has the same motivation: the synchronous components need
only local data, and hence can be made hard real-time; the
asynchronous one need global data and hence are at best soft
real-time.
So, we should be able to find a terminology that catches this insight
in a very intuitive term. I don't like too much our
synchronous/asynchronous or your functional/decision terminology,
because, as proven by our discussions, the convey different meanings
to different people. What about centralized/decentralized?
Local/global? Centralized/distributed? Coupled/decoupled? ...

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

For example, IPC components, or FSM components? These just give one
particular type of support to other components, while remaining
application-independent.

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

This makes sense. I suggest we finalize our draft design documents
(we need to anyway, as project deliverable), and then see how the real
implementation ideas differ (or not).

[...]
> If you do not impose a hierarchy, you do have a single layer :)

I don't think so: it's up to the application builder to use the
components to build an architecture that suites his application best.

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

Of course. I didn't want to suggest that one needs only independent
components; just that we should try to make all components we build as
independent as possible.

> 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

I agree.

[...]
> And do you think the notion of 'codel' is ok to implement what do you
> have in mind?
>

I think it _is_ a good idea: the codels are basic building blocks. I
just need to see more examples of them, in order to make my mind up
more definitely. I will look at our motion control design with the
codel idea in mind, and see what it gives. I could probably already
give a couple of examples myself (please tell me if they correspond to
your idea of a codel):
- a PID control algorithm: read setpoint and sensor data, calculate
  actuator output, write output.
- the computed torque algorithm for a given robot.
- the nonholonomic motion planning for a mobile robot. (At least in a
  short horizon.)
- the event handling to bring a robot to a safe stop.
- one iteration of a Kalman Filter.

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

Agreed about the second one; but the first one _can_ provide
functionality, because the new sensor could use the information
already gathered by the other sensors, which would be lost if the
robot would be rebooted. (Note that ``adding a sensor'' could also
mean that an already available but unused sensor will be activated
when needed.)

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

Don't tell that to the behaviour-based roboticst :-) But I think you
are right: one has to make the decision that the context in which the
robot is performing has changed by the event of having a second robot
with which to cooperate.

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

I think it could (should?) do more: some errors cannot be reliably
solved by the procedure that invoked the service, because the error
affects the working of the whole robot; so that procedure should do
what it can to handle the problem, _and_ raise an exception to warn
all other components that want/need to react to the event.

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

Fine, I wait for a more final document of yours on this topic :-)

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

Why do you think this is systematically the case? Any examples in
mind?

Herman