Re: Mini meeting Toulouse 22-23 april / Execution Engine

Christian Schlegel <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Organization FAW Ulm
Message-ID <[email protected]>
Herman Bruyninckx wrote:

> On Thu, 18 Apr 2002, Christian Schlegel wrote:
>
> [...]
> > In our architecture I have a completely separate task execution engine which
> > is responsible for interpreting task nets. That is a very powerful interpreter
> > which coordinates the overall task agenda and sets up various components to
> > fulfill a specific task.
>
> Where exactly do I find the details about this `task net'?

Some details on our task net execution engine can be found in our article on

http://www-mitpress.mit.edu/e-journals/Videre/001/v14.html

Our task net execution engine is inspired very much by the RAP system:

http://people.cs.uchicago.edu/~firby/raps/

The difference is in the language constructs and the exact interface to the basic
skills. In contrast to the original RAP system, we e.g. can keep a basic skill
running even if it has to be reconfigured. What does this mean ? Think on a motion
control component which reactively moves to the next intermediate way point given
by the path planner. This intermediate way point is updated each time the path
planner decides on another one due to progress to the goal or due to obstacles etc.
If the global path however consists of several symbolic waypoints like a chain of
rooms, it takes some time to reconfigure the mapper component, the path planner
component etc. for the next coordinate frame, the next goal regions etc. when
changing rooms. In that case we put the motion control into a reactive "drive
straightforward" mode, which is left as soon as the motion control gets the next
valid intermediate way point. This prevents the robot from stopping between rooms
and from circling around the way point. Since reconfiguration is fast, the robot
does not drive very far in that time (some cm even when driving with 1 m/s). That
kind of reconfigurations have been very troublesome with the original RAP system
and sometimes even not possible.

The task execution engine is one component which is written in LISP. I will try to
provide some kind of manual when I have finished the CORBA based communication
patterns ....


Another approach is the RPL (reactive plan language):

http://www.cs.yale.edu/AI/Planning/rpl.html

That approach is also inspired by the RAP system but more or less consists of lisp
macros etc. Therefore, RPL is a very high level programming package for task
coordination and execution problems. Our approach however is much at the level of
providing a simple task net language which allows people to describe task execution
sequences. Everything else like an agenda mechanism is readily provided and does
not have to be implemented like in RPL e.g.


The TCA activities are (in my opinion) very old activities. TCA is a library for
task execution but is too much related to programming task execution instead of
having a declarative way to specify tasks.


The bandwidth for task execution therefore is from finite state automatons (with
libraries providing support for specifying automatons) to full fledged artificial
intelligence systems with a reasoning component on conflicting ressource
requirements. We so far use a declarative task description language with a task net
interpreter which for some tasks calls a planning system for task expansion. This
proved to be a convenient approach since one can put as much domain knowledge as is
available into the task nets. Furthermore task nets can be modified easily without
"programming". At lower levels, we also use finite state automatons which is put
into a separate component and which simply provides another skill to the system
with resource requirements describing the components it needs since they are
controlled temporarily by the automaton. The task execution engine knows which
ressources are assigned to which task and makes sure these are without conflicts.


By the way: does anybody know the activities on

http://www.roboml.org/


Christian

>
>
> Herman
>
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480

--

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