A Generic Guide for Using Membrane Computing in Robot Control

Introduction

The use of membrane computing in robot control has gained momentum since the introduction of membrane controllers in (Buiu, Vasile, & Arsene, 2012). New models of P systems amenable to robot control, such as enzymatic P systems, have been proposed. New applications have been approached, such as the control of collective robot systems, including swarms of robots. Furthermore, these approaches have been compared with conventional ones, such as finite-state machines, and some advantages and disadvantages of using membrane computing models in robot control, have been provided.

The aim of this chapter is to offer the curious robotics engineer or intrepid researcher interested in new ways to control robots a guide for selecting the proper membrane computing models and simulators, and what problems could they face in implementing these control models for real-life robots and applications.

This chapter will take the form of a set of guidelines organized along a number of important topics such as:

• •

  Abstraction level;

• •

  Robot complexity;

• •

  The level of interaction between robots;

• •

  Task complexity;

• •

  The type of execution environment, simulated or real-world;

• •

  The level of parallelism.

The majority of the issues are presented in a comparative manner and represent separate concerns (a software engineering principle introduced in (Ghezzi, Jazayeri, & Mandrioli, 2002)). These separate concerns are important in that a developer should take each one into account when intending to use membrane computing models for robot control.

The following discussion is generic in the sense that it is not centered around a particular scenario but rather tries to accommodate a membrane computing robot controller to different structural and functional requirements.

Abstraction Level

The first fact that must be considered when designing a robot controller is the target level of control or in other words, where will the controller be placed in the control application. This control level is proportional to the abstraction level in the sense that a high level decision application (path planner, role assignment, …) uses only abstract elements as opposed to an embedded device controller (driver) that uses mainly numerical values in order to interface with the hardware. Several example programs are presented graphically in Figure 1.

Figure 1.

Example programs and their corresponding abstraction level

This type of stacked architecture is often used for operating systems where hardware devices (CPU, memory, …) reside at the bottom of the stack, followed by the operating system kernel. A set of system libraries follow immediately above and the interaction with the kernel is done using an Application Binary Interface (ABI) while the calls to the system library methods are made by user applications, found at the top level, through an Application Programming Interface (API) (Stallings, 2011). For both robot controllers and operating systems, the information flow is bidirectional and generally does not step over any level. Exceptions such as device drivers can be encountered both as part of operating systems but also robot controllers.

Depending on the requirements of the target application, the envisioned controller can be integrated into existing robotics pseudo-operating systems. These software packages are not real operating systems, in the sense of handling memory, CPU, process scheduling, but are actually Robotic Software Frameworks (RSF) that provide hardware abstraction for devices commonly found on robots and in some cases also include specialized algorithms. A detailed review and comparison of the most influential RSFs that are also suitable for multi-agent applications is presented in (Iñigo-Blasco, Diaz-del-Rio, Romero-Ternero, Cagigas-Muñiz, & Vicente-Diaz, 2012).