Multi-agent Pathfinding Algorithms Simulator · Start simulation 17 4.2.1.6. Stop simulation 17-18 4.2.1.7. Step by step 18 4.2.1.8. Restart simulation ... Multi-agent path planning

Multi-agent

Pathfinding

Algorithms

Simulator by

Liron Katav Amit Ofer

Version 1.0

Page 2

Table of Contents

1. Introduction 4

1.1. Vision 4-5

1.2. The Problem Domain 5

1.3. Stakeholders 6

1.4. Software Context 6-7

1.5. System Interfaces 7

1.5.1. Hardware Interfaces 7

1.5.2. Software Interfaces 7

1.5.3. Events 7

2. Functional Requirements 8

2.1. Graphical presentation of maps 8

2.2. Simulation configurations and tools on Grid map 8

2.3. Simulation configurations and tools on Geographical map 9

3. Non-functional requirements 9

3.1. Performance constraints 10

3.1.1. Speed 10

3.1.2. Capacity 10

3.1.3. Reliability 10

3.1.4. Safety and Security 10

3.1.5. Portability 10

3.1.6. Usability 11

3.1.7. Availability 11

3.2. Platform Constraints 11

3.2.1. SE Project constraints 11-12

3.3. Special restrictions & limitations 12

4. Usage Scenarios 12

4.1. User Profiles — the Actors 12

4.1.1. User 12

4.2. Use-cases 12

4.2.1. Use-cases in Grid map simulator 14

4.2.1.1. Create New Scenario 14

4.2.1.2. Load scenario 14-15

4.2.1.3. Save scenario 15-16

Page 3

4.2.1.4. Clear map 16

4.2.1.5. Start simulation 17

4.2.1.6. Stop simulation 17-18

4.2.1.7. Step by step 18

4.2.1.8. Restart simulation 18-19

4.2.1.9. Generate random scenario 19-20

4.2.2. Use-cases in Geographical map simulator 20

4.2.2.1. Set agents positions 20-21

4.2.2.2. Load map file 21

4.2.2.3. Start simulation 22

4.2.2.4. Stop simulation 22

4.2.2.5. Step by step 22

4.2.2.6. Restart simulation 22

4.2.2.7. Generate random scenario 22

4.3. Special usage considerations 23

5. Appendices 23

5.1. Grid xml file format 23

5.2. Map file type 23

5.3. References 23

Page 4

Introduction

Multi-agent path planning problem involves navigating units from their starting

position to their respective goals, whilst going around any static obstacles and other

moving units along the way.

The problem is becoming increasingly important in many real-life applications,

including motion planning in robotics, air traffic control, vehicle routing, disaster

rescue, Military operation planning and computers games.

It has been shown PSPACE-hard (it can be solved by a Turing machine using a

polynomial amount of space.) to compute a set of non-conflicting paths with the

shortest total length for a given instance in a grid world.

The standard admissible algorithm for this problem has a branching factor that grows

exponentially with the number of mobile units on the map, as the units move

simultaneously.

It is for these reasons that modern research on this problem focuses on finding a good

set of paths rather than an optimal set of paths.

Multi-agent pathfinding work can be grouped into two types of methods. Centralized

approach, in which all paths are computed jointly by a central unit. This approach is

theoretically optimal but computationally expensive. This approach have a major

advantage, it is able to handle complex navigation problems where movement is

constrained, such as in narrow corridors .Distributed (decentralized) approach

decomposes the problem into several sub- problems, which dictate local behaviors for

individual agents based on a small neighborhood of nearby agents. This method has

proven very useful for simulating groups of agents moving in unison, whether crowds

of humans or animals. The downside of the latter is that agents can lack a global

picture of the world.

1.1 Vision

The goal of this project is to develop a simulator that will help to observe the different

behaviors of different multi-agent pathfinding algorithms, in both grid map environment, and

real-map environment. The algorithms that will be tested in this simulator will be all based on

the basic A-star algorithm:

Page 5

A-star (A*), Peter Hart, Nils Nilsson, and Bertram Raphael, (1968).

