Versions of ESAIR

According to the hybrid Deliberative/Reactive paradigm, deliberative behavior (hereafter simply the behavior) can be represented by the sequence of reactive behaviors (also called, more simply, reactions). The reactions execute simple operations or make simple decisions.

The performance of the entire robot system can be represented by the sequence of behaviors which operate in turns, interact with each other and exchange information.

The architectures of most robotic software are composed of a fixed software framework and several behavior modules. The fixed software framework may too large for a robot system with limited hardware resources or for a small robot performing simple applications.

For this reason the ESAIR concept is proposed in two versions, the standard version (ESAIR STD) and a compact version (ESAIR MIN). The design allows users to switch between the two versions as needed.

The standard version is for a normal robot system which has multi-behavior capabilities and powerful hardware. Figure 3-4 shows the structure of ESAIR STD. It comprises all eight leaf classes and the arrows in the figure show the communication direction between those classes. The Resource Supervisor (RS), Behavior Supervisor (BS), Sensor Connection (SC)

and Action Connection (AC) are the four resident classes that make up ESAIR STD. With this framework, sensors and actuators can be added to the system. In ESAIR STD, the Connection class is adopted to simplify the behavior of sensors and actuators with different communication interfaces. In addition, the Supervisor class can be used to manage these behaviors in a robot system.

Figure 3-4: ESAIR structure, standard version (STD)

Figure 3-5: ESAIR structure of the compact version (MIN)

To accommodate systems with limited hardware resources, ESAIR MIN employs just three classes: Sensor, Reaction and Actuator. Removing the Supervisor class and Connection class alleviates the computational load of the robot system, but some flexibility may be sacrificed. Figure 3-5 shows the structure of ESAIR MIN. Because the Supervisor and Connection class are removed, run-time swapping behaviors and resources are not supported.

The hardware resources and reactions are selected in advance, during the design stage.

In this research, ESAIR STD is implemented in Linux using GPL libraries, and ESAIR MIN is implemented in PIC series MCU using specific libraries. In order to consider the system open-source, the Linux OS was selected for the standard version. Although ESAIR’s goal is to be flexible enough to be used on any kind of platform, ESAIR STD is only compatible with Linux OS and cannot be used on Windows OS. In fact, all open-source projects are based on Linux OS, and so we selected it for ESAIR as well. Furthermore, ESAIR STD can be implemented in two ways. One is that all ESAIR components including RS, BS, AC, SC, Behavior, Reaction, Actuator and Sensor are operated in individual processes and the other is that all these ESAIR STD components in are the threads in single ESAIR STD process. The implementation allows users to switch between two ways as needed.

Chapter 4

ESAIR Class Overview

This chapter describes the attributes, operations and responsibilities of the eight leaf classes that comprise ESAIR along with the relationships and interactions between them.

There are: Behavior Supervisor class, Resource Supervisor class, Behavior class, Reaction class, Sensor Connection class, Actuator Connection class, Sensor class and Actuator class.

4.1 Behavior Supervisor

The Behavior Supervisor (BS) is designed to deploy the Behavior classes and manage their interconnections. There behavior supervisor defines three processing phases:

initialization, user control and interconnection. In first phase, the BS is constructed and invokes the behavior defined in the configuration list. After making the order, the BS enters a WAIT_REQUEST state to wait for requests from users or other behaviors. ESAIR flexibly provides the ability to add and delete behaviors in run-time. Figure 4-1 illustrates the operation of the BS initialization phase.

Figure 4-1: Operation of BS in initialization phase

The user controls the second phase, handling the insertion and removal of behaviors with external inputs. When the BS is in the WAIT_REQUEST state (and only then), users can

command the BS to add or delete behaviors, which force the BS to enact or ignore the specified behaviors. Figure 4-2 illustrates the operation of the user control phase.

Figure 4-2: Operation of BS in user control phase

The third phase is behavior interconnection. The BS acts as a mediator to provide the central unit with the ability to handle the data exchange between behaviors. Adopting the mediator design pattern simplifies this exchange because it monitors only each behavior’s connection with the BS and does not need to consider peer-to-peer connections between behaviors. This approach enables initiating and removing behaviors during run-time.

