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