In most autonomous robot approaches, the individual robot's goals and cooperation behavior are fixed during the design. Moreover, the robot's design may limit its ability to perform other than initially planned tasks. This leaves little room for novel dynamic cooperation where new (joint) actions could be formed or goals adjusted after deployment. In this paper, we address how situational context augmented with peer modeling can foster cooperation opportunity identification and cooperation planning. As a practical contribution, we introduce our new software architecture that enables developing, training, testing, and deploying dynamic cooperation solutions for diverse autonomous robots. The presented architecture operates in three diferent worlds: in the Real World with real robots, in the 3D Virtual World by emulating the real environments and robots, and in an abstract 2D Block World that fosters developing and studying large-scale cooperation scenarios. Feedback loops among these three worlds bring data from one world to another and provide valuable information to improve cooperation solutions.
robot development framework where diferent nodes, or of the environment and the robot should find itself in. programs, communicate asynchronously by subscribing A goal can be, e.g., to keep a room clean or deliver a and publishing to topics shared over a network. A single package to a specific place. A robot may have multiple ROS node acts as the server, or master, to which other or even conflicting goals.
ROS-enabled devices can be connected to as clients, form- To achieve its goals (either by itself or in cooperation), ing the network. Being a leading open-source project in robot forms plans which consist of tasks. A plan describes robotics, ROS has an active development community, and how a certain goal is achieved, i.e., which tasks should be a diferent, newer version, ROS2, is also seeing increasing done and their (partial) order. To make a plan concrete, amounts of use and development. In this work, we use each task needs to be assigned to a robot (or a set of ROS2 in our implementation. robots). This concrete plan is called a workflow .
Our approach aims to support ad hoc encounters of het- Tasks are the individual elements from which plans and
erogeneous autonomous robots, which each have their workflows are composed of. Each task includes individual
own individual goals, which can be used to define vari- objects to be achieved, e.g., open a particular door, move
ous plans that include diferent types of tasks. Typically, to a specific place, etc. Tasks can be hierarchically nested
the cooperation tasks can be categorized into loosely in two ways. First, there can be general tasks (open a
and tightly coupled cooperation tasks [
The proposed software architecture enables coopera- Tasks have defined start and end conditions.
Howtion in both tightly coupled and loosely coupled tasks ever, the actions (see below) can be partly responsible for
mainly through peer modeling, which has been argued checking these conditions. The start condition is checked
to be a requirement for cooperation [
The rest of this paper is structured as follows. In Sec- (sets of) actions that achieve the same task, and an action tion 2, we introduce concepts related to our architecture. may be utilized in multiple tasks. Where goals, plans, In Section 3, we describe our solution – a software archi- workflows, and tasks are platform-independent, actions tecture that enables the developing, training, and testing should be implemented on each platform (and the world) cooperation of autonomous robots. In Section 4, we ex- separately. plain the current status of the architecture and what kind To allow cooperation, robots communicate their goals, of experiments are currently possible with the architec- suggested workflows, and tasks to develop workflows, ture. In Section 5, we cover work related to our approach. including multiple robots. To make this communication In Section 6, we discuss how we plan to improve the so- more fluent, robots maintain a model of themselves and lution in the future and what we are currently focusing each of their peers. In general, these models may hold on implementing. Finally, in Section 7, we draw some any important information of the robot in question, such conclusions for this work. as their physical properties, capabilities, i.e., which tasks they can perform, the robot’s goals, and the history of the workflows they have been included in and their success.
ontological concepts we use to enable cooperation. The basic concepts introduced here are part of DUL ontology, but we extend them in our work to provide concrete solutions and a more fine-grained understanding of the situation at hand.
The robots’ essential operation revolves around goals describing desirable situations, which we model as states
The architecture, with its components and the leveraged services, is depicted in Figure 1. The architecture can
Robot A
Planner Goal Model Workflow Model
Cooperative Brain Service Self Configu ration Model
Peer Models
Situational Context
Model Scheduler
Knowledge Manager
Environment
Model Task Runtime
Task Model - Start condition - End condition (implicit goal) - Resource estimate
Workflow History Model
Task Hierarchy Models
Task to Action Mapping
Model
Action - Block, virtual, and real world - Platform dependent (e.g., ROS service)
Sense Analysis Service A Actuate Service A Service B
Coop Communication Service - LFCiIbPorAaorCyposmpMemceuifnsiciscaataitoigvneeAct - LFCiIbPorAaorCyposmpMemceuifnsiciscaataitoigvneeAct - LFCiIbPorAaorCyposmpMemceuifnsiciscaataitoigvneeAct Legend
Runtime environment: World - 2D Block World - 3D Virtual World - Real World
Component are estimated in collaboration with Scheduler and Task and currently opening. However, to keep the "backward Runtime components. functionality" intact from Real World back to 2D Block
However, the most crucial responsibility of the ser- World, individual object states and actions that manipuvice is to estimate whether it will meet its own goals. late them in Real World model should be mappable into It constantly keeps track of its resources and what re- the 2D Block World model. sources other robots have allocated for helping it to meet Self Model and Peer Models contain information its goals. Hence, it leverages Knowledge Manager and about the robot itself and its peers. In general, each peer Task Runtime components by observing changes in the has its model, but aggregate models, e.g., considering cermodels that represent the other robots and environment, tain classes of robots, are possible. Robots exchange basic and then notifies the Planner which can alter its work- information considering themselves (drawn from their lfow and tasks (e.g., by replanning tasks with missing Self Model and other knowledge sources) when they first resources or reorganizing tasks in its workflow). meet their peers and update and replace this information through communication and observations. Where 3.2. Knowledge Manager Situational Context Model ofers current information of the state of the world, and Environment Model ofers an Knowledge Manager takes care of maintaining the robot’s understanding of how the world works, these models understanding of the world and the information associ- provide knowledge of what are each robot’s goals, which ated with the cooperation. The main input source for the tasks are possible for the robot, and what restrictions component is the robot’s (platform-dependent) service the robot may have for performing specific tasks, e.g., if components that the robot uses for observing and sens- the robot can only open specific types of doors. From ing. Knowledge Manager may also exchange information the cooperation perspective, these models are highly relwith other robots’ Knowledge Manager components via evant, as their information is needed in Planner when respective Cooperative Brain Services with Coop Messages. determining whether who can perform a particular Task. Knowledge Manager maintains the following models that Task to Action Mapping Models contains knowlenable novel and valuable cooperation as well as robot’s edge about mapping the task realizations to actions. This individual goal-oriented behavior: knowledge is mainly about the robot’s tasks, but peers’
Situational Context Model captures information tasks to action mapping information can also be partially considering the robot’s current situation, e.g., where it stored. This applies especially to cases if the robots are and other robots currently are, what is the state of the en- of the same type. Additionally, other peers may provide vironment objects near it, and other dynamic properties. some information about their action mapping for a parThe model’s contents can be updated using feedback from ticular task, e.g., resource estimates, timing information, sensors, Environment Model (e.g., by making queries of or constraints that can be used in planning. possible state changes in the physical objects represented Workflow History Model contains the information in the ontology if they are not directly perceived), Self on earlier cooperation situations, such as performed task and Peer Models, and direct communication with other hierarchies, their configurations, and execution results. actors, such as robots, through Coop Messages. To this ex- The information is used for improving the quality of the tent, Situational Context Model operates in tandem with cooperation by analyzing which workflows and roles the environment and peer models to provide a unified have previously worked well and which ones have failed. view of the most current understanding of the situation. Task Hierarchy Models are used as configuration This model can be used directly in Planner, whereas other models for creating task hierarchies (consisting of taskmodels provide more fractured view of the situation. goal-plan nodes), e.g., options for decomposing tasks or
Environment Model connects actions in the operat- goals and constraints for valid hierarchy configurations. ing environment, e.g., moving or object manipulation, It can be used to determine whether a particular task into state changes in ontological objects. The model hierarchy configuration is valid, and the hierarchies can, should represent the environment and its objects in sufi- then, be used by Planner or other components in Knowlcient detail so that it can be used to derive reasonable Situ- edge Manager, e.g., to represent aggregated high-level ational Context Model and reason about possible changes capabilities of the peers. of certain actions in particular situations. It can be updated using feedback from the environment (either per- 3.3. Planner ceived or received through communication). The level of detail in Environment Model varies across the diferent Planner is responsible for constructing Workflows which world types. In 2D Block World, the model is suficient are then, e.g., passed to Scheduler for execution or stored to possess simple logical states, e.g., is the door open or for later use. As input, Planner is given some starting closed, while in Virtual and Real World the model may situation, e.g. the current Situational Context, a desired be more elaborate, e.g., a door can be partially closed end condition, e.g. the current Goal, and other related parameters, e.g. restrictions for the workflow. Planner perform a task Guide. Such task then consists of other leverages the information maintained by Knowledge Man- tasks, like Move, Turn, Navigate, etc. ager in its attempts to select the robot and its peers to Action is the mapping from the behavior modeled specific roles and to assign them Tasks. For actually as- with tasks to the actual implementation of a specific task. signing Tasks for its peer robots, Planner negotiates with Actions are generally platform-specific, but there can be diferent robots’ Planner components. The purpose is alternative versions of actions for diferent robots even to ensure that the robot has a correct understanding of within the same platform. Similar to the tasks, also acits peer’s capabilities (i.e., Tasks it can perform) and that tions can consist of other sub-level actions. For instance, the peer has suficient resources, e.g., time and battery conforming Action: Guide may leverage various other power, to participate in the workflow. action implementations.
Goal Model defines a single mission that is expected to be carried out by a single robot or a set of robots. 3.5. Robot’s Services However, it does not define how the actual plan and the mission is expected to be performed. Instead, a Goal For actuating and sensing the events coming from the Model can set some ground rules for the robot behavior, world, the architecture enables leveraging various serlike time constraints or quality attributes. A Goal Model vices and communication between them. In Figure 1, is used for deriving start and end conditions for specific such services have been illustrated: an imaginary actuattasks. It may also afect what types of robots get selected ing Service A is used, for example controlling the robot, into the roles of the cooperation. and at the same time, it sends data to Analysis Service A.
Workflow Model consists of a Goal Model and a par- While we have mainly used ROS2 based services in our tially ordered list of Task Models where each task is as- current implementation, the Cooperation Brain is not signed to a (set of) robots. By default, Planner tries to put tied to any specific robot technology. Hence the services together a Workflow Model where the robot itself is in the may also be realized as ROS1 services or any other type of primary role, and its peers are assigned only if the robot service technology (e.g., as a Docker-based microservice). cannot meet the Goal. However, the Goal Model can affect how the workflow is put together: As the Goal Model 3.6. Scheduler contains information regarding a single robot’s mission, it can then define the mission to be highly cooperative or act as a leader. For example, consider that one robot is expected to act as a supervisor for the other robots – its mission is then defined to coordinate the others and their cooperation.
Scheduler component is part of the Task Runtime component. Scheduler fetches the Tasks from the Planner components Workflow and delivers the runnable Tasks to the Task Runtime. Scheduler’s primary duty is to maintain a Task list for execution in the robot, considering priorities and constraints of active goals. For this purpose, the Scheduler uses each task’s start and end conditions to 3.4. Task Runtime ensure that the situation is correct for running the task. Diferent types of robots can feature very difering un- The Scheduler also uses the resource estimates to ensure derlying platforms for development and interfacing in that the robot has the promised resources for performing general. Therefore, the platform is essentially what dic- the task. tates how actions have to be implemented. The Task Runtime is accordingly designed so that support for new 3.7. Coop Communication Service platforms can be added at will, in the form of platform modules. Currently supported platforms are the older and In order to cooperate efectively in varying situations and newer versions of the Robot Operating System, ROS1 and environments, the robots require a communication platROS2, introduced in more detail later. However, as a par- form that can relay messages between the components ticular measure stemming from the similarity of these deployed on various nodes. The base technology for interplatforms, actions are shared between both by abstracting robot communication is Socket.IO. It provides a relatively implementation diferences of subscribers and publishers reliable and fast enough communication channel for neusing the respective platform modules. gotiating about the cooperation-related activities, like
Task. The self-adaptive aspects of the architecture tasks and roles in workflows, and providing feedback. come into play when the autonomous operation or coop- In our present research, we mainly leverage ROS2eration requires certain resources. Each robot describes based robots. ROS2, on the other hand, leverages DDS its capabilities by communicating to others what kind of technology for communication between the ROS2 sertasks they can execute. A task may consist of sub-level vices. Hence, in the future, our implementation may tasks, that is, a task may group other tasks into a higher- change using DDS also for the cooperation communilevel behavior. As an example, consider that a robot can cation to make the architecture more streamlined. The downside, however, is that setting up a DDS-based com- There are also a number of other robots with diferent munication infrastructure can be challenging for robots capabilities executing their tasks, such as cleaning the that lack the required resources, and as there are sev- place, who have appropriate knowledge related to their eral diferent DDS implementations, incompatibility is- responsibilities, such as the layout of the cleaning areas. sues may emerge and issues with licensing. For this As their responsibilities, e.g., cleaning, may leave time reason, the implementation yet relies on our service and for other tasks, they can help the delivery robot. Socket.IO technology. Additionally, to support also non- While the above scenario seems very simple, there are ROS2 based robots, we have been discussing implement- almost unlimited possibilities to advance creative cooping a communication bridge that would allow ROS and eration. The scenario requires the robots to a) become other types of robots and smart objects and resources (e.g., aware of each other skills, objectives, and knowledge; b) sensors, existing facility service systems, smart home be able to define their joint problem: delivering the packsystems, etc.) in the environments to participate and age; and c) together form and execute good enough plans enhance the cooperation. for solving the joint problem. Hence, despite the limited
Coop Message is the base unit of the communication domain, we believe that the above scenario can serve as in the CACDAR architecture. Two other base message a basis for numerous other cooperation applications for types – BroadcastMessage and Direct Message – are in- diverse autonomous robots. herited from the base, and the idea is that the communication language is extended by inheriting new subtypes. 4.2. Introducing ROS and Real-World The only requirement is that each message has a sender.
The actual communication messages are based on FIPA Robots
Communicative Act Library Specification [
Broadcast Messages are sent publicly to all robots and focused on physical robots of the Real World. We had services connected to the Coop Communication Service. an already available supply of small-sized research use Typical use cases for these messages are when a new robots, and with Real World being the most intricate of robot arrives at a specific venue and then gets connected the three-world approach, it was deemed beneficial to get to the Coop Communication Service located at this venue. familiar with the particularities of physical robot develThe robot may then greet the other connected ones by opment from early on. The robots chosen for these early broadcasting its name and the tasks it considers capable implementation eforts were Rosbot 2.0 and TurtleBot3, of performing. The robot may also request help from both which used Robot Operating System, ROS, as their other robots by trying to describe its goal to other robots. development platform. As ROS was to become the first
Direct messages, on the other hand, are sent directly platform the Task Runtime would support, familiarizing from one robot to a set of recipients. These messages ourselves with it was necessary to get started. are mainly used for negotiating a cooperation plan and Being small, economical robots for education and recommunicating during the execution of the plan. search use, Rosbot 2.0 and TurtleBot3 were at the time equipped simply with wheels for movement and LIDARs 4. Current Status for scanning surroundings, with the Rosbot 2.0 also featuring a camera. The fundamental premises of the project In this section, we present the current implementation also meant further restrictions: we could not have the status of the architecture. We start by describing an exam- robots share any common understanding of the world, ple use case and then continue presenting some proof of not a common map or even coordinate system. Inspired concept implementations for the use case. Additionally, by these limitations, the very first mutually coordinated we report our experiences so far about the three-world Action made was that of Rosbot 2.0 following Turtlebot3 approach and its benefits. with the help of QR codes. Due to both robots using ROS, the development of Task Runtime began ROS support first, but care was taken in making it possible to add 4.1. Example Use Case: Package Delivery support for other robot platforms also. Throughout our implementation work and experiments, The QR code method is straightforward in principle: we have used the following as a base use case and sce- A QR code stand is propped up on the Turtlebot3. When nario which has been adjusted and changed to diferent Rosbot 2.0 sees the QR code on Turtlebot with its camera, environments and worlds in our three-world approach: it tries to move itself so that the QR code is centered on A delivery robot with a heavy package, e.g., a tool rented the image at a direct angle and a certain distance. The online, comes to a construction site previously unknown movement direction is based on distance, derived by comto it. It has a goal: deliver the tool to a specific location. paring the QR’s width in the image to a predetermined expected width, and rotation, derived from the homography matrix between the image and the QR code within due to major design diferences between the two, but it. we deemed it worthwhile for a number of reasons: ROS1
However, this method alone does not make for an uses a client/server architecture, where all machines have adequate following logic. When the guide, Turtlebot3, to be registered on the server machine. ROS2 is instead moves, it is easy for the follower, Rosbot 2.0, to lose sight an entirely peer-to-peer solution based on the DDS midof the QR code. As a solution, we implemented a com- dleware, which would quite intuitively appear a better munication protocol specific to this Follow action: If fit for cooperation of autonomous robots. Our project the guide goes out of view, the follower asks the guide to was also at an early stage at the time, and ROS2 exhibited stop. The follower then moves to where it last saw the more promising prospects for the future. In contrast to guide, and begins a search process that uses rotation data ROS, which was designed back in 2010 for research and exchanged between the follower and the guide. This ap- educational purposes, improvements in aspects such as proach utilizes the fact that we can calibrate and compare real-time programming claim to bring ROS2 closer to the rotations of the robots, even when the coordinates applicability even for industry use. For us, this heavily cannot be shared (as both have their own map). As an implied that any interesting future developments would additional measure, QR codes are added on all sides of most likely focus on ROS2. Therefore, we are now using the guide. If the follower sees a code other than the one the newly released stable release of ROS2, Foxy Fitzroy, behind the guide, the guide will attempt to rotate so that as the platform for Turtlebots and Gazebo simulation. the follower is lined right behind the guide again. The support for ROS2 on Rosbot 2.0 has been more lim
As a result, the Follow and Guide actions were cre- ited so far, so have instead kept it at ROS1 to demonstrate ated successfully on the physical robots alone. Yet, many how the Task Runtime is made to support both ROS1 and realities of the Real World hampering robot development ROS2. became apparent: Lighting conditions would afect the detection of QR codes greatly, even the slightest of obsta- 4.4. Bring Cooperation from Real World cles such as cables were insurmountable for the TurtleBot3, and having to reset the positions of the robots to 3D Virtual World manually every attempt was also rather inconvenient in the long run. We also did not have the equipment or means for complicated feats such as having the robots to carry objects. To top it all of, the worsening COVID-19 situation meant that work would remain remote for the foreseeable future, so we started to look into the robot simulation environments next.
we chose Gazebo2 for our first simulation environment.
Gazebo’s close integration with ROS matches well with our work on real-world ROS robots up to that point, and it being the de facto standard for robot simulation on ROS also means that ample support is available from the open source community.
In many aspects, making the jump from Real World to Gazebo was quite straightforward. A model of Turtlebot3 was already available for Gazebo, and it controlled efectively the same as in the Real World. Case in point, the QR code following method implemented in Real World worked as-is in the simulated world too. What proved dificult instead was having multiple robots in the same Gazebo simulation. In a Real World environment, diferent robots can be assigned diferent domain IDs to avoid topic overlaps in messaging. In Gazebo, however, all simulated robots belong to the same domain by design, so so-called namespaces have to be used diferentiate the topics. Unfortunately, as namespaces are no longer the Figure 3: Rosbot 2.0 following a QR code-equipped Turtle- preferred solution like they were in ROS1, many ROS2 Bot3. components do not work very smoothly with them, resulting in some hack-like approaches required. Yet in the end, we have managed to get multiple Turtlebots 4.3. Migrating from ROS to ROS2 running in the simulation, each complete with their own namespace and navigation stack.
Before moving from the Real World to the 3D Virtual For all that, running multiple robots in Gazebo presents World, we also changed the primary development plat- us with a certain reality specific to the simulated world. form from the original ROS, also known as ROS1, to ROS2.
Switching to the newer platform was not entirely trivial 2http://gazebosim.org/
Increasing the number of robots simulated also increases do to provide similar functionality in 3D Virtual World or the processing power required quite significantly. So far, Real World for the physical objects. Sensing the states of we have been running Gazebo in a virtualized Ubuntu the objects, e.g. is the door open or closed, may become a 20.04 on work use laptops. Just with three robots present problem especially in Real World if the environment does in the simulation, the simulation runs at anything be- not provide any support for it. However, this is not a probtween 0.4–0.7 times of the ideal normal speed. Evidently lem that is unique to our approach as any autonomous this would indicate a need for a more powerful, possibly robot encounters similar hardships in understanding its distributed solution, which we are looking into. current situation.
Though it can now be said that robot simulation too certainly has its own set of challenges, getting the Gazebo setup working has been quite beneficial in the end. The 5. Related work simulation environment can be edited at will, and resetting the simulation is naturally much simpler. Although, In this section, we discuss on related research work on for reasons yet unclear, we are experiencing bugs with architectures enabling autonomous robot cooperation, both to much inconvenience. Particular to our scenario, leveraging ontologies for forming an understanding of the light conditions are no longer an issue when it comes the cooperation possibilities and situations, as well as to QR code detection, and item delivery actions can be task planning and decision making in the context of ausimulated simply by spawning and despawning items. tonomous robot cooperation.
Currently, Gazebo is our main platform for development, as seen with our newest demo.
In 2D Block World, we have currently implemented a stantly changing environments have been studied for
minimal extension to DUL with concepts related to coop- many years. The general interest in the overall topic
eration and planning, i.e. goals, plans, workflows, tasks has spawned several research subfields, e.g., swarm
and actions, accompanied by a few physical object imita- robotics [
Although the first simulations in 2D Block World seem coupled multi-robot cooperation. For example,
Chaimowpromising, it is still unclear how much work one needs to icz et al. [
While Chaimowicz et al. also use the transportation
of objects as an example, the same use case has been
studied many times during the years. Recently, Zhang et
al. [
Single robot planning may be approached from multiple perspectives. Two often used ones are heuristic shortest path search, such as the famous A* algorithm and its dynamic counterparts, and solutions used for logical optimization problems, e.g. (weighted) maximum satisfiability solvers. The shortest path search provides (estimates) for moving from one node to another in a graph and aims to find the path of nodes with the shortest length, and logical optimization aims to find a (maximal or minimal) set of clauses that satisfy certain conditions. Dynamic shortest path algorithms fit well in environments where the robot may not fully understand its situation, e.g., a complete map and logical optimization excels in cases where it is crucial to ensure the correctness of the solution beforehand.
However, our goal is to provide a planner that uses
both logical verifications of the workflows through the
fulfillment of each tasks’ start and end conditions and a
heuristic estimate of its execution resources through peer
models and communication. Our approach difers from
typical multi-robot task planning (see, e.g., Yan et al. [
robots understand the structures of the physical and
social world around them (see, e.g., Olivares-Alarcos
et al. [
Mainly due to the advent of IoT, ontologies prove to be an exciting starting point for robots to understand the world as a built environment is getting populated with intelligent devices capable of communicating with other computational actors. This means that, e.g., a door can be opened using software communication alone and does not have to rely on physical door manipulation, and that sensors and other IoT devices may send information of their physical composition, purpose, and capabilities
sights into the realities of cooperation in both real and simulated worlds. We have not yet faced any truly insurmountable issues, but many aspects make working with these environments not entirely straightforward.
In Real World, there are innumerable factors that can potentially afect the robots’ ability to perform, such as the lighting as mentioned above conditions and cables on the floor. Of course, for our project’s purposes, this would not seem a significant issue, as we can perform our tests in a carefully designed, controlled environment.3 However, this does not remove the fundamental issue of unexpected factors. How would this uncertainty be dealt with within a hypothetical practical environment? One possible approach would be introducing some degree of "self-healing" properties in the design, both in terms
ment in the university campus, but the ongoing COVID-19 situation means these plans are still postponed. of the robots’ performance and the cooperation context. Currently, extensive work on this aspect is beyond the scope of this project, however.
In contrast to the unpredictable Real World, the simulated 3D environments are inherently about control and thus easier to work with. Nevertheless, there can still be considerable efort to set up a simulation the desired way, as seen with the dificulties in simulating multiple robots simultaneously in Gazebo. It also became apparent that multi-robot simulation can involve substantial hardware requirements. Still, we have found the Gazebo 3D simulation fulfills its purpose satisfactorily as a platform where cooperative actions can be developed for Real World (ROS2) robots in a more controlled manner.
However, it could also be noted that while the usage of 3D simulation does simplify some aspects, designing Actions for the Task Runtime remains an endeavor that relies on detailed knowledge in leveraging a particular robot’s inner workings. Contrary to how the primary interests of this project are in the dynamic and creative aspects of robot cooperation, there remains a nontrivial efort necessary in creating the actual units of implementation, Actions. Future work could explore how to design the Actions more eficiently.
In this paper, we presented a new software architecture and development approach for diverse multi-robot cooperation. The core idea of the new approach is improving the situational context by developing and training peer models and an ontology that improves understanding of the world. The peer models enable the robots to take their peers’ capabilities and goals into account in their reasoning, and the ontology can be used as a shared basis for communication and forming cooperation plans. The presented work is yet in its early stage, but we have already provided encouraging results and will continue the work.