This phase deals with two types of interconnection. The first arises when a target behavior wants to send data to a selected behavior, and the other is when a target behavior wants to receive data from a selected behavior.

In the first situation, the target behavior sends data directly to the BS, which hands the data transmission to the selected behavior. Before sending the data, however, the BS queries and checks the state of the selected behavior to determine whether it is able to receive the data.

If so, the BS sends the data along to the selected behavior and notifies the target behavior of the successful transmission. The upper part of Figure 4-3 shows the time sequence of a successful data transmission, and the arrows show the interaction among those components.

Figure 4-3: Time sequence diagram of Behavior A sending data to Behavior B

If the selected behavior is not-available to receive data, the BS repeats the query until the status changes or until a fixed time interval elapses. If it still cannot send data to the selected behavior at the end of the time interval, the BS cancels the sending order and notifies the target behavior with a fail message. The lower part of Figure 4-3 is shows the time sequence in a failed transmission situation.

When a target behavior wants to receive data from a selected behavior (the second situation in the BS’ third phase), the BS receives the request and queries the selected behavior to determine if it can send the data. If the selected behavior is available to send data to the target behavior, the BS orders the data, receives it from the selected behavior and sends it on to the target behavior to complete the task. The upper part of Figure 4-4 illustrates the interaction among these components in a successful data transmission.

Figure 4-4: Time sequence diagram of Behavior A receiving from Behavior B

If at the end of a fixed time interval the BS has not received a positive response to its query from the selected behavior, it cancels the order and sends a fail message notifying the target behavior. The lower part of Figure 4-4 shows the components’ interaction in this scenario.

In the behavior interconnection phase, ESAIR does not employ typical mechanisms such as a mediator or observer design pattern because those mechanisms are updated automatically with information from the components. Automatically updating information for every behavior is a processor-intensive task however, and it requires powerful hardware support. To lighten the processing load of behavior interconnections, ESAIR adopts a mechanism that sends and receives data according to the requests from behaviors. The pseudo code of the class defining the BS is shown in Figure 4-5.

~BehaviorSupervisor();

PutDataToBehavior(char* behavior, char* data);

GetDataFromBehavior(char* behavior);

QueryBehaviorState(char* behavior);

HMICommand(char* behavior);

BehaviorSupervisor (char* BehaviorList);

Figure 4-5: Pseudo code of Behavior Supervisor

4.2 Resource Supervisor

The Resource Supervisor (RS) serves two functions. It deploys Resource classes and handles requests from behaviors to configure those resources. The RS achieves these results using a four-phase process.

The first two phases, initialization and user control, are very similar to the first two phases of BS. The difference is that the deploying targets are not behaviors, but resources. RS initializes all the pre-defined resources in the first phase and receives users’ requests to add/remove resources in the second phase.

The user control phase is similar to the one in BS. Here, the user can add or remove resources, and RS receives and handles those requests in the Sensor Connection and the Actuator Connection. Because users are assigned the highest priority, they can delete a resource directly, without any allowance.

The third phase is the behavior registration phase. Before a behavior can use a resource, it needs to register a request with the RS. The resource registration mechanism stores information about behaviors’ resource usage for both the RS and the Connection. Furthermore, the developer also can pre-define the allowed usage of every resource and provide levels of resource usage authority using the registration mechanism. After a behavior registers with the accessed resource, the registration messages are checked by RS in the resource configuration phase and inspected by the sensor/actuator connection before the behavior uses or configures the resource. The data structure of resource registration information is used to share data between the RS and Connection classes. Figure 4-6 shows the operation between the behavior and RS in the behavior registration phase. After the registration is completed, the behavior receives acknowledgement from the RS, and it can then connect to the registered resource using the Connection. Further details of the interaction among behaviors, Connections and resources will be discussed in parts 4.5 and 4.6 of this thesis.

Figure 4-6: Operation of resource supervisor in behavior registration