Hierarchical Cooperative A* (HCA*), Silver, D. (2005).

Operator Decomposition + Independence Detection, Standley, T. (2010).

The simulator will allow the running of algorithms on two different environments:

Grid environment.

Geographical-map environment

The simulator will have easy-to-use interface which allows a convenient way to

compare between the above algorithms by various parameters.

1.2 The Problem Domain

The problem domain is to simulate several multi-agent pathfinding algorithms, and to

allow comparing them by several parameters, such as time complexity, space

complexity and more.

MPAS (Multi-agent Pathfinding Algorithms Simulator) works on both Windows and

UNIX environment.

The simulator will have two main components:

Grid environment.

Geographical map environment.

One of the most important goals of this product in this domain is providing the users a

friendly, useful, quick and functional User Interface for comparing different multi-

agents pathfinding algorithms.

External

GIS system

MPAS

Geographical map

environment

Grid map

environment

Page 6

1.3 Stakeholders

The MPAS is mainly a research tool for evaluating the efficiency and performances of

the algorithms discussed above.

Researchers will be able to simulate different scenarios based both on grids and

geographical maps.

The application will be useful for researchers in the field of pathfinding (AI).

Our main client is the Information Systems Engineering department in Ben Gurion

University (Mr. Roni Stern).

1.4 Software Context

We will divide the system into the following components:

Algorithm Layer will be responsible for running the algorithms.

It receives input needed for the algorithms such as number of agents, starting

and finishing positions for each agent, map type (grid of real-map) etc from

the controller layer. After receiving all the relevant data it will compute the

optimal paths (if one exists) for all the agents according to the input given

by using the chosen algorithm.

Controller Layer will be responsible to handle all the communication

between the algorithm layer and the Presentation Layer. It will receive input

from the user, and sends it to the algorithm layer. Then, whilst running the

algorithm it will receive data from the algorithm and sends notification to the

GUI in order to build a graphical representation of the current state of the

algorithm.

By using an event mechanism this layer is notified when any change is done in

the algorithm state, and can easily send the changes to the Presentation Layer.

Presentation Layer will be responsible for handle the communication with

the user and it will provide a graphical representation of current simulation

state and the final results of the algorithm (both a visualization of the

computed path for all the agents and the statistics).

We will have two graphical representations:

o Grid map - will be based on two-dimensional array, up to the size of

1000*1000 Cells.

o Geographical map – by using an external GIS SDK.

Page 7

This layer will allow the user to choose all relevant data for the simulation,

such as the algorithm, heuristics, the number of agents, starting and ending

positions for each agent, blocking areas and more.

1.5 System Interfaces

1.5.1 Hardware Interfaces

not applicable.

1.5.2 Software Interfaces

The system will operate both on Windows and UNIX environments.

The system will work with geographical map data from External GIS (geographical

information system) software such as – Google maps, Maps Web Services, etc.

Those software products produce a map file that will be used as an input for the

algorithm.

The External GIS software is still undecided (we are still in the process of researching

and trying to find the most suitable open source product for our application).

1.5.3 Events

The main events of the application are described as uses cases in section 4.2.

Presentation

layer

Controller

Layer

Algorithm

Layer

Events- Method Invocation-

User Gestures

View Changes

Input

State Change

Page 8

Functional Requirements

2.1 Graphical presentation of maps Choosing the map type - The user will have to choose on which environment

to run the simulator.

There will be two options:

o Grid map

o Geographical -map

2.2 Simulation configurations and tools on Grid map

# Requirement Description

1 Choose the size of the

grid map, and the

number of agents

When the user chooses the grid option, he will have to

choose the size of the grid. He also have to choose the

number of agents he wants to run in the simulator

2 load grid maps The user could load grid map, which will includes the

size of the grid and the blocked cells

3 save grid maps The user could save grid map, which he will create

including blocked cells and the grid map.

4 clear map The user can clear all starting and finishing cell and also

the blocking cells, in order to have an empty grid map.

5 Sets the starting and

finishing cells for each

agent

The user can choose the starting and finishing cell by

