Automatic Robot Programming from Learned Abstract ...

Proceedings of the 2007 IEEE/RSJ International Conference on Intelligent Robots and Systems San Diego, CA, USA, Oct 29 - Nov 2, 2007

WeA7.3

Automatic robot programming from learned abstract task knowledge Steffen Knoop, Michael Pardowitz, R¨udiger Dillmann IAIM, Institute of Computer Science and Engineering (CSE), University of Karlsruhe(TH), Germany [knoop,pardowitz,dillmann]@ira.uka.de Abstract— Robots with the capability of learning new tasks from humans need the ability to transform gathered abstract task knowledge into their own representation and dimensionality. New task knowledge that has been acquired e.g. with Programming by Demonstration approaches by observing a human does not a-priori contain any robot-specific knowledge and actions, and is defined in the workspace and action space of the human demonstrator. This paper presents an approach for mapping abstract human-centered task knowledge to a robot execution system based on the target system properties. Therefore the required background knowledge about the target system is examined and defined explicitely. The mapping process is described based on this knowledge, and experiments and an evaluation are given.

I. I NTRODUCTION Within the last years, robotic research has changed its focus more and more towards the domain of service robots for flexible applications in dynamic environments. The vision is to bring robots and humans together, and equip robots with the ability to work with humans in a natural and intuitive way. This includes on the one hand the capability to efficiently communicate with humans in a natural way; on the other hand, it creates the need for life-long learning and adaption of the robot’s knowledge. This knowledge comprises many areas, ranging from social behavior to geometrical and relational environment models as well as skill and task knowledge. Cooperative acquisition of new models for the robot raises two questions: How can the learning part be accomplished, and how can the the acquired knowledge be exploited by the robot? This paper addresses especially the second question for the domain of task learning and execution. Existing approaches for Programming by Demonstration yield a natural way for humans to teach a robot new tasks by simply showing, demonstrating and commenting the task to the robot. From the observation, the robot builds a hypothesis of the task and its goals. Based on this task description, we present an approach for generation of robot programs which can directly be executed by the robot. The challenge for this process is to transfer the task from a task sequence representation in human action space to an operable robot program formulated in the task language of the target robot. II. S TATE OF THE ART Learning and execution of tasks with autonomous robots has been studied for several years, ranging from trajectory learning with subsymbolic machine learning techniques to symbolic sequence learning and analysis. However, the

1-4244-0912-8/07/$25.00 ©2007 IEEE.

problem of mapping learned tasks to a robot has not been adressed explicitely; past and current works either concentrate on the learning part (e.g. directly in sensory-motor space) or on task execution. a) Programming by demonstration (PbD): Different approaches have been proposed and have been reviewed in [1], [2]. Systems can be discriminated by the learning paradigm applied: Imitation learning systems are used to re-identify and execute human motions [3], aiming at a high similarity of the robot’s movements to the demonstrated trajectories [4]. These systems require a large set of task demonstrations for generalizing the trajectory before the learning process can start, and the demostration in most cases is performed directly in sensory-motor space of the robot. Background knowledge based or deductive PbD-systems, as presented in [5], [6], [7], usually require much less or even only a single user demonstration to derive task descriptions. These systems analyse and interpret the task demonstration with respect to the changes and effects the user’s actions affect the environment. b) Task description languages: Several task descriptions have been developed during the last decade which are highly interesting and have proved their reliability and effectiveness in several projects, mainly evolving from the field of robot programming languages. Robot programming languages are mostly built as extensions to standard programming languages like C (see Colbert [8]) or LISP (see RAPs [9][10], Frob [11]). Here, runtime extension of tasks is not possible or only according to predefined rules. A survey can be found in [11]. Declarative task descriptions often rely on static descriptions. These are tree-like (e.g. TDL [12], or HTN [13], [14]) or procedural (see [15], [16]). However, most existing declarative task descriptions have been designed for manual task compilation or for task planning methods and do not support or even enable generation from observed and learned action sequences. Therefore, a task description called Flexible Programs (FP) has been set up (for details, see [17]). This task description follows the HTN concept and consists of a database of associated and linked actions. It runs the robot AlbertII in our lab, which includes a mobile platform, one 7Dof manipulator, a 4Dof hand, and an active stereo camera head.

1651

Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.

