On Tue, 3 Dec 2002 [email protected] wrote:
[...]
> 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.
Indeed, and making these "well-defined patterns" explicit would be a
very important contribution! I feel that we can do with much less than
the most generic state machine structure, and I also have the feeling
that the minimal FSM interface that you want is the same as the one we
want at the control level!
If one has an interface to a state automaton that is "only" an external
interface, _and_ it is doing the job in the context of robotics, than it
is _very_ worthwhile to have this interface. At all levels.
Does your state interface rely on particular SmartSoft architectural
design decisions?
[...]
> The sequencing layer is in my view simply another component among many
> others which normally operates on top of many other components.
That is similar to our real-time core design: the sequencing is
"outsourced" to a component, such that the other components need not be
coupled at all. The coupling is exactly and only through the sequencing
engine. One single point of decision making!
> Our approach uses our TCL (Task Coordination Language) which allows to
> describe execution sequences in a symbolic and declarative way.
This is "the" TCL, which is now abandonned by its original developers?
I guess the specific language is not so important, but the interface is.
I guess IDL is not suited for describing this interface, is it?
> 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.
This is also behind the Esterel/Orccad approach, as presented by Daniel
Simon at the Leuven meeeting. Of course, this kind of functionality is
quite natural in any sequencing component.
> 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).
Yes, I see.
> 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.
Both approaches are fully complementary, I think. They just provide
similar fucntionality at different levels and for different purposes.
But I think they might have _a lot_ in common, so making this
commonality explicit really interests me... That's the kind of things
Orocos is about: finding common designs for many robotics "things".
> 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 ?
That would be nice!
> 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.
Everything should be archived at
<http://mail.mech.kuleuven.ac.be/pipermail/orocos/>
Herman
PS I'm preparing to launch an "Orocos II" project, and this kind of
"task level" infrastructural software and protocols is one of the things
I think would be in such a project.
--
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.