From The iroboapp Project
Jump to: navigation, search

What is COROS

COROS is a new architecture and a development framework that extends ROS to support multi-robots software development. COROS can be seen as an additional abstraction layer on top of ROS that provides primitives to software developers to easily design and implement multi-robot application.

COROS Reference

For more details about COROS architecture, please refer to the following book chapter Anis Koubaa, Mohamed-Foued Sriti, Hachemi Bennaceur, Adel Ammar, Yasir Javed, Maram Alajlan, Nada Al-Elaiwi, Mohamed Tounsi, and Elhadi Shakshuki
COROS: A Multi-Agent Software Architecture for Cooperative and Autonomous Service Robots
Cooperative Robots and Sensor Networks (2015 Edition)
Springer, Studies in Computational Intelligence Series, 2015.

COROS Architecture

The COROS architecture is based on the concept of multi- agent, where an agent represents an independent entity, typi- cally a robot machine (i.e. Robot Agent) or a monitoring or control workstation (i.e. Monitor Agent).

COROS Layers

COROS consists of five layers illustrated in Figure 1.

Coros arch.png

Figure 2 shows the component diagram of the software architecture.

Main component v4.png

The software system is decomposed into five subsystems (or layers), each of which plays the role of a container of a set of components. These subsystems are:

  • Communication Layer: this subsystem was designed to address the communication layer requirement, as it ensures the inter-robot interaction between different agents. It comprises extensible and modular client and server components that enable agents to exchange serialized messages through the network interface using sockets.
  • ROS Interaction Layer: this subsystem adds a lightweight layer on top of ROS allowing a seamless inter-process interaction between ROS nodes (processes) defined in the architecture. The main role of this layer is to provide a simple and efficient way to manage the subscribers and the publishers to ROS topics and services. Any node can publish or subscribe to a new topic using both components PublishingManager and SubscriptionManager without having to directly interact with ROS.
  • Robot Control Layer: this subsystem also adds a second layer on top of ROS providing a bridge between the local software agents and the physical robots. The role of this layer is to manage the robot configuration and its state. The Robot Controller component provides an abstraction model for any ROS-enabled robot. This component provides several interfaces for controlling and monitoring robots states such as location, published and subscribed topics, provided and used services, etc. This enables to make easier to management of hetero- geneous robots as they adhere to a common component model. Any robot type can be easily configured to provide the interfaces provided by the robot controller components.
  • Application Logic Support Layer: this subsystem addresses the problem solving requirements; it encap- sulates all of the components needed to implement a complete multi-robot application. Any new application should reuse and configure the software components to define its proper behaviour. The Agent Operator is the main component of the Application Logic subsystem as it implements the actual behaviour of the applications. This means that every type of received message (through Agent Server Component) triggers the execution of an appropriate function as specified by the application. The Agent Operator uses the Communication subsystem to exchange information with other robotic agents in the environment.
  • Knowledge Base Manipulation Layer: This subsystem aims at satisfying knowledge base requirements and maintain an up-to-date information about the robot status and its environment. Usually, the majority of gathered information becomes obsolete from an execution to another. Based on its unique component State Moni- toring, this subsystem provides to others with a useful information and services such as allowing the agent to monitor and control its local state, other agents’ states, the state of the different tasks, and the information about the agent initial configuration.


Use Case1: Discovery Application

A first use case to illustrate COROS benefits is a discovery application that allows robots to discover their neighborhood, using the COROS architectural concepts. The reason behind implementing the discovery protocol is because it is needed by typical distributed robotic applications, since a robot ba- sically needs to have information about its neighbors to be able cooperate with them in accomplishing missions. We build the discovery protocol as an independent ROS software component that can be used by any other ROS application. The figure below presents the class diagram of the discovery application using the COROS architecture.


Use Case2: Courier Delivery Application

The second use case is courier delivery application that involves cooperation between a team of robots and to demon- strate how COROS architecture is effective in building such distributed applications. The scenario consists in a user sending a command to a team of robots for courrier delivery from one office to another. Using a market-based approach, the robot will coordinate to select one winner for executing the mission. We have deployed this application in the Computer Science department at Prince Sultan University.
The figure 4 below depicts the class diagram of the courier application.

Courier class.png

A demonstration is available in the following video