III. BASIS This section introduces the abstract task representation called Macrooperators, which are derived from user demonstrations, and the concept of Flexible programs which is used for task execution on our service robot AlbertII. A. Macrooperators This section gives a short overview of the task acquisition process and the classes of manipulation tasks that can be detected and processed by our PbD system. During the demonstration of a task in a so called trainingcenter, the user is observed using different sensors. Further details on the hardware used can be found in [18]. From sensor input data, so called elementary operators are extracted. Elementary operators (EO’s) are actions that abstract a sensory motor coupling like primitive movement types (linear moves etc.), grasp and release actions. EO’s are aggregated as primitives to so called macro-operators (MO’s), containing the full task description in the human action space. On a basis level, elementary move operators are aggregated to “approach”, “depart” and “transport” trajectories. Together with the grasp and release EO’s, picking and releasing of objects can be identified. Between these operations, various basic manipulation operations may be detected like transport operations, pouring operations and tool handling for instance. For further details, please refer to [7]. On the highest level, a sequence of manipulation segments is subsumed under a whole task demonstration. The environment, its changes and the pre- and postconditions are described in terms of first order predicate logics, based on a set of geometrical inter-object relations (like “on”, “under”), intra-object predicates and object-dependent internal state descriptors (“opening angle”, “oven temperature”). With multiple demonstrations of the same task available, reordering possibilities that exist during the execution time of a task can be learned (see [19]). They are represented by task precedence graphs (TPGs). A TPG for a task is a directed graph P = (M, N) with M being the set of subtasks or successors and N ⊂ M × M being the set of precedence relations a faultless task execution must comply with. A precedence relation (s1 , s2 ) ∈ N with s1 , s2 ∈ M implies that the operation s1 must be complete before the execution of s2 can start. For example, M = {a, b, c, d} and N = {(a, b), (b, d), (c, d)} implies that the successors a, b and d must be executed in this order and that c can be scheduled anywhere before d. The result of the task acquisition process outlined in this section is a robot-independent task description called macrooperator, containing a sequence of manipulation segments together with their pre- and post-conditions and the hierarchical decomposition into elementary operators. B. Flexible Programs Similar to TDL and HTN planning, the task is described as a hierarchical network which is processed with a depth-first left-to-right search strategy. In contrary to other representations, the FP task tree is not statically built, but instantiated

Fig. 1. Example with three seats in a node, where the first two seats hold two candidates each, and the last one has only one prospective child node. Prospective parent-child relations are depicted with dashed lines.

dynamically at runtime. This is a major difference to other HTN representations and enables especially online adaption and extension of task networks. This is a crucial feature for online task learning and parameterization from human–robot interaction. A detailed description of Flexible Programs can be found in [17]. Generally, two different node types exist: Leaves contain actions or other flexible programs which have to be executed. Their list of prospective children in the task tree is always empty. Inner nodes contain execution rules which control the order and execution of child nodes within the prospect which must not be empty. Their action is always empty. Consequently, all robot actions are contained in tree leaves which are connected by inner nodes. The child prospect in inner nodes contains possible child configurations, which are then selected to build the task tree. The prospect is composed of a set of n > 0 seats with m > 0 candidates each. The seats are arranged in p ≤ n parallel groups. The task tree is built from all prospective configurations by dynamically selecting one candidate for each seat at runtime, so that the parent node finally contains one child node per seat. An example can be seen in fig. 1, where the parent node initially contains seats with two candidates each. Candidate selection is done based on two criteria: First, the preconditions Ppre of each candidate are evaluated. If more than one candidate remains selectable, their rating functions R are evaluated to obtain a continuous measure for applicability of the candidates. Children which are arranged in seats within parallel groups in the prospect will be executed in parallel. As stated before, tree leaves contain basic actions. This can either be a command to one of the hardware abstractions, or it can be the execution command and parameters for another flexible program. In both cases, the action will be marked as completed when a corresponding notification from the target instance returns. These actions can be further parameterized from the environment model by using variables from the global database. It can be specified in each node which slot has to be filled from which variable. In the same way, action results (return values) can be stored, thus giving the possibility to pass parameters from one node to another. An issue which is still open in robotics is the selection of the elementary actions, both on observation and execution side. In existing systems, granularity of basic actions is mostly chosen according to the application, giving e.g. finer

1652 Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.

