Re: About component architectures...

Herman Bruyninckx wrote:

> On Thu, 25 Apr 2002, Christian Schlegel wrote:
>
> [...]
> Thanks for the feedback on my terminology struggles!:-) I add a new
> round of feedback from my side, inviting even newer rebuttals or
> additions from your side.

Hi Herman,

yes, terminology is a hard business ! However, the problem in robotics
often is that there are many terms used in different communities which
all contribute to robotics. Unfortunately, the exact definition depends
on the community. This is in particular true for the coordination
mechanism where approaches vary from finite state automatons to
artificial intelligence systems. Of course, unique terms are important
but I would like to keep those terms which are already in use. We then
should add a "namespace" indicating what we are talking about. One
example is the sequencing mechanism, which is used with three-layer
architectures. Sequencing describes the glue between a symbolic planner
and the basic skills of a system.

>
> > sequencing mechanism: This is the component, which is responsible
> > for restricted resources and which enables / configures only those
> > configurations which can work in parallel without needing to much
> > processing power, without using resources in conflicting modes etc.
> > It can be implemented as a task net interpreter, as a hierarchical
> > finite state automaton etc.
>
> Your phrasing ``sequencing mechanism: this is the component...'' is a
> bit unfortunate: I think there is a distinction to be made between a
> `mechanism' and a `component'. A component is an interface, and
> mechanisms are used to implement this interface, but both things are
> not the same.

Yes, I try to avoid mixing up "component" and "mechanism"

>
> I agree about ``can be implemented as a task net interpreter, as a
> hierarchical finite state automaton etc'' but I don't see the
> relevance of mentioning ``restricted resources,'' ``can work in
> parallel without needing to much processing power''. These features
> are not fundamental for a sequencing mechanism.

One important point to consider is that a framework not necessarily has
to be tightly coupled to an architecture. A framework of course has to
support the implementation of architectures and various architectures
allow to identify basic demands on the framework. A framework also has to
guide the developer of a component in such a way that the framework makes
sure that a component fits into the overall system. I always prefer
frameworks which avoid making too many restrictions on my internal
component structure since often new ideas do not fit exactly in
predefined structures and architectures.

Of course, since many robotic applications have been built over the
years, there is a tremendous amount of experience which should be
preserved in a framework to make building the next applications much
easier and finally avoid every group implementing a sick laser range
finder server. Since there have to be some architectural guidelines to
make sure that the framework at least allows to plug together several
distributed components to form a working robot, architectures require the
components to have several basic capabilities.

One approach which has been very successful so far has been to put at
least every inter component communication into standard patterns. This
makes it easy to plug in or replace components in an existing system
since the semantic of the interface is absolutely clear. Another
important point is that every component has at least some states with a
very clear semantic. One such state e.g. is the "neutral" state where the
activites within a component are deactivated to the level that it does
not request data from other components and that it answers requests with
a status code pointing out that it is in the neutral state now. Those
states are completely independent of the implementation and of the model
used in a component. The architecture of a component therefore has to
provide at least some basic configuration facilities which make sure that
the component can be integrated with low effort into every overall system
architecture. Often different parts of a complex system are based on
different architectures (e.g.  often the manipulator on a mobile
plattform is based on a different architecture than the mobile platform
itself). As long as all are built with components which can communicate
with each other it is simply the responsibility and chance of the
compenent developer or application builder to form the best suited
overall architecture, to distribute components suitably over computers
with enough processing power, which are connected by fast enough network
technology where necessary etc. etc.



Why did I mention restricted resources ?

Restricted resources are the motivation for many features of an
architecture and since a robotic platform is a system with restricted
resources, many difficulties of architectures are directly related to
restricted resources. At some level there has to be an approach which
decides what to do next. In very simple robotic systems this might be
hard-coded (the robot can do only one thing and therefore there are no
conflicts). Of course, the decision can be distributed over several
components etc. but at some level the robot has to set up such a
configuration that either the activated components do not command
conflicting steering commands or there has also an arbitration mechanism
been activated which prefers one steering command over the other in
specific situations. Restricted resources therefore are a good
explanation for task dependent component hierarchies and the sequencing
layer (in my terms as explained in the following paragraphs) not only
configures components, but its main purpose is to avoid conflicts in
configurations. With a task net interpreter, decisions can be made on the
fly, with a finite state automaton everything has to be coded in advance.



>
>
> (BTW Christian: could you give a two line description of a task net? I
> didn' really manage to extract this information out of the Videre
> paper you sent some days ago...)
>

Ok, here is an example of a task net (the syntax changed in the meanwhile
therefore there are slight differences to the Eurobot paper)
(a better paper for coupling the various components might be, I email it
to those which are interested in it)

C. Schlegel, R. Wörz
Interfacing Different Layers of a Multilayer Architecture for
Sensorimotor Systems using the Object-Oriented Framework SmartSoft
Third European Workshop on Advanced Mobile Robots, Eurobot '99
Zürich, Switzerland, September '99


Module representation:

(cdl-module
    (is-a module)
    (globalstate active)
    (strategy following)
    (goal-source person-following)
    (translational-speed 150.0)
    (compatible ((strategy following)(direction person-folowing))
                          (strategy approaching)(direction
object-tracking))
  ....

globalstate one-of (active passive error ....)
strategy one-of (following approaching ...)
goal-source one-of (planner object-tracking ....)
translational-speed interval [0 200.0]


Behavior representation:

(define-tcl (follow ?object)
    (method
        (constraints (and
            (laser-module gobalstate active)
            (vision-module globalstate active)
            ...))
        (configuration (
            (cdl-module goal-source vision)
            (cdl-module stuck-event continuous ?e1)
            ...))
        (task-net
            (parallel
                (t1 (wait-for ?e1 ...) :proceed)
                (t2 (wait-for ?e1 ...) :finish)
.....

Example task net:

(define-tcl (goto-object ?object-id)
    (method
        (context (object ?type ?objectid ?color ?approach-distance))
        (task-net
            (sequence
                (t1 (follow-object ?object-id))
                (t2 (search-object ?type ?color => ?object))
                (t3 (move-to-object-blind ?object ?approach-distance))
))))

>
> So, I would rephrase your definitions of the generic responsibilities
> within every Orocos component as follows:
>
> Resource scheduling
> Alloting resources to components, allowing them to progress in
> parallel, and making sure they don't use the resources in conflicting
> modes.

Resource scheduling is a key feature at various levels. Therefore there
will be no unique place for resource scheduling but many different
instantiations. At the lowest level you have the operating system and you
are lucky if it does a good job. At another level you might want to
decide how to distribute assigned computation time over your activities.
Yet at another level resource scheduling is the decision what to do next,
charge my battery or bring a cup of coffee to my superuser. Therefore I
don't see resource scheduling as a generic responsibility within every
component, only in the sense that a component should at least accept
resource requests / resource constraints and scheduling requests (like
deactiating a module) from outside.

>
> Sequencer
> The sub-component within a component that is responsible for the
> synchronized execution of a service by other sub-components within
> that component. Possible mechanisms for sequencing are: finite state
> machines, Petri nets, task nets, declarative programs, etc.

The sequencing  in the sense of three-layer architectures (like 3T etc)
often is called "sequencing layer". Some implementations even do not have
a separate component but include everything (basic skills etc.) into one
big process. From software engineering aspects and processing power needs
this is not a good idea of course, but is has been done. Therefore
"sequencing layer" should be "sequencing component" in our terminology.
This seems to be what you call "Execution control". See e.g. figure 1 in
the VIDERE paper.

To be consistent one should call your "sequencer" something like
"component sequencer" (I know not a good idea since "sequencing
component" and "component sequencer" is confusing. Does anybody have a
better idea ?). I could also accept "component state sequencer" or .....

>
> Execution control
> The Execution control structure is the structure (``architecture'') in
> which components are connected in order to perform a certain type of
> service.  The structure depends on the type of the service that is
> delivered, but not on a particular service request.  It consists of
> configuration (laying the structure, determining the responsibilities
> of the components in the structure), and of execution (sending of
> events to signal progress or failures).

One example of the above execution control is the sequencing layer etc.
in three layer architectures ....

>
> Configuration
> Setting up the parameters of a system (component, object,
> architecture, communication, ...). This includes activating events,
> enabling states, adding functionality to states, setting attributes,
> checking constraints, setting up communication, etc.

Agreed

> All these things above are `roles' for the supervisor. Or separate
> sub-components, that are woken up by the command interpretation of the
> service requests that enter the component. I'm for a `command
> interpreter' as Orocos concept, because it's clear what it means, and
> it allows us to get rid of the `supervisor' name :-)

I don't understand the details here: if a component receives a query it
might have a thread which is simply blocked until a query request is
received. It starts processing if the current component state allows for
processing and sends back the answer (see query communication pattern).
If the current mode is not suited for processing the query the component
developer already decided within his implementation what to do: enqueue
the query request until the component is able to process it or
immediately return a status code informing the requester that his query
cannot be processed and is ignored. This does not need any commands for
waking up subcomponents.

I agree with respect to setting states and parameters etc. But the state
class of SmartSoft e.g. has its own methods which are not commands. Of
course, one can set up one instantiation of the send pattern which
transfers a set of configuration parameters at once or sequentially (you
don't need a new send class for every single parameter of course). One
might think about some kind of XML ASCII based representation for
parameters (in LISP notation :  (parameter (maxspeed 500.0) (mode
apporach)) )

>
>
> The following two things are not `roles' of the supervisor, but
> definitions we should use consistently in ou documentation and mail
> exchanges:
>
> Communication
> Communication is inter-component exchange of data, i.e.,
> <em>configuration</em> messages and task-dependent <em>data
> transfer</em>. Orocos standardizes on the following set of
> communication patterns: ...

Agreed

>
> Data flow:
> The data flow is the task-dependent information that streams through
> the communication connection between various components. For example:
> maps, laser scans, images, etc.

Agreed


Christian

>
>
> Herman
>
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------