The fourth phase is the resource configuration phase. This phase handles requests from behaviors to configure the attributes of resources. The behavior only can configure a resource after registering with the RS in the third phase. The configuration mechanism is based on the operation of the ioctl function in the I/O sub-system of a UNIX-like operating system. This

phase is the primary function of RS. The connection of resources is kept separate from the data flow and the control flow. The main goal of RS is to isolate the control flow of the Resource class. The data flow of resources is handled by Connections.

The mechanism that separates the flow of control instructions from the flow of data simplifies the implementation and makes ESAIR reusable and flexible. Figure 4-7 shows the interaction of a behavior attempting to configure the Sensor class using the RS. RS will check the registration of resources and authenticate usage permission, before allowing the behavior to use the resource. The pseudo code of the class definition of RS is shown in Figure 4-8.

Figure 4-7: Operation of resource supervisor in resource configuration phase

Class ResourceSupervisor () {

public:

ResourceSupervisor (char* ResourceList);

~ ResourceSupervisor();

HMICommand(char* behavior);

RegisterBehavior(char* behavior, char* resource);

ConfigureResource(char* behavior, char* resource);

InvokeResource(char* resource);

RemoveResource (char*resource);

//…

}

CheckRegistration(char* behavior, char* resource);

// … private:

InitializeRS();

Figure 4-8: Pseudo code of RS definition

4.3 Behavior

A behavior class is an independent software component in ESAIR. Because behaviors are processed individually, the system guarantees reusability and ease of use and management.

Every single Behavior class provides a single sophisticated capability, such as face recognition, path tracking and so on. The definition of the behavior follow is deliberative in the hybrid deliberative/reactive paradigm approach. Behaviors can be smoothly added or removed by the BS to allow developers to achieve ideal robot performance. Behavior classes include three parts, or methods, which are outlined below.

First a behavior defines itself with primitive abilities that outline the initializing, terminating and executing of the behavior. Those primitive abilities form the life cycle of the behavior. The initialization of the behavior happens in the first or second phase in the BS.

During the execution of the behavior, it may need to communicate with other behaviors or resources to get the required information to assist in the targeted task. Terminating a behavior can be done manually in the BS user control phase, or it can self-terminate if the behavior specifies a one-time task and not an infinite loop task.

Second, communication with other behaviors is handled by the BS. The behavior may send data to other behaviors, receiving data from other behaviors, and query the current state of another behavior. When sending data to another behavior, the BS handles the transaction.

Receiving data from involves a request to the BS, which sets out to acquire the data from the selected behavior. The BS’s ability to query the current state of the selected behavior is important for determining whether data can be sent to or received from the selected behavior.

Successful data transmission, for send and receive requests alike, is not guaranteed if the selected behavior is unavailable, and the target behavior is notified of any failure. The non-guaranty of data transmission ensures the independence of each single behavior, though it sacrifices ties between coupled behaviors. Although communications between behaviors are not guaranteed, ESAIR is provides an adjustable time out interval to increase the likelihood of successful data transmission, and thus increases the robustness of the system.

Third a behavior may require communication between resources. The methods employed here include registering a resource, attaching resources, detaching resources, obtaining data from sensors, sending data to actuators and configuring resources. Registering and configuring resources are responsibilities of the RS. After the behavior registers with the selected resource, the behavior will attach to the resource using the Connection. Then the behavior can send data to actuators and receive data from sensors. The pseudo code of the definition of a Behavior class is described in Figure 4-9.

Class Behavior ()

Active();

CommunicateResource(); //communicate with resources by Connection CommunicateBehavior(); //communicate with behavior by BS

Terminate();

//…

}

Figure 4-9: Pseudo code of Behavior definition

4.4 Reaction

In ESAIR, a Reaction class is a sub-set of the Behavior class. It is adopted by the reaction part of the hybrid deliberative/reactive paradigm. To introduce the concept of the Reaction class, it will be discussed here in the context of the two ESAIR versions.

In ESAIR STD, the Reaction class can be regarded as the resident or primitive behavior needed in almost every robot system. A reaction can interact with resources without using the Connection class. This means that behaviors that need an immediate response can be chosen for implementation by the Reaction class. Furthermore, because a reaction is limited by the usage of resources and a pre-defined stopping point, reactions only govern simple behaviors.