granularity for coordinated movements than for task planning in STRIPS-like scenarios. In our context, EOs are chosen as the smallest entity that can be observed (i.e. basic movement types, grasps according to Cutkosky’s classification), while FP leaves represent single commands to the executing hardware control layer. C. Problem statement and analysis The aim of the work presented in this paper is to automatically transform abstract task knowledge into an executable robot program. For the given context, this means the task of mapping a Macrooperator to a Flexible Program. As the target task description compulsorily is robot-specific, the transformation process must also be dependant on the target system and task description. The presented work is however not limited to MOs and FPs, but gives a general analysis of the required information and mechanisms. So more generic, the problem can be formulated as follows: Which knowledge about the target execution system do we need to introduce into pure abstract task knowledge to obtain an executable robot program? What steps are required to perform the compilation process? To answer these questions, first the characteristics of both task descriptions need to be investigated. • The MO only contains primitive actions which are considered as relevant for task completion by the PbD system. Furthermore, not all actions can be extracted from observation. E.g. sensory actions like localization of objects cannot be observed, and the PbD system thus acts on the Closed-world assumption. • A task learning system only uses successful demonstrations for learning. A Macrooperator does not contain any actions for error recovery or emergency situations. All error handling which is to be included in the resulting robot program has to be generated and added during task compilation. • A Macrooperator is given in the action space of the demonstrating human, including workspace, capabilities and kinematics. The robot program must be specified in the action space of the executing robot. So all actions need to be mapped from human into robot space, maintaining the action goals. A related issue is the decision whether a task can be successfully transferred to the target system or not. There are obvious criteria, like the number of required manipulators for coordinated actions; but also many non-trivial constraints exist. This question will not be addressed in detail within this paper. IV. M APPING APPROACH Following the problem statement in sec. III-C, two main issues need consideration for a successful, open-ended and portable mapping: The compilation process and the required knowledge about the target system. This section describes the

proposed compilation process, and sec. V then summarizes the required system knowledge. This explicite definition then enables porting and mapping to other robot agents. Fig. 2 outlines the global compilation process, which consists of four main steps. The first step performs the structure mapping from the Macrooperator to a preliminary Flexible Program. It is described in sec. IV-A. The resulting FP is then manipulated according to a set of predefined rules, which change, add or delete task knowledge (see sec. IV-C). This is the core of the mapping process. Finally, subtasks are identified which can potentially be parallelized (see sec. IV-D) based on the MO contents and the target system specification. A. Structure mapping The first step for transformation of a MO to an FP consists in the so-called structure mapping or direct transformation (see fig. 2). This step generates a preliminary robot program by mapping the MO structure and contents to the robot task description. The transformation is done recursively, following the structure of the MO in a depth-search manner from left to right. A first version of the resulting FP is generated. For each node in the MO tree, the following steps need to be carried out: 1) Generate an FP root node for the target program, and start with the MO root node. 2) Extract successors, precedences and explicit parallelizations from the current MO node. 3) Generate all candidates for the current FP seat. 4) Construct the child seat structure for each candidate. Depending on the number of candidates, proper alternative resolution needs to be done. 5) Perform step 2 to 4 for each resulting child candidate. It is important to note that the result of this step does not deliver an executable robot program; it only contains parts of the necessary actions and structure that need to be performed for achieving the desired goal.

Fig. 3. Resulting Flexible Program for a partially ordered Macrooperator. Candidate relations are drawn with dashed lines, candidates for the same seat are grouped together in a box.

With the hierarchical MO and FP descriptions given in sec. III-A and III-B, the structure mapping for fully ordered MOs is straight-forward. As both MO and FP representation are hierarchically built, the structure mapping reduces to a syntax mapping. For partially ordered MOs which do not define precedence relations for every contained operator pair, and for MOs with explicitely defined parallel operations, the FP structure is quite different to the MO. An example FP can

1653 Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.

c0 and P b denote preliminary robot programs, and P 0 and P denote Fig. 2. Task knowledge translation process. O denotes the source Macro Operator, P executable robot programs

