A Framework based on concurrent Object-oriented programming for Building Behavior-based Control Systems for Mobile Robots

A Framework based on concurrent Object-oriented programming for Building Behavior-based Control Systems for Mobile Robots

José Eduardo Mendonça Xavier

Escola Técnica Federal do Espirito Santo

Av. Vitória, 1729 - 29040-333 Vitória-ES

[e-mail]

Hansjörg Andreas Schneebeli

Universidade Federal do Espírito Santo

Av. Fernando Ferrari, s/nº - 29060-970 Vitória-ES

[e-mail]

Abstract An approach based on concurrent object oriented programming (COOP) to build a control system for a mobile robot is presented. A behavior-based control system is decomposed in intercommunicating concurrent objects named Agents. These agents belong to five categories: Primitive Sensor, Virtual Sensor, Behavior, Primitive Actuator and Virtual Actuator. Based on this approach, a C++ tool is developed, where the categories above are implemented as C++ classes, in which built-in communication mechanisms are included. Each class has a standard interface and functionality. It is possible, then, to develop a complex control system by deriving new classes from the base classes and by instantiating objects. These objects are interconnected in a dynamic manner and thus building a control system with different behavior levels, which is able to react to environment changes.

Keywords: behavior-based control, agents, mobile robots, concurrent object-oriented programming.

1 Introduction

Behavior-based control architectures have proven to be good alternatives for controlling mobile robots in a simple and efficient way, as shown by Brooks [2, 3]. On the other side, concurrent object-oriented languages have good capacity for representing problem solutions involving concurrency, because of the powerful abstractions they allow and the possibility of reusing code [9].

In this paper, a framework based on the Concurrent Object Oriented Programming (COOP) paradigm is presented [8], which enables the construction of behavior-based control systems for mobile robots in a relatively simple way, also considering features like modularity, simplicity and real time aspects. The construction of a control system is done by creating new classes of concurrent objects derived from some base classes available in a library. The concurrent objects instantiated from these classes are called Agents, and are control modules similar to the modules originally used by [2, 3]. These agents can take an action or interact with other agents and/or with the external environment.

A behavior-based control system has a general structure that is similar to that shown in Figure 1 [3]. It is composed by various interconnected agents forming a control system in a layered fashion according [3]. The interconnections between agents are dynamically established, and are controlled by a message passing system.

As can be seen in Figure 1, there are three categories of agents. The agents in charge of acquiring information about the environment are the Sensor agents and are directly or indirectly connected to physical sensors. Those indirectly connected to physical sensors, like Agent S3 in Figure 1, just process information delivered by other agents, and are called Virtual Sensor agents. In a similar way, there are Actuator agents, which send information to physical actuators present in the system. There are also Virtual Actuator agents, which are similar to the virtual sensor agents.

Finally, there is a last group of agents, called Behavior agents, which receive information from the Sensor agents, process it, and send the results to the Actuator agents or other Behavior agents. As any other agent, the Behavior agents can be active or inactive in a given instant. In Figure 1, the agent B2 is inactive. Immediately after being activated by a message sent by agent B1, it must rearrange the connections in order to modify the overall behavior of the system. This is done by a subsumption mechanism similar to that presented in [3] and will be describe later.

Figure 1:
A behavior-based control system considered as a interconnection of agents

2 The Software Tool

The software tool here developed is based on the work of [7], where a behavior-based control system is decomposed in three categories of specialized agents (denoted Agents¹): Sensor, Behavior and Actuator, and some derived categories: Primitive Sensor, Virtual Sensor, Primitive Actuator and Virtual Actuator. This categorization is shown in Figure 2.

Thus, the job of a behavior-based control system designer is to identify the different agents necessary to build a behavior-based control system. The Sensor and Actuator Agents are generally easy to identify and implement. On their turn, the various behaviors can be implemented either as separated agents or as an interconnection of some simpler agents, according to the layering approach used in [3].

Figure 2:
Schneebeli's Agent categories [7].

The structure of the developed tool is shown in Figure 3. It consists of C++ abstract classes representing the different categories of agents present in a system. The primitive classes are PSensor, VSensor, Behavior, PActuator, and VActuator, which are shown in the upper part of Figure 3, all derived directly or indirectly of a base class Agent². Every object of the class Agent has a common set of general abstractions that implements some basic Agent features. For example, as concurrent objects they have execution threads, they can communicate between themselves by message passing, and they can be activated or deactivated by appropriate messages.

