This is a repository copy of The RACE Project : Robustness by Autonomous Competence Enhancement

This paper reports on the aims, the approach, and the results of the European project RACE. The project aim was to enhance the behavior of an autonomous robot by having the robot learn from conceptualized experiences of previous performance, based on initial models of the domain and its own actions in it. This paper introduces the general system architecture; it then sketches some results in detail regarding hybrid reasoning and planning used in RACE, and instances of learning from the experiences of real robot task execution. Enhancement of robot competence is operationalized in terms of performance quality and description length of the robot instructions, and such enhancement is shown to result from the RACE system. 1 Project Aim and Demonstration Domain RACE (Robustness by Autonomous Competence Enhancement) is a project funded by the European Commission under the 7th Framework Programme and running from 12/2011 to 11/2014. The partners are those J. Zhang, L. Zhang, S. Rockel, B. Neumann, J. Lehmann Hamburg University E-mail: zhang@informatik.uni-hamburg.de K. S.R. Dubba, A.G. Cohn, University of Leeds A. Saffiotti, F. Pecora, M. Mansouri, Š. Konečný Örebro University J. Hertzberg, M. Günther, S. Stock Osnabrück University L.Seabra Lopes, M.Oliveira, G.H. Lim, H.Kasaei, V.Mokhtari University of Aveiro L. Hotz, W. Bohlken HITeC Hamburger Informatik Technologie-Center e. V. institutes from which this paper is authored. This short project report summarizes the RACE methodology of working towards achieving these aims, and it sketches main project results, as visible about half a year before the end of the project. The overall aim of RACE as set out in the description of work was to develop an artificial cognitive system, embodied by a service robot, able to build a high-level understanding of the world it inhabits by storing and exploiting appropriate memories of its experiences. Experiences will be recorded internally at multiple levels: high-level descriptions in terms of goals, tasks and behaviours, connected to constituting subtasks, and finally to sensory and actuator skills at the lowest level. In this way, experiences provide a detailed account of how the robot has achieved past goals or how it has failed, and what sensory events have accompanied the activities. Contributions were foreseen in the description of work to advance the state of the art along three lines: 1. robots capable of storing experiences in their memory in terms of multi-level representations connecting actuator and sensory experiences with meaningful high-level structures, 2. methods for learning and generalising from experiences obtained from behaviour in realistically scaled real-world environments, 3. robots demonstrating superior robustness and effectiveness in new situations and unknown environments using experience-based planning and behaviour adaptation. 2 Joachim Hertzberg et al. Fig. 1 The PR2 robot Trixi grasping mugs from the counter. So the thrust of the project was clearly of a conceptual nature. Yet, to demonstrate an integrated system and to have it learn from experiences, a physical robot and a demonstration domain are clearly needed. An “academic” demonstration domain was used to focus on the conceptual issues rather than application requirements, and to keep low the overhead for providing permanently the real-life demonstration scenario and for modeling it in a good simulation environment that would allow project partners to work independently at their sites between code integration events. The demonstration domain is an AI and Robotics classic: a (mockup) restaurant with a robot waiter. The robot, Trixi, Fig. 2, is a PR2 with an additional RGBD camera on top of its head. The task spectrum of Trixi is to serve guests in the mockup restaurant. Fig. 2 schematically shows one of a number of several scenarios defined for the restaurant domain; these scenarios are available both physically in a lab room and in simulation (Gazebo). Having such fixed scenarios allows tasks to be executed under somewhat controlled environment conditions to compare robot performances over different degrees of experience in the domain on Trixi’s side. In the sparsely populated scenario in Fig. 2, it would make sense to give Trixi the order “Serve mug1 to guest1! ” or “Serve coffee to guest1! ”, both yielding the same service. It is also conceivable to teach Trixi how to serve: “Pick up the mug at the counter, bring it to the guest at table1 – this is how to serve a coffee”. It is assumed that basic robot behavior (such as navigation, object handling, object recognition) is available on Trixi – actually, RACE has started from standard capabilities available for a PR2 in ROS [17], cf. Sec. 2.1 for an explanation of the control architecture. Standard restaurant action schemata for a waiter, such as serving something to some guest, are available in a pre-defined Fig. 2 Schema of an instance of the RACE demo scenarios in the restaurant domain. The counter of Fig. 2 is the counter1 on the left. See text for more explanations. form as Hierarchical Task Network (HTN) methods, cf. Sec. 3.1 for more on planning in RACE. Trixi was able to physically perform such restaurant standard actions in closed-loop plan-based control from early on in the project, based on the control architecture explained later (Sec. 2.1). This state-of-the-art approach was taken as the ground level of performance compared to which competence could be enhanced from experience by methods to be developed in the project. Now what are reasons and opportunities for competence enhancement here? In a mundane domain like a restaurant, there is an infinite set of possibilities for variations of tasks to be executed in the light of actual conditions, even though the domain itself and the actions for a waiter (human or robot) to perform are highly schematized. These variations are the sources of possible disturbances for Trixi’s execution – actually, they are the sources of the brittleness of autonomous robot performance in real-world settings that is so often deplored. They would in general result in non-nominal execution of the planned behavior, or in needed variations of the planned behavior at execution time. For example, unknown at planning time, paths may be blocked for the robot, the guest may have changed his seat on the table, standard placing areas on the table may be occupied by belongings of the guest, standard manipulation areas for the robot to stand while serving the table may be blocked, a newly arriving guest may interrupt plan execution, and so on. Conditions on all levels of description of robot performance (temporal, spatial, causal, perceptional, kinematic, dynamic) may actually deviate from the standard – no matter how the standard is formulated in detail. The RACE idea is that actually experiencing such deviations and learning ways how to deal with them (cf. Sec. 3.4) should lead to more robust performance in the domain. Moreover, being able to conceptualize such experiences and thereby to generalize them and make them amenable to the robot’s