4 The SHELLEY Integrated Environment (SIE)

The operating system model discussed above (see Figure 1) offers the additional benefit of being completely modular: distinct functional units are separated into disjoint and independent components. These components then can be used to construct more complex structures, which in turn can be used as the components to build even more complex and powerful entities. This modularity provides a very simple and convenient way for developers to construct powerful systems by using the work of previous developers as building blocks. Additional advantages are that this form is very flexible and expandable, and that it facilitates program code reuse. It is with this model in mind that we have designed the SHELLEY INTEGRATED ENVIRONMENT (SIE).

4.1 The Agent/Administrator/Device Model

We cannot, however, have complete freedom in the modularity of SIE; there must be some constraints to define the relationship between these modules. Thus, we employ the operating system model as the basis for a similar structure to govern SIE: the agent/administrator/device model.

In this modular all-encompassing structure, there are three primary types of components: agents, which are programs for a specific task, devices which the agents use to accomplish these tasks, and the administrator, which intercedes between the other two modules, facilitating communication and regulating agent access to devices.

4.1.1 Intelligent Agents

As discussed earlier, intelligent agents are objects designed for a specific artificial intelligence task, such as navigating through a maze, playing chess, or performing speech recognition. Thus, to build an artificially intelligent entity, multiple agents would be run to accomplish each different behavior desired. In SIE, the intelligent agent is considered to be a software application written to accomplish a particular goal, following the general definition presented earlier of an agent as a mechanism mapping input from sensors to behavior through effectors. Agents in SIE are analogous to application processes in the operating system model.

4.1.2 Device Modules

The agents, however, should not have to know the details of the resources (sensors and effectors) that they necessarily must use. Therefore, we call upon the device module to act as an interface between the agent requests and the physical robotic hardware. Device modules within the context of SIE encapsulate individual functional units. They usually control external hardware peripherals such as arms and cameras, though a device can just as easily contain a cognitive module such as an artificial neural network. Through device modules we are able to extract the implementation details of these functional units from the role of the agent programmer. These device modules are equivalent to an operating system's device drivers in that both the SIE device modules and the operating system's device drivers are software applications which facilitate the use of specific hardware by other software applications.

4.1.3 The Administrator

The challenge remaining is to integrate the agents and devices into a cohesive whole, allowing intelligent agents to use devices while still maintaining a relative degree of simplicity for the individual implementation of an agent. The solution is the administrator module which serves as a mediator between the agents and the devices that the agents use, much like the operating system kernel serves as a mediator between software applications and the hardware they must use. The administrator resolves all conflicts between multiple agents trying to control the same device. For example, if multiple agents require access to a robotic arm, but wish to move the arm in differing directions, it is up to the administrator to resolve this dispute. When an agent requires data from a device, the agent sends the request to the administrator who passes the request on to the device if the administrator deems the request admissible. When the device sends back data, the data is streamed to the administrator who channels it to the appropriate agent. In this way the complications of resource management are extracted from the agents and devices, and handled only by the administrator (see Figure 2).


Figure 2: The SIE Agent/Administrator/Device Model

4.2 Agent Ownership of Devices

Some devices such as one which interfaces with motor-driven wheels should only be controlled by one agent at any one time. Other devices such as one which acquires single frames of video from a camera may be used by multiple agents, but only one agent should have permission to make status changes to the device, for example, change the resolution or filtering mode in the case of a video frame acquisition device module. Given these stipulations, the administrator employs a mechanism for read/write permissions similar to that of a Unix operating system. If a device is designated as 'sharable' then it can have an unlimited number of agents using it, though it can have at most one owner with full read/write permission at any one time (ownership equals write permission); all other agents must use the device in read-only mode. The requests of a device which are considered read-only and those which require write permission must be explicitly made known to the administrator through a .conf file for each device (see Section 4.4 The device_list File).

This permission system introduces the additional complexity of determining which agent owns (has write permission for) a device. The administrator grants owner privileges to an agent for a specific device if the agent requests the device and no other currently connected agents own the device - either no other connected agents have requested the device, and therefore it is not yet connected, or other agent(s) are using the device, but the previous owner has relinquished ownership and no other agent in the interim has requested ownership.