The base classes add features to the Agent class, making them more adequate to the purpose of the corresponding agent in the control system, thus simplifying their representation in a program. The base classes correspond to:

• Primitive Sensor Agent (PSensor class) – to directly interface the control system and physical sensors, collecting data and delivering information to other agents. Example: Agents S1 and S2 in the control system shown in

  Figure 1;

• Virtual Sensor Agent (VSensor class) – to implement filters, signal processing, and other manipulations in data coming from one or more Sensor Agents. It can be used to deliver new information obtained by a "sensor fusion" approach. Example: Agent S3 in

  Figure 1;

• Primitive Actuator Agent (PActuator class) – to directly interface the robot and actuators. Example: Agents A1 and A2 in

  Figure 1;

• Virtual Actuator Agent (VActuator class) – to implement preprocessing or a high-level actuator. For example, an Agent Move can be implemented, which responds to signal containing a direction and a velocity, and send set-point information to PID actuators (i.e. PActuator objects), which control the robot wheels;

• Behavior

  ³ Agent (Behavior class) – to implement the robot actions alone or combined with other members of this class, thus defining the robot overall behavior and its "intelligence". Example: Agents B1 to B4 in

  Figure 1.

Figure 3 shows an example of a control system developed using these frameworks, including all abstraction levels. On the top level, one can see the base agents, on the level immediately below, the classes developed by the designer of the control system and on the bottom level, a simple control system similar to the one shown in [3]. It is formed by the objects instantiated from the developed classes. This control system implements two behavior levels: Runaround (formed by the Runaround and Avoid Agents) and Avoid Obstacles (formed by the other Behavior Agents). The result is a code whose structure will be similar to that shown in Figure 4.

Figure 3:
Hierarchical structure of the framework

The term behavior used to name these agents should not be misunderstood as a behavior level used by Brooks [2,3]. In the context of this article, it refers to an element (agent) used to implement the behavior levels.

Figure 4:
Code structure of a behavior-based control system.

The code contains:

• the definition of the agent classes, derived from the primitive classes in a library, including information about binding;

• the implementation of the derived classes, specially the code of the method;

• the instantiation of the classes; and

• the main program, that is the method Main of the auxiliary class MainAgent, which is responsible for the startup of the system.

The implementation of a control system as a program with concurrent objects is based on concurrency models of multithreading, which allows the representation of a system as a network of cooperative elements, in this case the Agents. The use of the same base class for deriving all classes guarantees the uniformity of interface for all system elements, thus making the program easier and minimizing implementation errors.

3 Concurrency Model and Message Processing

The Agent object presented here descends of the actors defined in [5]. In the actor model, an actor is a computational agent that executes actions in response to received messages. Upon receiving a message, an actor can execute actions as to send a message to other actors, to create other actors or to execute a script. The Agent works in the same way, processing one message before accepting another one.

When an Agent is created through a constructor of a class defined by the designer, it is in an inactive state, in which it will remain until it receives a start message. It then goes to a stand-by state, in which it is active but waiting for a message. In this state it does not use CPU time. Upon receiving a message, it "wakes up" to verify if the message belongs to a predefined set of acceptable messages. If the answer is positive, it process the received message, and then returns to the stand-by state. If the message is not an acceptable message, the agent just ignores it and goes back to the stand-by state.

An Agent can be represented in a simplified form by its main components. As shown in Figure 5, it consists of:

• a message buffer, used to store the incoming messages;

• an input buffer, where the message being pro-

  cessed is stored;

• an output, where the message to be sent to other agents is mounted; and

• some methods, which implement the message processing algorithms.

Figure 5:
The basic structure of an agent.

The interaction between agents is based in a fully asynchronous message passing mechanism. Two types of messages can be sent: ordinary and express [9]. Messages sent in express mode have higher priority when compared to those sent in ordinary mode. So, they are processed before the messages passed in ordinary mode. Their use is very important to process emergencies or abnormal situations, once ordinary messages are only processed when there is no express messages in the message buffer.

