[email protected] writes:
| 3* Defining an event based, realtime capable and programmable 'Execution
| Engine' for handling component control flow. This is partial overlap with
| some patterns in the communication part since they also use
| events. This work is supposed to emerge from LAAS. However, needing
| this urgently at KUL might lead to a proposal from this corner.
Unlike you would expect from the number of mails from
LAAS in the mailing list, things are starting to emerge :)
However, we don't have something usable yet, and you probably
shouldn't expect a first draft before late june. I wish things had
progressed much faster and I'm really doing my best...
If you remember how GenoM works, we are currently able to parse the .gen
file in order to generate the execution engine. This is a rather empty
shell as of now, but it should be able to execute something very soon.
In order to glue things together, we should try to see how you components
could be described in terms of services and how these description fit
into the `.gen' model. If we are able to do this, I'm quite confident on
the possibility to `glue' things together (at least theoretically)
| I actually wanted to discuss.
| --> KTH is using log4cpp, XMLwrap, ACE ( are you happy with this ? ) and TAO,
| a self made build system, some idl specs and an in house made pattern
| implementation. In addition, they deliver the software to build some servers
| to control a robot.
| --> KUL is using automake, has a c++ interface layer, realtime os
| abstraction, a realtime device abstraction layer (comedi, canbus, ...),
| an in house property and reporting system (opposed to XMLwrap and
| log4cpp), a kinematics library (with 3D trajectory generators), and a lot
| of different classes to glue it all together (<-- we know this is bad).
| --> LAAS ???
We have several independant libraries:
- a parser for the .gen files, which translates the specification into a
set of C structures which can be used by an execution engine (or, in our
case, by genom which generates the execution engine).
- a task abstraction library on top of the posix interface which
implements threads, semaphores, timers and shared memory. It is
compatible with the VxWorks API and we use it with our execution engine.
- the execution engine itself, used by genom (here you could use
yours). Almost empty as of now.
- a bunch of makefiles and configure scripts to compile and link all the
bits together.
And as you already know we also have released GDHE (desing of graphical
interfaces). But this is a bit out of the scope of this mail and we'll
have the opportunity to talk about this on june the 20th.
--
Anthony
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.