Devices may also be specified to allow multiple instances. This most likely would occur with cognitive modules, or at least devices which operate completely at a software level and do not interface with external peripherals. If an agent requests a device of this type, then each request will result in a new device of that type to be run. Therefore, an agent who requests a device of this type is guaranteed to be granted owner permissions because it is the only agent using that instance of the device.

To further facilitate sharing of devices and inter-agent cooperation, an agent can query the current ownership status of a device and receive a response of either (a) the querying agent owns the device, (b) another agent owns the device, (c) no agent owns the device, or (d) the device is not known. The agent can also make a request to the administrator to claim ownership of a device, receiving either a confirmation or rejection. In the case of a rejection, the administrator sets a flag which indicates that there are agents without ownership who desire ownership. Agents can query the status of this flag to know if other agents have been requesting ownership. Additionally, the agent can relinquish ownership of a device. Through this system, multiple agents can effectively share a device by yielding ownership when they are able to operate in read-only mode, and by requesting ownership only when it is absolutely necessary to have write permission. Of course, handling of ownership issues is not necessary for an agent implementation; if an agent is not intended for use alongside other agents, then behaving in a 'device-greedy' manner is completely acceptable.

4.3. The Flow of SIE

Just as the kernel runs the entire time the operating system is running on a computer, our administrator module runs as a background process whenever we are using SIE. If no intelligent agents are running, then the administrator simply waits, listening for agents. When an agent is run, it connects to the administrator, informing it of what devices are needed. After each device request, the agent listens for a response from the administrator, who processes the device request and makes one of the following responses if an error occurs:

  • The requested device is currently in use by another agent, and the device is not sharable. The administrator gives the agent the choice of either exiting or continuing without the device.
  • The requested device is currently in use by another agent, but the device is sharable. Thus, the agent can access the device, but will not have ownership permissions. The administrator gives the agent the choice of either exiting or continuing without ownership of the device.
  • The requested device is unknown to the administrator. The administrator gives the agent the choice of either exiting or continuing without the device.