The method invocation in agents is controlled by a enabled set mechanism [6], which is here implemented as a State⁴ class. So all agents has a state object denoted Agent::state as an attribute. The state object operates as gatekeeper to the agent methods. The keys of these gates are the message types. So, when an agent is in a certain state, this state determines the methods to be called for each message type.

When an object of the class state ("Agent: :state") is completely defined, the following parameters are known:

• the set of acceptable and unacceptable messages;

• the method to be called for each type of message received;

• a reference to the state from which this state is derived;

• a default method (optional) to be called in response to an unacceptable message; and

• an element called pseudo-guard, that implements a restrictive access to the methods. It is similar to the guards used in [1], and does not exist in the original enabled set approach [6].

The states form an hierarchical structure internal to the Agents (Figure 6), in which the low level states inherit information defined in the high level states. The same message type can be enabled in different states of an agent and in each state be associated with a different method, thus making possible that the most appropriate method to be called in each situation. The binding of messages and methods to states makes superfluous a lot of tests that should be done in methods to determine which algorithm should be executed. More important, to include the processing of new message types, it is not necessary to modify or to have access to the code of parent classes, thus avoiding the inheritance anomaly [6,8].

In a determined state, if there is no method bound to a certain message type, messages of this type are processed by a method specified in a higher level state. A great level of flexibility is thus obtained because it is possible to bind a certain message type to a new method, to make it unacceptable or to process it only if it comes from some given Agents.

Transparency is obtained because the transition between states is done internal by to the methods. The first state is specified in the agent constructor and the transition is done upon receiving the first message.

The connections needed to build a control system as a network of cooperative agents are established in two ways:

Figure 6:
Hierarchy of state objects internal to Agent

• hardwired: the destination of a message is coded in the Send method call.

• connect mechanism: an Agent sends a CONNECT message to another Agent asking it to put itself or a third one in its destination list. This is shown in

  Figure 7.

Figure 7:
Establishment of a connection

Generally, after finishing processing of a received message, messages are sent to all agents in the destination list. The disconnection works in a similar way, that is, the final effect of a DISCONNECT message is the removal of an agent from a destination list of a certain agent.

With this mechanism, it is possible to dynamically modify the Agent interconnection, thus enabling the system to alter its overall behavior to adapt to new environment situations or new goals.

4 Dynamic Reconfiguration of Agent Interconnections

The startup of an Agent can be done through the START and ACTIVATE messages. The stop of an agent, on its turn, can be done through STOP and DEACTIVATE messages. The START and STOP messages are used for simple startup and stop of Agents, without modifying the interconnections, and can be used for temporarily activating/deactivating an Agent. The ACTIVATE message is used to implement an activation mechanism similar to that of [7], by invoking the Init method, which activates the Agents that will be connected to the requesting agent and asks for connections to other Agents that will deliver information to it.

The activation of one Agent can activate other ones, forming a cascade (tree-like) of activation and finally forming a network of connections that will implement many layers of behavior levels (Figure 8). This activation mechanism is used to maintain active only the agent needed to compound a control system. Agents whose information are not ned, that is, those whose destination lists are empty, can deactivate themselves.

Figure 8:
The tree-like activation of Agents

The deactivation of an Agent can also occur through the DEACTIVATE message. In this case all Agents in the destination list receive a DEACTIVATING message informing that this Agent has been deactivated. These agents have to choose to deactivate themselves (the default action) or to proceed without the information delivered by this Agent. After sending the DEACTIVATING message the agent deactivates itself calling the End method.

There are two forms of mediation and arbitration used in this framework, both using the enabled set mechanism defined above:

• the

  conquer mechanism; and

• the

  channel mechanism.

The conquer mechanism [7] works as an important arbitration mechanism for Behavior Agents, forming a scheme in which Agents in a situation considered more important can assume the priority in sending messages to another Agent, in a way similar to the subsumption mechanism shown in [3]. With this mechanism, an agent processes only messages received from the conqueror Agent. The conquering process of an agent A by another agent B (Figure 9) occurs when Agent A sends a CONQUEST message to agent B. From this moment on, the agent B goes to a conquered state, in which only messages from agent A are processed. This monopoly over agent B ends when agent A sends a RELEASE message to agent B or after a timeout period after the last message received. In both cases, the agent goes to the state it was before being conquered. This mechanism is particularly important for the robot actuators. The situation of two distinct behaviors wanting to obtain the control (to conquer) of a certain actuator (Actuator object) is very common. This is necessary to avoid some panic-like situations, in which the actuator would try to obey contradictory commands coming from different sen-ders.

