MIRO

MIRO is a distributed object-oriented framework for mobile robot control, based on CORBA (Common Object Request Broker Architecture) technology. The MIRO core components have been developed in C++ for Linux. Due to its programming language independence, further components can be written in any language and on any platform that provides CORBA implementations.

The MIRO core components have been developed with the aid of ACE (Adaptive Communications Environment), an object-oriented, multi-platform framework for OS-independent inter-process, network connection and real-time communication. They use TAO (The ACE ORB) as their ORB (Object Request Broker). TAO is designed as a high-performance implementer of real -time applications. Therefore MIRO should be easily portable to any other OS where ACE and TAO run. These include many Unix clones, Windows NT and some real-time operating systems. MIRO was built because existing robot control architectures were not sufficient to fill the needs of usability, reliability, scalability and portability. The hardware devices (sensors and actuators) run concurrently, and, due to the constant lack of computing power, tend to reside on multiple computers. When the goal of cooperative behavior among multiple autonomous robots becomes of interest, this system as a whole will become well-distributed. MIRO uses ACE and TAO because they are multi-platform, high-performance libraries which proved to be very sophisticated in terms of usability, portability and scalability.

Table 1: Comparison of related projects Interaction Client/Server IPC Client/Server

(layer)

Mediator CORBA CORBA Mediator

Flexibility Y Y Y Y Y Y Y

Software Resource Library Core + Component

Chapter 3 ESAIR Overview

The design of software architecture for robot systems should take into account not only the components that comprise the system, but also the behaviors that describe the coordination among components. This chapter introduces the proposed software architecture ESAIR and explains the design goals, the behavior classification and the design details of ESAIR’s component-based approach.

3.1 Design Goals

The major goal of the proposed software architecture is to provide higher flexibility, better reusability and ease of manageability for software components.

z Flexibility

Although the concept of middleware is not considered in this design, flexibility with ports should be maintained to accommodate different hardware and software platforms.

z Reusability

Reusability is the likelihood a segment of source code can be used again to add new functionality with little or no modification. The reusable software components should also eliminate hardware and software restrictions to be independent from platforms.

z Manageability

Manageability means that it should be easy to manage software plug-ins. We would like to design manageable components that can be inserted and removed in runtime without disturbing the current execution of robot systems. Manageability reduces the complexities in device connectivity and improves scalability of robot systems.

3.2 System Components

Generally, robot software frameworks are either component-based or behavior-based.

Component-based software frameworks make robot systems in which it is easy to insert and remove components. Behavior-based frameworks provide a friendly interface to define behaviors or operations in a robot system.

ESAIR combines concepts of both approaches. In the proposed architecture, new behaviors can be easily defined to coordinate system components. Similar to a computer system, the components for a robot system fall into four categories: control units, sensors, actuators and communication modules. These are shown in Figure 3-1.

The control unit acts as a central processing unit (CPU) in a PC system; it handles the algorithms and coordinates other system components to perform a specific behavior. Sensors can be treated as input devices that obtain data, such as environmental information, an object’s location, velocity, and so on. Actuators are output peripherals that perform real commands from the control units. The communication module is similar to the bus system; it handles the information exchanged among the system components in a robot. These system components make the robot system work well and perform various behaviors and operations.

Figure 3-1: Relation of system components

3.3 Behavior Classification

Behaviors, the core of robot systems, represent coordination and interaction among the system components, sensors, actuators, and controller mentioned in the previous chapter.

Since the coordination or interaction may or may not depend on the previous or current states of system components, robot behaviors can be classified according to their characteristics.

Figure 3-2: Hybrid Deliberative/Reactive Paradigm

By the end of the 1980’s, the Reactive Paradigm [22] gained popularity in the design and implementation of robots. The paradigm allowed robots to operate in real-time using inexpensive and more efficient processors. However, a robot design based on the Reactive Paradigm could not plan optimal paths, monitor its own performance or select the best behavior to accomplish a task. The sequencing or assembling of behaviors using the Reactive Paradigm relied heavily on the designer. In 1990’s, the Deliberative Paradigm [22] was proposed to provide planning, problem solving and learning capabilities. Upon integrating deliberative plans with the reactive paradigm, a hybrid Deliberative/Reactive Paradigm [22], as shown in Figure 3-2, was proposed to provide good software modularity and allow deliberative functions to execute without being influenced by reactive behaviors.

ESAIR adopts the hybrid paradigm and categorizes behaviors as either deliberative or reactive, as shown in Figure 3-2. In ESAIR, deliberative behaviors can actively require information from resources and from other behaviors. It also can memorize and use past

knowledge to predict future events by applying certain algorithms. The planning of deliberative behaviors allows access to information from/to sensors and actuators in a robot system. On the other hand, reactive behaviors defined in ESAIR can only access specific sensors and actuators according to profiles preconfigured by developers or applications. The reactive behaviors belong to a subset of deliberative behaviors.

3.4 Software Architecture

The software architecture proposed in this thesis consists of a standard version (STD) for robot systems and a compact version (MIN) for embedded platforms with limited resources.

This chapter introduces the definition of classes used for building the proposed architecture and the two versions.

3.4.1 Class Definition

In the proposed architecture, ESAIR, four base classes are defined to show an abstract representation of software components in a robot system. The four base classes are the Supervisor class, Action class, Connection class and Resource class. Based on the object-oriented approach, several leaf classes are inherited from these base classes. The four base classes are defined in this chapter, followed by a brief of the inherited leaf classes.

First, a Supervisor class responds to the deployment and management of resources and behaviors, such as configuration, device insertion and removals. Generally, a Resource Supervisor class and a Behavior Supervisor class inherit the methods and attributes of the Supervisor class in order to manage the resources and define behaviors, respectively.

Second, an Action class defines the activities, including behaviors and reactions, in a robot system. The Behavior class and Reaction class, inherited from the Action class,

represent the deliberative and reactive behaviors in the hybrid Deliberative/Reactive Paradigm, respectively.

The Connection class is designed to bridge the Action class and Resource class and it provides the single entry point between these classes to conceal communication details to heterogeneous devices, while providing a unique simple connection method rather than handling specific connections with a particular device for the Action class. For ease of design, the Connection class is extended to the Sensor Connection class, which only handles data from sensors, and the Actuator Connection class, which only handles connections with actuators.

Lastly, the Resource class is comprised of a variety of hardware resources used in robot systems. The resource class is divided by the direction of the data flow, and it extends to the Sensor class, which considers the data flowing from resource to action, and the Actuator class, which considers the data flowing from action to resource.

Figure 3-3: ESAIR class inheritance and association diagram

Figure 3-3 illustrates the relationship and inheritance of the four base classes and the eight leaf classes. The classes on the left side shown in gray blocks are base classes, which do not actually exist in ESAIR. They are abstract classes that define the whole software architecture of ESAIR. In other words, ESAIR is comprised of these base classes from an analytical viewpoint. The classes in the right side are the leaf classes inherited from the base classes.

The inheritance relationship is shown by the grey lines in the Figure. The control relationship of leaf classes is shown by the arrows. The arrows also note that the number of objects that can be controlled. The composition of those eight classes establishes the basic architecture of ESAIR’s design and implementation.

3.4.2 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.

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.