be seen in fig. 3. The depicted structure is generated for the MO subtree with current node v (see example in sec. III-A), and Successors M = {a, b, c, d} Precedences N = {(a, b), (b, d), (c, d)} The grey nodes have been created and added during mapping to maintain the precedences. Fig. 3 can be read from top to bottom: Following the given precedences, node d must occur at the end. For odering {a, b, c} there are two candidates v1 and v2. For v1, a can be factored out, resulting again in two alternatives for ordering b and c. The remaining node order c, a, b is represented by v2. For a different target task description, the mapping process is necessarily different. Nevertheless, it is possible to map the acquired task knowledge to any other description, given that it yields at least the same power (conditions, branching etc.). B. Elementary Operator mapping After mapping the MO structure, the EOs need to be mapped from observation to execution space, which is deb picted in fig. 2, giving P. Basically, this mapping must be known a priori. So for each occuring EO, a corresponding FP node must be given. An EO from observation does not necessarily correspond to one basic robot action. This leads to two cases during EO mapping: 1) The current EO corresponds to a single robot action, represented by a leaf in the FP tree. The corresponding node can be directly generated from a mapping table. 2) The EO needs to be represented by an FP node tree, which is compound from a set of nodes. In this case, the mapping replaces the EO with a whole given subtree. In both cases, only the node type mapping is given. The action parameters still need to be transformed into execution space. E.g. a TCP (tool center point) motion that is given in the reference frame of the observation must be transformed into the robot’s coordinate system before it can be executed. Parts of these issues can be adressed by shifting the problems into the FP: E.g. a TCP movement from an EO can be replaced in FP space by a large subtree which checks reachability, possibly moves the robot base, and then moves the arm.

b the reSo for mapping the MO O to the preliminary FP P, quired a-priori knowledge about the target system comprises the structural constraints of the target task description, and the mapping for each EO. For transformation of parameters like trajectories, grasps etc, either a mapping or a functional description must be given a-priori. In a later stage, these functions and parameters may be adapted or even learned by the system with techniques known from imitation learning. C. Rule-based tree manipulation To ensure an action sequence that can successfully be executed, it is necessary to include further information about the robot system, because a syntactically correct program does not guarantee a reasonable task sequence. According to sec. III-C, the observed action sequence does not hold all necessary actions for execution. Fig. 2 depicts this step as rule-based manipulation of the preliminary task description. This step has to accomplish two goals: First, it has to ensure correct execution, and second, it has to include subtasks that are convenient but not mandatory for execution. These two goals lead to two different rule types for task knowledge manipulation: Mandatory rules comprise b to all manipulation rules which need to be applied to P ensure correct execution. As stated in sec. III-C, the MO e.g. contains grasp and release actions, but no actions for localization of objects to grasp, which is not necessary there due to the closed-world assumption, and which can also not be detected at all when performed by a human. Convenience rules contribute to the transparency and appearance of the resulting task description. This especially comprises feedback to a user like speech or display output. Nevertheless, application is optional. These rules are defined as a 5-tuple (N, P, I, C, A) with N being a unique name, P a set of activation patterns, I the ingress nodes which must be part of the pattern, C an additional condition which must be true for rule application, and A the actual tree manipulation action. This action can add or remove nodes to the tree relative to the defined ingress node. In some cases, dependencies between rules can occur. If a dependency between two rules R1 and R2 exists, according to graph manipulation theory, application of R1 can either activate or deactivate R2 , or it destroys the contribution of R2 . To avoid these effects, all dependencies need to be

1654 Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.

defined. Based on this, a rule dependence graph can be set b up which orders the applicable rules for a given P. Considering the dependence relations between different potentially applicable rules, one follows the directive: All potentially applicable rules must be applied. Potentially applicable are those rules which are either applicable directly or which are activated by another potentially applicable rule. This directive has been set up heuristically, and it makes sense given the fact that mandatory rules must be applied to the according patterns to ensure successful execution. The set of designed mandatory rules for the described setup contains e.g.: • Open hand prior to each grasp operation. Activation pattern P (grasp), ingress node I (grasp), C (true), action A searches the appropriate tree location for the open hand operation and adds the according node. • Move arm into a safe position before driving to a different location. • Localize object before grasping it. • Exception handling adds a feedback and a safe termination to each node which has a non-nil precondition. The inverse precondition of the original node gives the precondition for the exception handling. • Resource allocation nodes are inserted when necessary. To avoid colliding parallel actions in the robot, all physical components of the robot are organized as resources which must be allocated to a certain FP before usage. These resource allocation nodes are inserted into the task tree. Convenience rules are e.g.: • Speech comments are generated for high level nodes. For each node which is annotated with speech, a corresponding output is generated which contains the action name. • Visual feedback is generated in the same way to visualize the current robot state on its display. D. Parallelization Obviously, many elementary operations can be carried out in parallel to reduce the overall execution time. Logically, two actions can be executed in parallel if their resource sets are disjoint and their effects are independent. In contrary, dependencies like [first go to position, then grasp object] have dependent effects. However, for an action sequence which has been obtained from observation, the effect dependencies cannot be resolved robustly. On the other hand, the used resources can easily be extracted from the contained robot actions. Actions that are marked in the MO as “parallel actions” have been translated accordingly during the first step. So this last step considers only potential parallel execution of actions that are not marked explicitely as such. These mainly originate from previous tree manipulation, like addition of speech output, object localization etc. It is e.g. obvious that any speech comment can be executed in parallel with its according action node.

