| Newsgroups |
gmane.science.robotics.orocos.user |
| Organization |
FAW Ulm |
| Message-ID |
<[email protected]> |
[email protected] wrote:
> This sounds to me to be a feature that is useful in other contexts also,
> such as in the real-time control. There, we were thinking of getting the
> dynamic (re)configuration by using some sort of "genom" execution
> engine, which can "rewire" according to the state it is in. Is this
> also the "sequencing mechanism" you are referring to, or do you use
> another approach?
>
> If it is indeed the same approach, it is worthwhile to think about a
> common nomenclature and documentation :-)
Hi,
The goal of the "genom" execution engine and the goal of the "sequencing
layer" is the same but the approaches are a bit different. The SmartSoft
communication patterns provide the basic component infrastructure without
restricting the internals of every component to a specific state automaton.
The decision on which kind of component internal mechanism is used for
activity coordination is related to the question of the component
architecture. The goal of SmartSoft is to provide a stringent notion of
component without being too strict with respect to the component internals.
This ensures interoperability while not restricting every component to a
specific component architecture. To achieve this, we map every component
external activity to well-defined patterns.
One now has to distinguish carefully between component internal automatons
for component internal activity coordination (genom execution engine versus
SmartSoft state / wiring pattern) and between components coordinating other
components (GenoM overall architecture versus FAW three layer architecture
with TCL). The GenoM execution engine mainly addresses the first issue and a
sequencing layer mainly addresses the second issue. Both tasks can however
be solved by a finite state automaton, but this is not the only possible
approach.
The sequencing layer is in my view simply another component among many
others which normally operates on top of many other components. Our approach
uses our TCL (Task Coordination Language) which allows to describe execution
sequences in a symbolic and declarative way. The statements include
configurations and are very similar to the RAP system (Firby). Task nets are
composed of "parallel" and "sequence" constructs, form hierarchical
tree-like descriptions of complex activities and are executed by an
interpreter resulting in appropriate configurations of components. The
synchronization of the execution progress with the task net steps is
performed by events. The task net description are very simple to use and
even complex task executions can be described easily. The TCL includes among
other concepts a statement to describe a finite state automaton and is not
included in every component, but is a separate component which can be used
to master other components. This is needed as soon as resources are bounded
and one needs more and more centralized decisions on what to do next in
which configuration.
The sequencing layer imposes several constraints on other components to be
able to coordinate their activities. This for example includes dynamic
component wiring (wiring pattern) and graceful activity deactivation (state
pattern). Since these patterns are needed in robotics components, they are
included in the implementation of the SmartSoft component framework. In
SmartSoft, we do NOT require a specific automaton in every component as is
proposed with the GenoM component architecture. We however need at least the
state pattern (deactivation of blocked communications etc.) and the wiring
pattern for simple and standardized interfaces to any kind of task
coordination mechanism. In SmartSoft, it is up to the component builder to
choose an appropriate component internal structure. The state and the wiring
pattern provide the smallest needed basis. Every component builder is free
to coordinate his component internals by a more elaborate finite state
automaton or simply use the state / wiring pattern.
Instead of using the TCL component as sequencing layer, one can also use a
finite state automaton for component coordination.
Boris, could you please again mail the short documentation on our finite
state automaton task coordination mechanism which runs on top of the
communication patterns ?
Common nomenclature is always a good idea and I would support any effort of
trying to find good definitions ! Documentation is needed as well, but I
currently do not have an uptodate description of the TCL. I already sent
some mails into this list regarding the sequencing layer and others some
months ago and perhaps those mails are still available somewhere.
Cheers
Christian
>
>
> Herman
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +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/
---------------------------------------------------------------------