The Agent Net AGV Forklift Simulation

The Agent Net AGV Forklift Simulation Larry Suarez Grid Research Group Agent Net, Inc.

Abstract

There needs to be significant changes in the way software is developed. The increase in distributed computing problems (homeland security, cooperative business solutions, automated e-commerce) has rendered existing software solutions unreasonable. Adding to the dilemma is the fact that creating reliable, functioning distributed software solutions is beyond the capabilities of most developers. A distributed software solution must be able to adapt to constant changes, support non-central control, be self-monitoring, be self-healing, allow modifications at any time, and persist under failing systems. Agent-based systems, including distributed autonomous agents (DAA), are viewed as a possible solution to the distributed computing problems in the world today.

Background

Agent Net has been working on a distributed Agent Grid for the last five years. The grid, populated by autonomous agents, is viewed as the next generation architecture for distributed computing solutions. Although the benefits of agent-based systems are well known, the difficulty has been in how to effectively design and construct agent-based systems. A designer with minimal or no programming skills should be able to develop effective agent-based solutions. This paper will discuss the facility used by the Agent Net Corporation to research agent design paradigms and development tools for agent-based systems. The facility, the Forklift Simulation Software (FSS), is embedded within the Agent Net Agent Development Environment (ADE). FSS allows Agent Net researchers to experiment with visual graphical interfaces in the design of agents and agent systems. FSS is based on a well-known paradigm used by robotic and agent researchers – a manufacturer’s shop floor on which Automated Guided Vehicles (AGV) operate. The vehicles, forklifts under the control of agents (or holons), are programmed to navigate the shop floor. The forklifts are designed to accomplish both simple and complex tasks. Simple tasks include moving crates from one location to another. Complex tasks include the cooperation of multiple forklifts when lifting crates beyond the capabilities of a single forklift. The FSS facility provided by Agent Net includes the following:

1. Graphical design tool to define the shop floor on which the AGV forklifts operate.

2. Graphical flow tool to design “deliberative” agent processing genome. This implies the ability to weave agent behaviors into a flow to accomplish deliberative tasks such as moving a crate from one location to another (e.g. move forklift to shelf ‘A’ load crate from shelf onto forklift move forklift to truck ‘B’ drop crate in truck).

3. Minimal JAVA development text editor tool to construct agent behavior. Agent behavior is

The Agent Net AGV Forklift Simulation 2

constructed using the JAVA programming language. Using JAVA allows an agent behavior to execute on numerous types of machines and makes it available to a wide number of developers in the industry today. The editor tool allows the designer to write and compile JAVA code and assign the JAVA behavior to an agent.

4. Network modeling tool to model the distributed computing environment in which the agent-based solution will execute. The network modeling tool contains an embedded simulation component to allow simulating the execution behavior of the solution (including simulating host execution speed, network speed, and bandwidth capabilities).

The Forklift Simulation

The simplest means in which to understand agents and agent behavior is to present an example. Agent Net provides a demonstration of agent technology using a recognizable paradigm – the simulation of AGV forklifts. The simulation models a manufacturer’s shop floor which contains walls, shelves, crates, and forklifts. Each forklift is managed by an autonomous distributed agent whose behavior controls the forklift as it migrates through the shop floor. Figure 1 shows the Agent Net ADE tool in which the user has selected the forklift demonstration and has been taken to the shop floor designer.

The shop floor consists of a grid measuring 16x16. Each rectangle in the grid can hold either a shelf, forklift, crate, or wall. Designers can drag and drop objects from the Designer Toolbar onto the shop floor. Once the shop floor design is completed, the designer can save the layout at which time the Agent Net tool will generate the necessary agents to control the forklifts. Each agent is give the standard default name of “ForkLift_<id>” where <id> is some numeric value. In addition, the shop floor layout is translated into an internal world representation consisting of a rule-base. Agent behaviors use the world representation to determine the correct actions of the forklift on the shop floor. Agents are free to manipulate the world representation including adding and removing world information. The agents do not have any default behavior when first created. Designers may populate the agent’s behavior by using either existing behaviors or creating new ones. This document will not define the structure of an agent’s genome but suffice it to say that the designer has many different capabilities in constructing a genome.

Agent Net, Inc. Company Confidential 2/2/2007


Figure 1: Shop Floor Designer

Society Selector Designer Toolbar

Shop Floor (Top View)

The designer can create a shop floor from scratch or augment a number of examples provided by Agent Net. The agents and the representation of their world (shop floor) are collectively known as a “society”. The use of the term “society” is not without forethought. The agents within the society (i.e. agents operating on the shop floor) have the capabilities to collaborate with one another and to take on behaviors much like other entities that coexist within social structures. Agent research not only includes the design of the agents themselves but, more importantly, how agents interact with one another to form complex organizations or hierarchies which are not based on a central-control paradigm.