Based on a predefined set of possible parallisms, this step processes the task tree to find sibling nodes which can be parallelized. E.g. speech comments are always arranged in parallel with their corresponding action, a close hand action is also parallellized with any other action. V. TARGET SYSTEM PROPERTIES This section summarizes the system properties required for the mapping process, which need to to be described explicitely beforehand. • The structural organization of the robot task knowledge is crucial for mapping between different task descriptions. The structure may be hierarchical (like described in sec. III-B), or a finite state machine (FSM). Other examples include Petri Nets or precedence graphs. In any case, the target task language needs to provide at least the same power than the source, and mapping strategies for each control structure must exist. • For elementary operators, a mapping to the target execution language must exist. This mapping contains not only an assignment of actions, but also functions to transform grasps, trajectories and other parameters into the robot’s execution space. Many works dealing with mapping of single actions can be found in literature. E.g. grasp mapping is often based on the concept of virtual fingers which serve as an intermediate step between the source and the target mapping space. For details, see [20] and [21], where this concept has been introduced and used initially. • The tree manipulation rule set must be defined a priori. More generally, it is required to define which actions need to be added or modified in the original sequence to obtain an executable robot program. According to sec. IV-C, two basic classes of modification rules can be distinguished: Mandatory and convenience rules. Furthermore, dependencies between these rules must be established to derive a correct application order. • Actions that have not been observed in parallel but can be executed concurrently must be defined. This is especially expedient for feedback to the user, but also other actions can be carried out simultaneously. Potential concurrencies are highly dependent on the target system; two pick-and-place operations may e.g. be parallelized for a system with two manipulators, if reachability is given; for a robot with only one manipulator they have to be serialized. Explicite definition of these features of the target robot system and execution language is the first step towards an automated mapping process, which transforms systemindependent task knowledge onto a dedicated robot. A unified mapping process then can, by exchanging the target system properties, map an observed task to different robot systems. VI. E XPERIMENTS AND RESULTS Two types of experiments have been conducted to evaluate the presented approach. The first experiments concern the

1655 Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.

TABLE I M APPING

RESULTS FOR

20 DIFFERENT M ACROOPERATORS , ORDERED

BY NUMBER OF NODES IN SOURCE

MO name Approach Transport Approach Retreat Pick Place Place Pick Pick and place Pick and place Pick and place Pick Place Pick and place Pick and place Pick and place Lay table 3 objects Lay table 3 objects Lay table 3 objects Lay table 6 objects

#nodes MO 4 5 6 9 19 21 24 27 38 39 40 42 54 56 57 58 136 139 149 228

#nodes FP 19 30 21 26 39 42 45 47 106 117 118 62 75 124 135 126 389 392 402 721

MO Mapping time/sec 0.36 0.48 0.45 0.62 1.06 1.07 1.16 1.25 2.48 2.63 2.64 1.84 2.25 2.96 3.16 3.01 9.26 8.95 9.62 19.52

Fig. 5. Resulting Flexible Program with 20 nodes. Nodes with a dot contain additional parameters like trajectories, positions, or simply text.

mapping process itself: Different Macrooperators have been mapped to FPs to evaluate the performance and computation time of the implemented approach. Second, the resulting FPs have been executed on the target robot in simulation to evaluate the correctness and completeness of the resulting robot programs.