Figure 9:
The conquer mechanism

A channel mechanism based on [4] was introduced in [8] to try more advanced mediation and arbitration mechanisms. Channels as proposed in [4] were specifically designed for use in reactive control systems. A channel is an entity built to accept an arbitrary number of inputs and combine them in a predefined form (such as calculating the average, the sum, the maximum or the minimum value) in a unique output, as shown if Figure 10.

Figure 10:
A channel combines many inputs in one output

5 Implementation

This framework was developed originally in a Sun workstation and later on a PC running Linux using a cross-compiler based on GNU C++ and generating code for a Motorola 68XXX CPU. It was tested on a VME based system with Motorola 68030 CPU and later on a CPU board based on a Motorola 68332. With the exception of task switching routines implemented in Assembly and hardware dependent routines to interface with timers and serial channels, implemented in C, all software is programmed in C++ and is portable to any 32-bit CPU.

6 Conclusions

The invocation of objects through messages is a well known approach and is used in many Concurrent Object Oriented Languages. Using this abstraction and object oriented techniques, it is possible to develop a behavior- based system in a relatively simple way by adding features to existing code.

By using this framework one can construct agents and control systems, merging the concurrent classes with C++ (‘thread-safe’) standard classes. The framework favors the code reuse either by instantiation of many objects of the same class or by inheritance, adding new features to the existing classes without recoding them.

The modularity of the agent structure and the beha-vior-based control system enables the incremental building of the control system. Another consequence of the intrinsic modularity is the simplicity to implement this system in distributed or multiprocessor architectures. The possibility of dynamically modifying the connections between Agents according to the context contributes to the flexibility of this approach.

References

[1] G. R. Andrews, F. B. Schneider. Concepts and Notations for Concurrent Programming. ACM Computing Surveys. 15(2):3-43, 1983.

[2] R. A. Brooks. Autonomous Mobile Robots. In W. E. L. Grimson, , R. S. Paul (eds.) AI In The 1990's And Beyond, pages 343-363, MIT Press, Massachusetts. 1987.

[3] R. A. Brooks. A Robust Layered Control System for a Mobile Robot. AI Memo 864. Massachusetts Institute of Technology, 1985.

[4] E. Gat. ALFA: A Language for Programming Reactive Control Systems. In Proceedings of the IEEE International Conference on Robotics and Automation. pages 1116-1121, 1991.

[5] C. Hewitt. Viewing Control Structures as Patterns of Passing Messages. Artificial Intelligence. 8: 323-364, 1977.

[6] S. Matsuoka, A. Yonezawa. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. In Research Directions in Concurrent Object Oriented Programming. MIT Press. pages 107-150, 1993.

[7] H. A. Schneebeli. Die Steuerung von Mehrfinger-Greifersystemen PRD Thesis University of Karlsruhe, Germany, March 1992.

[8] J. E. M. Xavier. Uma Estrutura para a Construção de Sistemas de Controle Baseados em Agentes para Robôs Móveis. MSC Thesis Universidade Federal do Espírito Santo, Nov 1996.

[9] A. Yonezawa, E. Shibayama, T. Takada et al. Modeling and Programming in an Object-Oriented Concurrent Language. In A. Yonezawa, M. Tokoro, (eds.) Object-Oriented Concurrent Programming. MIT Press. . 55-90, 1991.

[10] Stroutsrup, Bjarne, C++ Programming Language. Addison-Wesley, 1990

1

Agent with uppercase A denote agent as define in [7].

2

Agent with fixed-width font denote a C++ class, which implements an Agent.

3

The term behavior used to name these agents should not be misunderstood as a behavior level used by Brooks [2,3]. In the context of this article, it refers to an element (agent) used to implement the behavior levels.

4

This should be not confused with the aforementioned active and inactive states of an Agent.

Publication Dates

• Publication in this collection
  08 Oct 1998
• Date of issue
  Apr 1998