selecting the agent number, selecting start/finish point

and clicking the cell.

6 Set blocking cells The user can choose which cell to block by selecting the

block option and then clicking the cell he wants to block.

7 Choose the algorithm to

be tested

The user chooses one of the 3 algorithms: A*, HCA*, CP

8 Choose the heuristic to

be used

The user can choose which heuristic will be used for the

search

9 Start the simulation The user will press on the "start" button to start the

simulation

10 stop the simulation The user will press on the "Stop" button to stop the

simulation , he could not re-run it from that point again

11 Running the simulation

Step by step

The user will press on the "Step" button to run only one

step of the simulation , meaning one step of the agents.

12 Generate random

scenario

The user can choose to create random scenario by

providing the size of the map and the number of agents

13 Restart simulation The user can clear the result of the simulation, and can

choose to run the same scenario using different algorithm

and/or heuristic.

Page 9

2.3 Simulation configurations and tools on Geographical map

# Requirement Description

1 Choose the map, and

the number of agents

When the user chooses the real map option, he will have

to load a map from a file. He also have to choose the

number of agents he wants to run in the simulator

2 Sets the starting and

finishing positions for

each agent

The user can choose the starting and finishing positions

by selecting the agent number, choose the start/finish

option and clicking on the map.

3 Choose the algorithm to

be tested

The user chooses one of the 3 algorithms: A*, HCA*, CP

4 Choose the heuristic to

be used

The user can choose which heuristic will be used for the

search

5 Start the simulation The user will press on the "start" button to start the

simulation

6 stop the simulation The user will press on the "Stop" button to stop the

simulation , he could not re-run it from that point again

7 Running the simulation

Step by step

The user will press on the "Step" button to run only one

step of the simulation, meaning one step of the agents.

8 Generate random

scenario

The user can choose to create random scenario by

providing the size of the map and the number of agents

9 Restart simulation The user can clear the result of the simulation, and can

choose to run the same scenario using different algorithm

and/or heuristic.

Page 10

Non-functional requirements

3.1 Performance constraints

3.1.1 Speed

o The system should launch in less than 1 minute.

o The system should give an output graph not more than 15 minutes (it will

usually take much less, this is the worst case scenario with the simple A*

algorithm).

3.1.2 Capacity

o The user can test up to 1 Million vertices (1000 1000 on grid and 1

Million on real-map)

o The user can test up to 100 agents that will run simultaneously.

o The system should take up to 1GB RAM memory when processing the

data.

3.1.3 Reliability

The system is not required to support data recovery, self-stabilization or error-

correction.

The system should be able to detect when a corrupted file is loaded and alert the

user.

3.1.4 Safety and Security

The simulator will not demand any permissions or security levels. So this feature is

not applicable in this system.

3.1.5 Portability

The system should operate on Linux and Windows (XP/Vista/7).

The system should be able to run on a standard pc computer (though calculation times

may vary according to system specs).

Page 11

3.1.6 Usability

The system GUI should be user-friendly and easy to use.

The system should be simple to manage for the common user.

The learning pace of the system should be quick.

3.1.7 Availability

The system should be able to operate at any time of day and no matter the amount of

applications running at the background of the Operating System.

3.2 Platform Constraints

The application will be developed in Java and could work under Windows and

Linux operating system.

The station that will run the system should not be older than 3 years and

include JRE and java version 1.6 or higher.

3.2.1 SE Project constraints

The system is interactive due the fact that the user can configure it control the

running of the algorithm.

The system will get the input data for the simulator from the user or from a pre

made scenario (xml) file.

The Project development progress will be record in a special web page which

address is: http://mpasproject.weebly.com/

The application will not require any special hardware.

The application will be debugged and tested by using both Junit tests and a

logger.

The Project members will attempt to achieve the expected milestones:

o Requirements document – 4 weeks

o Initial prototype (all GUI aspect, dummy algorithms) – 2 months

Page 12

o All algorithms implemented – 4.5 months

o Updated prototype – 5.5 months

o Final product – Project's day (July 2011)