operations from the MO can still be identified. Additional actions have been added by the mapping process i.e. to give feedback to the user (Voice Out and Display Out), and to properly allocate and free resources for execution (see also sec. IV-C). The first tree leaf contains an action which triggers a global switch to avoid automatic resource locking behaviour, which is added in every automatically compiled FP. It is obvious that the FP contains many more nodes than the source MO, due to the fact that additional execution commands have been introduced. Also, the tree depth has grown, which heavily depends on the complexity of the MO and the applied rules. Especially when the MO contains explicite parallel node groups, insertion of resource allocation and exception handling increases the tree depth. Here, the difference between abstract task knowledge derived from observation and an actual robot program can be studied. While the MO only contains only abstract operation statements independent from any executing system, the FP is specific to one particular robot, with a particular programming language etc.

A. Mapping evaluation

B. FP execution and evaluation

For evaluation of the mapping itself, a set of 20 Macrooperators has been mapped to FPs. It is evident that the mapping process results and performance are highly dependent on the contents of the Macrooperator, as rule application depends on the occurence of the respective activation patterns. Therefore, it has been tested with Macrooperators from demonstrations with different content. The resulting number of nodes and computation time can be found in tab. I. Looking at the relation between the amount of nodes contained in the source description and the required computation time for mapping, a linear dependency seems obvious. Nevertheless, it is important to note that different MO structures can result in completely different mappings. For comparison between source Macrooperator and resulting FP, a very simple MO with 5 nodes is depicted in fig. 4. It consists in 4 sequential arm movements, which are of type free move and linear move. These 4 movements are compound for an approach operator, which has been taken from a pick operation. This simple MO can now be translated into a Flexible program, the resulting FP is depicted in fig. 5. The move-

To validate the mapping result, the FP has to be executed on the target robot. To evaluate its correctness, the resulting FPs have been tested on the robot AlbertII in simulation. Fig. 6 shows an example sequence taken from execution of an FP “Laying the table with 3 objects”, which has been generated from a Macrooperator. The MO consists of 136 nodes, and the FP has 389 nodes. Execution has been successful in simulation, and the following conclusions can be drawn: • Mapping of abstract task knowledge to a dedicated robot system can be done automatically following the presented approach. • Transformation of each single movement into the robot’s workspace needs to be further investigated. In fig. 6, the robot trajectories follow the demostration, which in some cases leads to collisions with the environment. This can be avoided by applying state-of-theart path or grasp planning techniques, thus obtaining a collision-free path to the target location. However, by doing this, the robot might deviate from the intended task that has been demonstrated, which is unwanted.

Fig. 4. Source Macrooperator for mapping, 5 nodes. Nodes with a dot contain trajectory information.

1656 Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.

Fig. 6.

Execution of FP ”Laying the table with 3 objects” in simulation (left to right). The table with 3 objects is located in the foreground.

So here, it seems necessary to build a more detailed hypothesis of the user’s intentions to derive a correct and still collision-free robot path. VII. D ISCUSSION AND CONCLUSION This article has presented an approach for mapping symbolic task knowledge that has been obtained from user demostrations by a Programming by Demonstration system to a particular robot task language. Especially the required knowledge about the target system and task language has been investigated and defined explicitely. The approach is one step towards an automated mapping of high level tasks to various robot systems. Generally, it is necessary to collect a dedicated set of information and functions for a target robot system and define it explicitely. The mapping process then generates robot programs automatically based on the system description. This exhibits the main difference to existing approaches: Existing mapping approaches are always designed for one specific robot and one target task language. In many cases, it is even necessary to perform the demonstration in the robot’s workspace by driving it active or passively, which is not feasible for users who expect the robot to behave like humans. R EFERENCES [1] R. Dillmann, O. Rogalla, M. Ehrenmann, R. Z¨ollner, and M. Bordegoni, “Learning Robot Behaviour and Skills based on Human Demonstration and Advice: the Machine Learning Paradigm,” in 9th International Symposium of Robotics Research (ISRR 1999), Snowbird, Utah, USA, October 1999, pp. 229–238. [2] S. Schaal, “Is imitation learning the rout to humanoid robots?” in Trends in Cognitive Sciences, vol. 3, 1999, pp. 233–242. [3] S. Calinon and A. Billard, “Learning of gestures by imitation in a humanoid robot,” in Imitation and Social Learning in Robots, Humans and Animals: Behavioural, Social and Communicative Dimensions, K. Dautenhahn and C. Nehaniv, Eds. Cambridge University Press, 2005. [4] A. Alissandriakis, C. Nehaniv, K. Dautenhahn, and J. Saunders, “Using jabberwocky to achieve corresponding effects: Imitating in context across multiple plattforms,” in Proc. of Workshop an the social mechanisms of robot programming by demonstration at ICRA 2005, 2005. [5] Y. Sato, K. Bernardin, H. Kimura, and K. Ikeuchi, “Task analysis based on observing handds and objects by vision,” IEEE/RSJ Int. Conf. on Intelligent Robots and Systems, Lausanne, pp. 1208 – 1213, 2002.