If a device is successfully connected to the administrator with the requesting agent as owner, then the administrator sends a confirmation to the agent. After each confirmation by the administrator (or acceptance of restrictions by the agent) the administrator sends the agent a unique identification number which the agent and administrator then use to refer to the device in all future communications. Note that this device identification number is not the same as the identification number listed in the device_list file. This identification number serves the purpose of allowing the agent and administrator to refer to a specific device, distinguishing between instances of the same device type. If an instance of a device is shared between multiple agents, then the same number is used by all agents to refer to this device. For example, if there is a video camera device module, an agent may require two instances of this module (one for each of SHELLEY's two cameras). Thus each instance of the module would be referred to by a different identification number so that the agent and administrator can distinguish between the two. Also, if multiple agents are sharing the same video camera module, then both agents use the same number to refer to the same device.

Such different situations may appear to make initialization of an agent overly complicated, but an agent could be written very simply by connecting to the administrator, asking for certain devices, and immediately failing if confirmation is not received. Depending on the context in which this agent will be run, this approach may be sufficient. However, in cases where the programmer wishes to maximize the stability of the agent and build support for inter-agent cooperation, handling of the above situations is necessary, along with the ownership issues discussed previously.

When an agent disconnects from the administrator, any devices used exclusively by that agent are also disconnected by the administrator. If the device is being used by other agents, then the device will remain until all agents accessing it disconnect.

4.4 The device_list File

When the administrator is started, it reads a device_list file that lists all the device modules that will be supported by the administrator. The device_list file must adhere to the following syntax: lines that begin with white space or pound signs ('#') will be ignored; lines which define a device must have the following information in order (separated by white space):

  • A positive integer, to be used as a unique identification number for the device. This number is used both internally by the administrator and by agents referring to the device at time of request.
  • The device executable name (with full path).
  • The host computer on which the device should be run. This currently has no effect - all device modules are run on the host of the administrator (see Section 7 Future Work for a discussion of running devices on remote computers).
  • Either share or no-share to designate if the device can be shared by multiple agents.
  • An integer to designate the maximum number of agents which can share the device. If the number is 0, then there is no fixed maximum. If the device is designated as not shareable, then this value must still be here, but it serves no functional purpose.
  • Either multiple or no-multiple to designate if the device can have only one instance or multiple instances.
  • An integer to designate the maximum number of instances which can exist for that device. If the number is 0, then there is no fixed maximum. If the device is designated as no-multiple, then this value must still be here, though it is meaningless.

Note that multiple overrides share; if a device is marked to be both multiple and share, a separate instance of the device will be created at each request - the device will never be shared until the maximum number of instances for that device is achieved, at which point the device will be shared.

Below is a sample device_list file. The lines with pound signs are comments. Each other line specifies a device by executable name and unique id number by which both administrator and agents will refer to the device.

	
	 # Andy Ritger
	 # 4-12-99
	 # Research Honors
	 # sample device list file
	 5 /opt/local/shelley/devices/frame_grabber localhost share 0 no-multiple 0
	 1 /opt/local/shelley/devices/neural_net localhost no-share 0 multiple 0
	 17 /export/home/aritger/temp/mobot_wheels localhost no-share 0 no-multiple 0 

The administrator also requires a file associated with the device in the same directory as the executable called <executable name>.conf (for example: 'frame_grabber.conf' or 'neural_net.conf'). These .conf files specify which device requests, if any, are considered to require write permission. If the administrator cannot find the file, it will produce a warning and proceed under the assumption that all requests require ownership to be performed.

4.5 Network Protocols and the Details of Inter-Module Communication in SIE

4.5.1 Choice of Communication Medium

The mechanism for inter-module communication within SIE is the sockets Application Programmer's Interface (API), following a client-server model where the administrator functions as the server, and the agents and devices function as clients. Sockets were chosen over other forms of interprocess communication (IPC), such as shared memory, pipes, and signals [6], because they are built on top of TCP/IP, and therefore facilitate the possibility of networking and distributing module execution over the different computers that comprise SHELLEY.* Sockets are a sequenced, reliable, fast, bidirectional means of interprocess communication through variable length streams [4]. The sockets are of type SOCK_STREAM and domain AF_INET, which allows the client-server to connect and communicate anywhere on the Internet [7].

To ease future implementation, several C wrapper functions are provided for simple socket creation and use (shelley_sockets.h and shelley_sockets.c). Future contributors are not bound to use the SHELLEY_SOCKETS mini-library, but the basic facilities are provided and a complete - though rudimentary - client-server structure can be built solely with SHELLEY_SOCKETS function calls. Figure 3 gives a detailed chart of the layers of protocol used in SIE.


Figure 3: The Layers of Inter-Module Communication Protocol used in SIE

4.5.2 Defining a Communications Protocol

In his 1997 paper, Douglas Gage discusses the obstacles he has encountered in networking mobile robot systems [7]. His approach is primarily for defense purposes using a wireless RF networking system, which differs from this project in that we do not have the same constraints of long bandwidth-delay, error prone links, and of being mission critical. Nevertheless, his discussion on communication protocol is still very much applicable. Gage defines protocol as: 'a language used by two entities to exchange information over a communications channel - it represents a shared understanding or agreement of how each entity will interpret the signals it receives from the other' [7]. To facilitate communication between the three types of modules in SIE, we must therefore intricately define the signals that will be sent between the modules.

SIE's communications protocol is as follows: once the socket connection has been established, 1-byte messages are sent across the connection, always initiating at the agent in agent-administrator communication, and at the administrator in administrator-device module communication.** This forces the condition that the administrator cannot directly broadcast information to agents; if something changes at the administrator, such as another agent relinquishing device ownership, agents can only find out this information by explicitly requesting it. Similarly, at the connection between the administrator and a device, state changes at the device can only be known by the administrator if it explicitly queries the device. This may at first appear confining, but it greatly simplifies the protocol between any two devices, because both will always know which is expected to send the next message.

When an agent connects to the administrator, there is a sequence of startup information passed back and forth in the following format: the agent sends the AGENT_CONNECT message, *** to which the administrator then replies with the ADMIN_ACKNOWLEDGE_AGENT_CONNECT message. Next, for each device the agent requires, it sends AGENT_DEVICE_REQUEST followed by an int32 integer which is the device identification number specified in the file device_list. The administrator then responds with ADMIN_CONFIRM_DEVICE_REQUEST if the device was successfully connected, and owner privileges granted to the requesting agent, otherwise, one of the following errors is sent by the administrator: ADMIN_DEVICE_UNKNOWN, ADMIN_DEVICE_ALREADY_OWNED, or ADMIN_DEVICE_NOT_AVAILABLE. In all three error cases the agent has the option of accepting the error (AGENT_ACCEPT) and the stipulations which that implies (see Section 4.3 The Flow of SIE) or failing (AGENT_FAIL), in which case there is no further communication between the administrator and the agent; the administrator disconnects the agent and frees all resources used exclusively by that agent. After the administrator has sent the ADMIN_CONFIRM_DEVICE_REQUEST, the administrator also sends a 32-bit integer which is a unique number which the agent should then use whenever referring to the device. The number is also sent after the agent sends the AGENT_ACCEPT message. When all devices have been requested and either confirmed, or errors accepted, the agent sends AGENT_DEVICE_REQUEST_DONE, indicating the end of startup communication between the agent and the administrator.

When a device is requested, the administrator uses the device id number given by the agent to lookup the device executable (this information is stored in the device list file) and run it, following the convention: '<device executable> <computer hosting the administrator> <port number on which the administrator is listening for devices>'. For example:

/opt/local/shelley/devices/frame_grabber localhost 4096

The administrator then waits for the device to connect to it, sending an acknowledgement upon connection, ADMIN_QUERY_DEVICE, to which the device responds with either DEVICE_READY or DEVICE_FAILED if the device module experienced some internal error and was not able to acquire all its needed resources. On a DEVICE_FAILED, the administrator sends an ADMIN_DISCONNECT_DEVICE message to the device allowing it to exit cleanly, and informs the requesting agent that the device is unavailable.

After these initial exchanges of startup information between agents and the administrator, and devices and the administrator, the specific protocol for a device must be explicitly defined for every device type. The administrator examines the device's .conf file to know which device requests require write permissions (requests not listed in the .conf file are assumed to only require read permission). However, beyond knowledge of what requests can only be issued by the owner, the administrator does not need to know any more specifics of the device protocol, and merely channels allowable requests through from agent to intended device, and from device to appropriate agent.

For an agent to send a command to a device, the agent sends the message AGENT_SEND_DEVICE followed by two int32 numbers: the unique identifying integer to specify the device, and the length (in bytes) of what is being sent to the device. There is the further stipulation that the first byte of the message for the device must be the request code. If the agent is not owner, the administrator compares this request with the requests listed in the .conf file for the device in question, and determines if the message can be sent to the device. If the administrator determines that the message can be sent to the device, the message (stripped of the AGENT_SEND_DEVICE, the int32 device id number, and the int32 message length). The administrator also notes which agent sent the message, so that when the device responds, the message can be channelled to the correct agent. The two requirements we place on device protocol in SIE are: (1) devices must always send some response back after receiving a request, and (2) the device must prepend this response with an int32 indicating the size (in bytes) of the response.

Finally, the agent can send the AGENT_DISCONNECT message which tells the administrator that the agent is quitting. At this point the administrator assumes that it will receive no more communication from the agent, and frees any resources that had been allocated for the agent. If the disconnecting agent is the only agent using any devices, those devices are sent the ADMIN_DISCONNECT_DEVICE message.


* While SHELLY currently consists of one Sun Ultra I Workstation and three Intel-based personal computers, there is no reason why that could not change in the future, and we can maintain the flexibility emphasis in our design by allowing for any number and type of computers.

** SIE employs its own defined types int8 (one byte, unsigned) and int32 (four bytes, unsigned) for all its communication. This is important for portability. If SIE is ported to a platform with a different sized integer (a different number of bits), the only change which needs to occur is the definition of SIE's int8 and int32 [8].

*** All messages are declared as constants through C #define statements in the sie_protocol.h header file.



Next     Previous Contents