multi-agent pathfinding algorithms simulator · start simulation 17 4.2.1.6. stop simulation 17-18...
TRANSCRIPT
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).