3.3 Special restrictions & limitations

Due to the complexity of the search problem given and the constraint on time (give an

output answer after at most 15 minutes) – the system might not return the whole path

but only a partial one.

Usage Scenarios

4.1 User Profiles — the Actors

4.1.1 User

The system has one type of user. The user is responsible for inserting the data into the

system, to start and stop the simulation and also to adjust simulation settings and

request the statistical data.

4.2 Use-cases

The system is divided into two sub-systems when the choice which environment to

run the simulator is made by the user. The sub-systems are:

Grid maps simulator.

Geographical maps simulator.

The use-cases are divided according to this division.

See use-case diagram in the next page

Page 13

Page 14

4.2.1 Use-cases in Grid map simulator

4.2.1.1 Create new scenario

Use case name: Create new scenario.

Version: 1.0

Goal: User wants to define the data needed for simulation.

Summary: The User chooses the size of the grid and the number of agents. The user

then provide properties and parameters such as: starting and finishing cells for each

agent and the blocking cells.

Actors: User

Stakeholders: User – interested in creating a new scenario for the Multi-agent

Pathfinding Algorithms Simulator in order to simulate the chosen algorithm.

Pre-conditions: valid data must be provided by User.

Triggers: User provides correct parameters.

Basic course of events:

1. User chooses to Create New Scenario in the GUI menu.

2. User chooses the size of the grid to initializes the map.

3. User chooses the number of agents he wants to simulate.

4. The system provide the grid and the agents as requested

5. User inserts into the grid-map the starting and finishing cells for each agent

and the blocking cells for all the agents.

Alternative paths or Exceptions: when some data is incorrect the system should

inform the user to re-enter valid data.

Post-conditions: the grid map model is created, and ready for running the simulation.

4.2.1.2 Load scenario

Use case name: Load scenario

Version: 1.0

Page 15

Goal: User wants to load and visualize a chosen .xml file, the file holds data needed

to run the Multi-agent Pathfinding Algorithms Simulator (agents start positions,

destinations and blocked cells).

Summary: The user chooses Load option in the GUI menu, and provides a path to

file, and then the system loads and visualizes the data given in the file.

Actors: User

Stakeholders: User – interested in loading existing scenario file to simulator.

Pre-conditions: .xml file exists and holds a valid data.

Triggers: User provides a correct path, and then the System loads the file.

Basic course of events:

1. User chooses to Load Scenario in the GUI menu.

2. User provides a path to file.

3. The system loads the file.

4. The system visualizes all the given data.

Alternative paths or Exceptions: if file doesn’t exist or some data is invalid, the

system should alert the User.

Post-conditions: .xml file loaded, the grid map model is created, and ready for

running the simulation.

4.2.1.3 Save scenario

Use case name: Save scenario

Version: 1.0

Goal: User wants to save a scenario in order to use it later.

Summary: User chooses a Save option in the GUI menu, the system saves current

data and properties to a file

Actors: User

Stakeholders: User – interested in saving/overwriting the scenario.

Pre-conditions: new file name chosen or other file selected for overwriting operation.

Triggers: User chooses save option and provides file name.

Page 16

Basic course of events:

1. User chooses save option in GUI menu.

2. The system loads save file dialog.

3. User chooses new name or file if overwrite.

4. The system saves file.

Alternative paths or extensions: if file already exist or some data is invalid, the

system should alert the User.

Post-conditions: .xml file created and saved.

4.2.1.4 Clear map

Use case name: Clear map

Version: 1.0

Goal: User wants to clear the data for the simulation. Data such as: starting and

finishing cells for each agent and the blocking cells.

Summary: The User chooses Clear option. The starting and finishing cells for each

agent and the blocking cells will be removed.

Actors: User

Stakeholders: User – interested in clearing the cells in the grid map.

Pre-conditions: there is data on the grid map.

Triggers: User click on the Clear option

Basic course of events:

1. User chooses to Clear option in the GUI menu.

2. The system clears the simulator's data from the grid. The grid's size and the

number of agents will not change. The data that will be deleted is: starting and