Agent Design

Agents are not designed as one would design software today. Current software design principles operate at only one level: thousands upon thousands of lines of code that execute sequentially from beginning to end or from one state to another. In contrast, agent design operates at multiple levels. An agent consists of a collection of “behaviors” in which each behavior is a small, succinct task or accomplishment. Each behavior executes to completion and then is returned to the agent’s pool of behaviors for further execution. In other words, a behavior executes over and over again during the life of an agent until triggered by special start/stop events or until the agent considers the behavior unusable or detrimental. If a behavior somehow faults (either from a programming error or hardware error), the behavior is still returned to the pool for execution which provides a level of fault-tolerance. Agents are free to manipulate at run-time not only it’s world representation but also it’s pool of behaviors. This provides the “learning” capabilities attributed to autonomous agents.



As an example, lets take an agent that shifts through email looking for indications of terrorist involvement. Within this agent, some behaviors intelligently break down the email into semantic information (typically call Information Extraction) and converts the data into the agent’s world. Other behaviors look for suspicious situations within the world (e.g. use of certain terms such as “al Qaeda”). Another behavior looks for terms that require immediate attention such as dates which may imply attacks. The agent may augment itself by searching the Internet for new behaviors from other agents that are more successful at locating terrorist involvement. Other behaviors may send located suspicious data to external agents which contain more sophisticated algorithms for detection (and hence must execute on larger and faster machines). By breaking the total task of an agent into behaviors, additional behaviors can be added to the agent while it is executing or different priorities can be adopted per behavior to achieve better results. For example, to prevent too many erroneous “red flags”. Another level of agent design includes the creation of complex behaviors by synchronizing a number of simple behaviors much like one would create a task workflow.

The Simple Shop floor

For our first example, lets design a simple shop floor with some walls, shelves, and a crate. There will be one forklift and hence one autonomous agent. The trend in agent behavior development in the industry is to not design large complex behaviors but to construct very succinct behaviors and then build complex behaviors using these fundamental behaviors as building blocks. Figure 2 shows the initial shop floor. The name of the example (society) is “ForkSim 1”.

Figure 2: Simple Shop Floor

Forklift

Wall

Shelf

Crate

As previously mentioned, when the shop floor design is saved, the ADE generates the required



agents for the simulation and constructs the agent’s world. As shown in figure 2, the left hand side of the ADE window contains the results of saving the design of the “ForkSim 1” society. The generated corresponding agent, “ForkLift_1”, is shown as well as the world representation, “World Model”.

When a simulation is initiated, the following general steps are taken:

1. The Agent Virtual Machine (AVM), which controls the life-span of an agent, is initialized.

2. Each agent is instantiated and begins it’s startup procedure.

3. Each agent loads the internal representation of it’s world into memory. The information represents the “beliefs” of the agent. Agent research includes the definition and completeness of world representations.

4. Each agent loads it’s behaviors into memory and then initiates the processing of the behaviors (e.g. a forklift starts to move on the shop floor).

Within this example, we have defined six behaviors for the agent:

1. GoToALoc: causes the forklift to move to a particular location on the shop floor.

2. MonitorBattery: monitors the battery life of the forklift and, if low, will dock the forklift onto a “charging pad”.

3. TurnIfBlocked: forces the forklift to turn on it’s axis in another direction if blocked in it’s current orientation.

4. GiveWay: if confronted by another forklift, this forklift will move to allow passage (or reverse if the path is not wide enough for two forklifts).

5. MoveToAdjacentLoc: causes forklift to move one rectangle in the direction of its orientation.

6. LoadCrate: if a crate is in an adjacent shelf, orient the forklift to the crate and load the crate from the shelf.

Although we have six behaviors for the agent, on the initial run of the simulation we will only enable the behavior “MoveToAdjacentLoc”. Enabling a behavior implies allowing the behavior to be used by the agent. Behaviors that are disabled are not available for execution but can be enabled at a later time. Agents are free to enable or disable their own behaviors based on the state of it’s world and may do so at anytime during it’s life-span. As mentioned above, the behavior “MoveToAdjacentLoc” means that the forklift will move indefinitely unless blocked to the next adjacent location on the shop floor grid in the direction of it’s orientation.

Figure 3 shows the result of the simulation shortly after initiation. The forklift has traveled a short distance by repeatedly executing the behavior “MoveToAdjacentLoc” and upon reaching a wall can no longer move to the adjacent location. In traditional software design, the developer would enhance the behavior “move to adjacent location” to anticipate the existence of walls and other objects on the shop floor. In agent design, we merely enable the existing behavior called “Turned if Blocked” which executes at the same level as the “move to adjacent location”. The designer does not indicate the order of execution and allows both behaviors to execute at the same priority level. In traditional software design, the software would be enhanced and the original software replaced during some “off-time” when the software was not in use. With agent design, the new