[6] Y. Kuniyoshi, M. Inaba, and H. Inoue, “Learning by watching: Extracting reusable task knowledge from visual observation of human performance,” IEEE Trans. on Robotics and Automation, vol. 10, no. 6, pp. 799–822, 1994. [7] R. Zoellner, M. Pardowitz, S. Knoop, and R. Dillmann, “Towards cognitive robots: Building hierarchical task representations of manipulations from human demonstration,” Intl. Conf. on Robotics and Automation (ICRA) 2005, Barcelona, Spain, pp. 1535 – 1540, 2005. [8] K. Konolige, K. L. Myers, E. H. Ruspini, and A. Saffiotti, “The Saphira architecture: A design for autonomy,” Journal of experimental & theoretical artificial intelligence: JETAI, vol. 9, no. 1, pp. 215–235, 1997. [9] R. J. Firby, “The rap language manual, version 2,” I/NET Inc., Tech. Rep., 2001. [10] R. Firby, “Adaptive execution in complex dynamic worlds,” Ph.D. dissertation, Yale University, Computer Science Department, 1989. [11] G. Hager, J. Peterson, and P. Hudak, “A language for declarative robotic programming,” in Proceedings of the International Conference on Robotics and Automation, 1999, pp. 1144–1151. [12] R. Simmons and D. Apfelbaum, “A task description language for robot control,” in Proceedings of the Conference on Intelligent Robots and Systems (IROS), 1998. [13] K. Erol, J. Hendler, and D. S. Nau, “HTN planning: Complexity and expressivity,” in Proceedings of the Twelfth National Conference on Artificial Intelligence (AAAI-94), vol. 2. Seattle, Washington, USA: AAAI Press/MIT Press, 1994, pp. 1123–1128. [14] K. Erol, J. Hendler, and D. Nau, “Semantics for HTN planning,” Computer Science Dept., University of Maryland, Tech. Rep. CS-TR-3239, 1994. [15] K. L. Myers, “A procedural knowledge approach to task-level control,” in Proc. of the 3rd International Conference on Artificial Intelligence Planning Systems, B. Drabble, Ed. AAAI Press, 1996, pp. 158–165. [16] B. Jensen, G. Froidevaux, X. Greppin, A. Lorotte, L. Mayor, M. Meisser, G. Ramel, and R. Siegwart, “The interactive autonomous mobile system robox,” in Proceedings of the 2002 IEEE/RSJ Intl. Conference on Intelligent Robots and Systems. IEEE, 2002, pp. 1221– 1227, ePFL, Lausanne, Switzerland. [17] S. Knoop, S. R. Schmidt-Rohr, and R. Dillmann, “A flexible task knowledge representation for service robots,” in The 9th International Conference on Intelligent Autonomous Systems (IAS-9), Kashiwa New Campus, The University of Tokyo, Tokyo, JAPAN, Mar 07 2006. [18] M. Ehrenmann, R. Z¨ollner, O. Rogalla, S. Vacek, and R. Dillmann, “Observation in programming by demonstration: Training and exection environment,” in Humanoids 2003, Karlsruhe/Munich, Germany, October 2003, 2003. [19] M. Pardowitz, R. Z¨ollner, and R. Dillmann, “Learning sequential constraints of tasks from user demonstrations,” in Proc. IEEE-RAS Intl. Conf. on Humanoid Robots, Japan, 2005, pp. 424 – 429. [20] S. Kang, “Robot instruction by human demonstration,” Ph.D. dissertation, Carnegie Mellon University, Pittsburg, Pennsylvania, 1994. [21] M. Arbib, T. Iberall, D. Lyons, and R. Linscheid, Hand Function and Neocortex. A. Goodwin and T. Darian-Smith (Hrsg.), Springer-Verlag, 1985, ch. Coordinated control programs for movement of the hand, pp. 111–129.

1657 Authorized licensed use limited to: Georgia Institute of Technology. Downloaded on April 8, 2009 at 21:08 from IEEE Xplore. Restrictions apply.