From COINS Research Group
Jump to: navigation, search



Project Info

  • Principal Investigator: Anis Koubaa
  • Duration: 1 year
  • Funding Agency: King Abdul-Aziz City for Science and Technology

Work packages

  • WP 1. Conceptual Design of the MyBot Robot Model
  • WP2. Software Engineering of MyBot
  • WP 3. Implementation and Development
  • WP 4. Experimentation, testing and validation of MyBot


This report presents the design of an assistive mobile robot to support people in their everyday activities in office and home environments. The contribution of this project consists in the design of a modular component-based software architecture that provides different abstraction layers on top of Robot Operating System (ROS) to make easier the design and development of service robots with ROS. The first abstraction layer is the COROS framework composed of complementary software sub-systems providing different interfaces between ROS and the client applications. The second abstraction layer is the integration of Web services into ROS to allow client applications to seamlessly and transparently interact with the robot while hiding all implementation details. The proposed software architecture was validated through a experimental prototype of Turtlebot deployed in University campus. Furthermore, we outline the challenges incurred during experimentation and focus on lessons learned throughout the implementation and deployment.

Video 1: Courier Delivery Demonstrator


We designed a software architecture that provides two abstraction layers on top of ROS to make easier the development of distributed applications for service robots. It includes two major layers, namely:

  • COROS architecture: which is a component-based software architecture that provides a first abstraction layer on top of ROS composed of modular components to develop cooperative and distributed applications, In particular, we design ROS to JSON interfaces that allows more flexible machine-to-machine communication between heterogeneous end-devices considering the platform independence properties of the JSON. ROS messages are converted from and to JSON format.
  • Web Services interfaces: ROS Web services is the second abstraction layer that allow client applications to seamlessly and transparently interact with the robot while hiding all implementation details. Services are made public to client applications, which can be invoked by a Web Service client.

The advantage of our architecture is that it decouples networking, from application logic , and robot control. Each component can be defined and implemented independently of others and can be reused as appropriate in different complex applications.
In what follows, we present the main features of these contributions.


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.
The COROS architecture is based on the concept of multi-agent, where an agent represents an independent entity, typically a robot machine (i.e. Robot Agent) or a monitoring or control workstation (i.e. Monitor Agent).
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.

ROS Web Services


ROS As A Service (RoAAS) was designed to make an abstraction of ROS resources, including topics, services and actions for developers who do not have prior background on robots or on ROS. We retain three major advantages behind exposing ROS as a service following an SOA approach:

  • Promote public use of robots: First, non-roboticians programmers will be able to develop applications that communicate with ROS-enabled robots through a service layer. Web services are a possible instance of the service layer that can be used as a mediator between client applications and the ROS ecoystem. In addition users will have the capability of directly interacting with robots through the Internet, and this will enlarge the community of users and applications’ developers.
  • Robot-Cloud integration: A second advantage is the integration of the robots into the cloud as the robot can expose its resources as services through the cloud that allows users to virtually access these resources to per- form some actions. For example, in case of surveillance applications, an end-user may want to send a set of UAVs for a mission and control their missions remotely through the cloud. The internal status of the UAVs and their observations will be provided as services to the end-user by the cloud back-end.
  • Standard and unified interfaces: it will be possible to develop unified and standard client applications that seamlessly interact with heterogeneous robots provided that they share the same service-oriented interfaces, in- dependently of the implementation details.

Figure 9 depicts the deployment diagram of ROS Web services and illustrates the integration of the Web services’ layers into the ROS-enabled service robot and the client device.


Video 2: Tutorial on ROS Web Services



  • Anis Koubâa (Editor), Robot Operating System – The Complete Reference, in the series Studies in Systems, Decision and Control, Springer International Publishing, 2015 (under press – contains 28 chapters, first Springer book on ROS).


  • Anis Koubâa, ROS As a Service: Web Services for Robot Operating System,in Journal of Software Engineering for Robotics (JOSER_, Dec 2015.
  • Anis Koubaa, Mohamed-Foued Sriti, Yasir Javed, Maram Alajlan, Basit Qureshi, Fatma Ellouze, Abdelrahman Mahmoud, A Service-Oriented Software Architecture for Personal Assistant Robots using ROS, to be submitted to Springer Journal on Intelligent Service Robotics, (Impact Factor in 2014: 0.658)
  • أنيس قوبعة: تصميم روبت شخصي مساعد لتطبيقات الأتمتة المنزلية والمكتبية،


Book Chapters

  • Anis Koubâa, Mohamed-Foued Sriti, Hachemi Bennaceur, Adel Ammar, Yasir Javed, Maram Alajlan, Nada Al-Elaiwi, Mohamed Tounsi, Elhadi Shakshuki, “COROS: A Multi-Agent Software Architecture for Cooperative and Autonomous Service Robots” Cooperative Robots and Sensor Networks 2015, Studies in Computational Intelligence Volume 604, 2015, pp 3-30.
  • Anis Koubâa, Fatma Ellouze, ROS Web Services a Tutorial, to appear in the Robot Operating System (ROS), The Complete Reference, Springer, in the series Studies in Systems, Decision and Control, Springer International Publishing, 2015.

Conference Papers

  • Anis Koubaa, Mohamed-Foued Sriti, Yasir Javed, Maram Alajlan, Basit Qureshi, Fatma Ellouze, Abdelrahman Mahmoud, Turtlebot at Office: A Service-Oriented Software Architecture for Personal Assistant Robots using ROS, submitted IEEE International Conference on Robotics and Automation (ICRA 2016), Stockholm, Sweden, May 16-21.

Technical Report

  • Anis Koubaa, MYBOT: A PERSONAL ASSISTANT ROBOT, KACST Technical Report, June 15, 2015.