finishing cells for each agent and the blocking cells.

Alternative paths or Exceptions: when there is no data on the map, the system

should inform the user there is nothing to delete.

Post-conditions: the grid map is cleared, all the cells are empty.

Page 17

4.2.1.5 Start simulation

Use case name: Start Simulation

Version: 1.0

Goal: User wants to start a simulation.

Summary: User presses the Start button (after he chooses the algorithm he want to

test and all the relevant data is entered by the user correctly). The system starts

visualizing the algorithm process of the multi-agent pathfinding algorithm.

Actors: User

Stakeholders: User – interested in simulating and testing the given algorithm with the

data given.

Pre-conditions: the system has a scenario ready to be tested, and the user already

chose the algorithm.

Triggers: User presses a Start button

Basic course of events:

1. User presses start button on GUI.

2. The system sends the data to algorithm layer.

3. The algorithm layer starts calculating the paths, and sends data to GUI to show

the progress while the algorithm runs.

Alternative paths or extensions: when data is missing, the system should alert the

user to re-enter the data.

Post-conditions: simulation started, the GUI visualizes it, and the system visualizes

real-time progress of the algorithm.

4.2.1.6 Stop simulation

Use case name: Stop Simulation

Version: 1.0

Goal: User wants to stop the simulation before its done calculating.

Summary: User presses Stop button, the system stops the simulation.

Actors: User

Stakeholders: User – interested in stopping the simulation.

Pre-conditions: the simulation is running (path is being calculated).

Triggers: User presses a Stop button.

Basic course of events:

Page 18

1. User presses a Stop button in the system GUI.

2. The system signals the algorithm layer to stop simulation, visualization

freezes.

Alternative paths or extensions: none.

Post-conditions: visualization of the running simulation freezes.

4.2.1.7 Step by step

Use case name: Step by step

Version: 1.0

Goal: User wants to see the calculated path one move at a time.

Summary: User presses Step button, the system calculate the path and shows only

one step of the path, then the user can click again on the Step button to see the next

step in the path (and so on, until there are no more steps to show).

Actors: User

Stakeholders: User – interested in seeing the path one move at a time.

Pre-conditions: the system has a scenario ready to be tested, and the user chose the

algorithm.

Triggers: User presses the Step button

Basic course of events:

1. User presses the Step button on GUI

2. The system sends the data to algorithm layer.

3. The algorithm layer starts to simulate the calculation of the path.

4. The GUI shows only one step of the path found.

5. The user can click again on the Step button to see the next step of the path.

Alternative paths or extensions: when data is missing, the system should inform the

user to re-enter the data.

Post-conditions: simulation started, the GUI visualizes each step at a time.

4.2.1.8 Restart simulation

Use case name: Restart Simulation

Version: 1.0

Page 19

Goal: User wants to be able to clear the screen after a run of the algorithm in order to

allow the user to run the same scenario again using a different algorithm and\or

heuristic.

Summary: user clicked on the restart button, the GUI clears the screen and reloading

the same scenario to the state that it was before the running of the simulation.

Actors: User

Stakeholders: User – interested in reloading the same scenario again in order to try a

different algorithm and\or heuristic.

Pre-conditions: a scenario is loaded, the simulation finished its run.

Triggers: the restart simulation button has been clicked.

Basic course of events:

1. The user clicks on the restart simulation button.

2. The GUI informs the controller that the simulation is restarted so that all of the

algorithm layer's data structures will be cleared.

3. The results of the algorithm are cleared and the map returns to the state it was

before the running of the simulation.

Alternative paths or extensions:

If the user chooses to restart before the simulation ever ran it informs the user that

restarting will have no effect.

Post-conditions: The map is cleared, all of the algorithm layer's data structures are

clear and ready to run again.

4.2.1.9 Generate random scenario

Use case name: Generate random scenario

Version: 1.0

Goal: User wants to generate a new random scenario for testing an algorithm.

Summary: the user chooses to generate new random scenario option, enters the

required parameters, the system generates a new random scenario according to the

given parameters and displays it.