Reactions are a sub-set of the Behavior class, so they can be regarded as a limited version of the Behavior class. In contrast to the Behavior class, the Reaction class only has three parts:

main functional capability (primitive), the communication with resources and the communication with Behavior classes. The main functional capabilities of reactions are identical to those of behaviors. In the Reaction class, communication with resources is direct rather than mediated by the Connection class. The developers need to select swappable methods to realize the connection of resources to reactions when off-line. When a reaction communicates with a Behavior class, it only needs to receive the request from the behavior and operate those commands, which could include disabling the reaction.

In ESAIR MIN, the Reaction class is either platform-dependent part or platform-independent. Platform-dependent reactions consider communication with resources using several communication interfaces on different platforms. Developers can select a suitable interface for their target resources. To combine these communication interfaces, the shell of the reaction is constructed. Platform-independent reactions provide the core of an operation algorithm and decision-maker for a reaction. Independent reactions control dependent resources to perform the desired reaction. The pseudo code of the definition of Reaction class is described in Figure 4-10.

Communicate(); //communicate with sensors or actuators Terminate();

Figure 4-10: Pseudo code of Reaction definition

4.5 Sensor Connection

In ESAIR, the Communication class between behaviors and resources isolates them from each other. The existence of the Connection allows behaviors and resources to easily swap because the relationships among those components are simple and fixed (A behavior class

relates to the BS and the Connection and Resource class relate only to the connection class).

Sensor connection (SC) is one leaf of the Connection class, and it handles data transmission to and from sensors in the robot system.

Figure 4: Relation of sensor connection

The SC works like a router to designate the path from specific sensors to designated behaviors. It handles all data collected by the sensors in the robot system and the control connection is handled by the RS. The relation among behaviors, sensors and the SC is shown in Figure 4-11.

SC is one of the resident components in ESAIR STD. In run-time, SC receives data from all sensors in the robot system, but those data are not recorded unless they are requested by the behaviors. The sensor data will not be saved if the data is not required for a behavior, but the receiving process from every sensor in the sensor connection is continuous.

After a behavior registers a sensor from the RS, the RS will update the register information to the SC and the Behavior class will attach to a specific sensor from the SC. The behavior requests the attachment of a sensor, and SC will route the required sensor data information to the behavior. After the behavior attaches to that sensor through the SC, the

behavior can receive the required sensor data, updated automatically by the SC. The interaction among the behavior, RS and SC is illustrated in Figure 4-12.

Figure 5: Interaction when a behavior receives data from sensors

The data transferred from sensors to the SC can be categorized by the type of data update:

periodic updating and event-triggered updating. Periodic updating is done by sensors set up to transfer data to the SC in fixed time intervals. This is often used for sensors that gather environmental information such as temperature, pressure and so on. Event-triggered updating comes from sensors such as buttons, keypads or touch panels which update data when certain events are triggered. This type of sensor can interact with users, and the data gathered is triggered by users or certain defined events. Figure 20 shows periodic updating between sensors and SC.

Because the SC handles the data collected by sensors, the control collisions will not arise.

SC supports various Behavior classes that require the same sensor data. The pseudo code of the definition of SC is described in Figure 4-13.

InvokeResource();

SensorConnection(char* ResoureList);

~ SensorConnection();

RScontrol(); //using by RS handle resource data flow

AttachSensor(char* behavior, char* resource); //attach by behavior

GetData(char* behavior, char* resource); //call by behavior to get sensor data

Figure 4-13: Pseudo code of SC definition

4.6 Actuator Connection

The Actuator Connection (AC) is similar in format to the SC. The only difference between these two Connection classes is that AC receives commands from behaviors and routes them to a specific actuator. The mechanism that attaches an actuator to a behavior registration is same as in the SC.

The main function of the AC is to designate actuators when ordered by behaviors. In ESAIR, many behaviors can control the same actuator, but this could entail logic conflicts

The main function of the AC is to designate actuators when ordered by behaviors. In ESAIR, many behaviors can control the same actuator, but this could entail logic conflicts