Preprint version • Final version available at http://ieeexplore.ieee.org • DOI: 10.1109/Humanoids.2011.6100883 Towards an open-source social middleware for humanoid robots Miguel Sarabia, Raquel Ros, Yiannis Demiris Department of Electrical and Electronic Engineering Imperial College London, UK Email: fmiguel.sarabia, raquel.ros, [email protected] Abstract—Recent examples of robotics middleware including teristics of the framework. Finally we show two preliminary YARP, ROS, and NaoQi, have greatly enhanced the standardisa- examples of the framework being used to recognise dance tion, interoperability and rapid development of robotics applica- steps with the Nao robot and the iCub simulator. tion software. In this paper, we present our research towards an open source middleware to support the development of social II. HAMMER MIDDLEWARE DESIGN GOALS robotic applications. In the core of the ability of a robot to interact socially are algorithms to perceive the actions and inten- Here we delineate the design goals that we set out to fulfil tions of a human user. We attempt to provide a computational when coding the framework. layer to standardise these algorithms utilising a bioinspired a) Generic: We have strived not to make any assumption computational architecture known as HAMMER (Hierarchical Attentive Multiple Models for Execution and Recognition) and on the final usage of the middleware . The middleware is very demonstrate the deployment of such layer on two different flexible and its operation can be fine-tuned. humanoid platforms, the Nao and iCub robots. We use a dance b) Adaptable: Right from the start HAMMER was con- interaction scenario to demonstrate the utility of the framework. ceived to work with other popular environments within the robotics community. This is what influenced our choice of pro- gramming language, C++, as it seems to be the community’s I. INTRODUCTION language of choice. Because HAMMER may be needed to It has been stated that the new generation of robots will work in a variety of environments it has only one dependency, be human centred [1] as opposed to robots currently used the Boost libraries. in factories which mechanically repeat what they have been c) Interoperable: This is closely related to the previous programmed to do. One of the main remaining obstacles lying goal. As our framework is adaptable it could easily inter- in the way of human centred robotics is that of understanding operate with other robotic middlewares such as ROS [7], the intentions and abilities of the user [2]. This understanding Player [8], YARP [9], Urbi, NaoQi, OpenNI, CARMEN [10], is fundamental for a social robot in order to react and respond DAC [11] and knowledge databases like the one proposed in accordingly to a human user. the RoboEarth project [12]. For a survey on the merits and However, despite a wealth of very useful middleware for challenges of robotic middlewares refer to [13]. HAMMER the control and development of a basic skill set of humanoid could also work with robot hardware abstractions layers, such robots, to the best of our knowledge there is not any equivalent as the one created for the CHRIS project [14]; nevertheless, middleware for the social aspect of the humanoid robot abil- it does not have to use any such abstraction if not needed. ities. In this paper we present a middleware that will provide Briefly, it is fundamental that HAMMER can be integrated a fast starting point for anyone that requires a robot that with any robotic framework without any major issues. recognises the abilities and intentions of its users. Throughout d) Ease-of-use: When it did not conflict with the need this paper our focus will be in humanoid robots, although there for generality we aimed to make the middleware as simple is no reason why the library could not be used for other types as possible to use. For example, this is our motivation behind of robots. the pervasive use of shared pointers which deallocate memory The main aim of the middleware is to allow flexible automatically without any user intervention. Every attempt deployment, employing hierarchies of inverse-forward model was made to keep the middleware consistent. As such, once pairs (described in section III-A). HAMMER [3] has been the basic mindset of HAMMER has been learnt, using the successfully used in many different contexts; for example, framework should prove a simple task. to recognise and imitate a human moving an object between e) Multi-threaded: From the very beginning HAMMER two tables [4], to recognise compound and single actions of was meant to be a concurrent system where all the inverse- multiple robots [5] and to predict the intention of opponents forward pairs ran in parallel. The middleware provides support in a real-time strategy game [6]. for this without any user mediation, all registered inverse This paper is organised as follows. We start by presenting models are executed concurrently, unless there is a hierarchical the design goals of the middleware. Next we introduce a brief dependency between them (cf. section III-C). In any case, overview of the HAMMER architecture and the main charac- users must be careful about the use of shared structures in Preprint version • Final version available at http://ieeexplore.ieee.org • DOI: 10.1109/Humanoids.2011.6100883 inverse and forward models as HAMMER only protects its own structures. Consequently any shared variable between different models should be adequately insulated, lest it be accessed or written by two threads at the same time. f) Open: The HAMMER social middleware is open source and publicly available. III. HAMMER MIDDLEWARE IMPLEMENTATION In this section we describe the theory behind the HAMMER middleware and its main features. Figure 2 shows how the HAMMER middleware fits in with the rest of the robotics ecosystem. A. Underlying theoretical structures The field of cognitive robotics was drastically changed with Fig. 1. Diagrammatic representation of HAMMER. Each pair of inverse and forward model represents a hypothesis about the next state, which is then the discovery of the mirror neuron system in primates (for evaluated against the actual state to generate a confidence value. an overview see [15]).The primate mirror neuron system is hypothesised to use the same structures for executing actions as well as recognising them when executed by others. Sub- sequently theories were developed stating that humans use internal inverse and forward models for motor control [16]. HAMMER is inspired by both these concepts. An inverse model is a function which takes the state of the world as input, and an optional explicit target state. It outputs the action signals to reach the target state, which could be implicitly hard coded in the model or explicitly passed as an input parameter. A forward model is defined as a function that takes an action signal and outputs the predicted state of the world after the signal has been executed. The term forward model has been used in the literature to represent many different concepts. For us it is an output predictor, following the analysis in [17]. Pairing together an inverse model and a forward model, Fig. 2. Data-flow between HAMMER, other major robotics components and we obtain a system that generates a hypothesis about the next the user application. Dashed connections refer to forthcoming features of the middleware. state of the world. By combining several inverse-forward pairs, which are normally run in parallel, numerous hypotheses are proposed. These hypotheses are compared against the actual from the observations of a demonstrator the robot can place state of the world at the next time-step. A confidence value itself on the “demonstrator’s shoes” [2]–[4]. is computed for every inverse-forward pair, representing the HAMMER is also able to distribute the robot resources, or confidence on that inverse-forward pair being the behaviour attention, according to the needs of the inverse-forward pairs that is being currently executed. By repeating this process it- by making the saliency of their resource requests a function of eratively, confidences for different behaviours can be observed their confidence. However, this issue goes beyond the scope over time. This is HAMMER’s basic mode of operation, as of this paper and we will not explore it further. The reader is shown in figure 1. referred to [2], [3] for a description of this functionality. Until now we have used ‘state’ in a loose manner. ‘State’ is a set of variables both external (environmental) and internal B. Framework Description (proprioceptive) to the robot. From now on, we will refer to these variables as aspects to differentiate from other code vari- In order to create a HAMMER-based architecture the fol- ables. Aspects contain all the information needed to recognise lowing components need to be specified. and execute the behaviour contained in an inverse-forward pair. • State of the world, for every time step. ‘State’ can represent the actual state of the world around the • Inverse Models robot, or the state around a demonstrator. If we take the latter • Forward Models approach, the robot can effectively recognise the actions of • Action Signals, which will be used to send commands a demonstrator, as long as it has the inverse-forward pairs to between the inverse and the forward models represent that action. In other words, by generating the state • Confidence Evaluation Function Preprint version • Final version available at http://ieeexplore.ieee.org • DOI: 10.1109/Humanoids.2011.6100883 //Bring HAMMER structures into scope The HAMMER middleware provides structures to aid in the using namespace HAMMER; design of the above components, while at the same time Signals::KPtr inverseModelFunction( making as few assumptions as possible about the intended const State::KPtr& current, const State::KPtr& target){ //Read data from state and target end application of the architecture.