Actors: User

Stakeholders: User – interested in creating a new random scenario for running one of

the algorithms.

Pre-conditions: valid data must be provided by User.

Page 20

Triggers: the user chooses to generate new random scenario option from the menu.

Basic course of events:

1. The user clicks on the Generate new random scenario option in the menu.

2. The user enters the desired parameters for the new scenario (map size, number

of agents, the number of blocked cells).

3. The system generates a new random scenario that fits the entered parameters.

Alternative paths or extensions: If the user enters invalid parameters the system will

alert the user and ask him to re-enter the parameters correctly.

Post-conditions: a new random scenario is created and displayed, the user may now

run the algorithm of his choice.

4.2.2 Use-cases in Geographical map simulator.

4.2.2.1 Set agents positions

Use case name: Set agents positions.

Version: 1.0

Goal: User wants to determine the start positions and destinations for each agent in

the simulation.

Summary: The user chooses the agent for which he wants to edit its start

position/destination and chooses the desired vertex on the map.

Actors: User

Stakeholders: User – interested in adding a new agent or editing the start/destination

of an agent that already exists.

Pre-conditions: the map file is loaded and displayed in the application.

Triggers: user chooses a valid point on the map.

Basic course of events:

1. The user chooses the desired agent.

2. The user chooses whether to edit the start position or the destination of the

agent.

3. The user clicks on the map.

Page 21

4. The system sets the start/destination of the agent to the location the user

clicked on.

Alternative paths or Exceptions: if the user chooses start position and clicks on a

location on the map that is already occupied by another agent the system will alert the

user that it cannot continue with the request.

Post-conditions: the system sets agent's information according the user's selection.

4.2.2.2 Load map file

Use case name: Load map file

Version: 1.0

Goal: User wants to load and visualize a geographical map and run pathfinding

algorithms on it.

Summary: The user chooses the Load map option in the GUI menu, and provides a

path to file, and then the system loads and visualizes the data given in the file.

Actors: User

Stakeholders: User – interested in loading a map file to the simulator.

Pre-conditions: map file exists and holds a valid data.

Triggers: User provides a correct path, and then the System loads the file.

Basic course of events:

1. User chooses to Load a map in the GUI menu.

2. User provides a path to file.

3. The system loads the map file.

4. The system displays the map.

Alternative paths or Exceptions: if file doesn’t exist or the file is corrupted, the

system should alert the User.

Post-conditions: map file loaded.

Page 22

4.2.2.3 Start simulator

same as use case 4.2.1.5

4.2.2.4 Stop simulator

same as use case 4.2.1.6

4.2.2.5 Step by step

same as use case 4.2.1.7

4.2.2.6 Restart simulation

same as use case 4.2.1.8

4.2.2.7 Generate Random Scenario

Use case name: Generate Random scenario

Version: 1.0

Goal: User wants to generate a new random scenario for testing an algorithm.

Summary: the user chooses to generate new scenario, enters the number of agents,

the system will randomly determine the start/destination positions for every agent on

the map.

Actors: User

Stakeholders: User – interested in creating a new random scenario for running one of

the algorithms.

Pre-conditions: The number of agents must be between 1 and 100.

Triggers: the user chooses to generate new random scenario option from the menu.

Basic course of events:

1. The user clicks on the Generate new random scenario option in the menu.

2. The user enters the number of agents.

3. The system chooses the start/destination positions for all the agents randomly.

Alternative paths or extensions: If the user enters invalid input the system will alert

the user to re-enter the number of agents.

Post-conditions: a new random scenario is created and displayed on the map, the

user may now run the algorithm of his choice.

Page 23

4.3 Special usage considerations

None.

Appendices

5.1 Grid xml file format

ScenarioExample.xml

5.2 Map file type

TBA

5.3 References

1. A-star (A*), Peter Hart, Nils Nilsson, and Bertram Raphael, (1968).

2. Cooperative Pathfinding, David Silver (2005).

3. Finding Optimal Solutions to Cooperative Pathfinding Problems,Trevor

Standley (2010).