behavior can be added or enabled at any time during the life of the agent and becomes effective immediately.

Figure 3: Initiating the Simulation

Figure 4 shows the forklift now traveling through the shop floor after the “TurnIfBlocked behavior is enabled. Enabling or disabling a behavior via the Shop Floor Designer is accomplished by right-clicking on the behavior and choosing the “enable/disable” menu item. The behavior state is then toggled.



Figure 4: Enabling the “TurnIfBlocked” behavior

Agent Behaviors (now TurnIfBlocked is enabled as well)

Figure 5 shows the JAVA code used to model the “move to adjacent location” behavior. The code is viewed via the JAVA development environment embedded within the ADE tool. The code references a number of functions defined by the Agent system to interrogate the internal world representation. For example, to determine the current position of the forklift on the shop floor the function CurrentPosition() is called. The behavior code is executed using a standard JAVA virtual machine and requires no specialized code on behalf of the designer.



Figure 5: Behavior body Editor with “MoveToAdjacentLoc”

Advanced Shop Floor Example

The simple shop floor example shows that when a forklift has an agent that contains only two enabled behaviors (“move-to-adjacent-loc” and “turn-if-blocked”), the forklift can meander through a shop floor with little trouble. In fact, current agent and robotic research is concluding that most complex behaviors are derived from a small number of simple behaviors. The “learning” capabilities of agents includes the construction of complex behaviors from simpler behaviors. The next shop floor example is a little more complex. The task is to take a crowded shop floor and have a forklift locate a specific crate and deposit it in a new location (e.g. truck). Figure 6 shows the shop floor we will be discussing. Notice that there are now two forklifts (two agents) and a more complicated set of obstacles. Because the task is more complex than simply moving to an adjacent location, we need to use the behavior modeler to string a number of simple behaviors together.



Figure 6: Advanced shop floor example.

Figure 7 shows the behavior that is designed for the current example. The behavior is in the form of a behavior flow consisting of a number of simpler behaviors of which were discussed in the previous section. This flow models the “deliberative” behavior found in humans in which humans are able accomplish complex tasks by coupling many simpler behaviors. The entire complex behavior consists of the following behaviors executed in the following order:

1. Move to location “A” with coordinates (x,y) (“GotoALoc”).

2. Once positioned at location (x,y), load an available crate in the adjacent location (“LoadCrate”).

3. Move to location “B” with coordinates (x’, y’) (“GotoBLoc”).

4. Unload the crate in the next location in the currently oriented position of the forklift (“DropCrate”).

5. Park the forklift onto it’s charging pad.



Figure 7: Complex agent behavior “LoadTruckB”.

Finally, Figure 8 shows the progress of one of the forklifts moving towards the shelf on which to drop the crate.



Figure 8: Forklift carrying crate for dropoff.

Distributing the Solution

A final capability of the Agent FSS facility is the ability to simulate the distribution of agent societies within a agent grid. The simulation is accomplished via a network modeling tool embedded within the ADE tool. The network modeler within the FSS facility allows designers to model many types of network configurations which includes metrics such as “disk access time”, “host processor speed”, “network bandwidth”, and “disk utilization”. The modeler is a discrete-system simulator which models the real world as discrete steps that occur at specific events (e.g. time “ticks”). The designer can also use the simulator as a monitoring tool which can monitor a live agent-based solution in which values from the monitoring are feed back into the simulation for accurate future simulation runs.

Figure 9 shows a model of an agent-based solution for the distributed problem of allowing Intuit customers to send state tax forms to state processing centers. The diagram shows two agent societies in which one is executing on the tax payer’s home machine while another is executing at an Intuit processing center. Finally, each state processing center has defined an agent to act as a connection point to outside submitters in which the agent contains behaviors such as:

• Translate incoming tax forms to state internal formats.

• Filters to quickly test the correctness of the tax form and to return the form if incorrect.

• Filters to quickly flag suspicious tax forms.

• Response data to the submitter to indicate that the forms have been received and have either successfully or unsuccessfully passed initial document checks.



Figure 9: Network modeler distributing an agent-based solution.

Summary

Agent Net is researching the viability of applying agent grids to the distributed computing problems that exist today. A major issue that will determine the success or failure of agent grids is the difficulty in designing agent-based solutions. Using the Forklift Simulation Software (FSS) developed by Agent Net, Agent Net researchers can examine and evaluate the types of development environments that will allow designers to create powerful agent-based solutions.


The Agent Net AGV Forklift Simulation

Technology

Transcript of The Agent Net AGV Forklift Simulation