All components of the SALMA simulation approach have now been discussed.
This means that the parts of the delivery robots example shown in the previous sections can be assembled to create a fully functional simulation model and define concrete simulation experiments. As a first step, it is important to validate the model, i.e. to confirm that the simulated system behaves in a way that is consistent with the assumptions and expectations of the modeler. In the case of the delivery robots experiment, this can best be done by visualizing the behavior of the robots. The easiest way this can be achieved is by logging the positions of the robots to a CSV file with a step listener like that in Figure 3.20.
After the simulation experiment, this file can be read and analyzed with any mathematical software package like Matlab, Octave, or R, or with libraries provided by the scientific Python stack (SciPy) [dev15], which was used for all calculations and diagrams in this thesis. As a first step, the path of the robots can be plotted in a two-dimensional diagram together with the locations of items and workstations. Figure 3.23 show such a plot with all robot paths for a simulation with 3 robots, 20 items, and 5 workstations with a grid size of 200×200. All positions were initialized randomly by sampling from uniform distributions on the grid’s dimensions as shown in Figure 3.18. Even though it is hard to trace the exact movements of each individual robot, it can clearly be seen that the robots in fact adhere to the movement strategy defined in Figure 3.12 and that all items were visited during simulation. This already can be seen as a strong confirmation for the simulation’s validity. For further investigation, it is also possible to animate the robots’ movement, which shows that each robot exactly follows the two phase of its control procedure, i.e.
picking up the item and then delivering to a workstation.
After the validity of the simulation model has been confirmed visually,
0 50 100 150 200 0 xpos
50 100 150 200
ypos
rob1rob2 rob3
Figure 3.23: Robot paths from a simulation with 3 robots, 20 items, and 5 workstations in a 200×200grid.
experiments can be set up to perform deeper analyses of aspects in which the modeler is interested. One typical question that might arise in a scenario like the delivery robot example is how the number of robots influences the rate of items delivered to workstations. On the one hand, it makes sense to expect that deploying more robots means that items can be delivered faster. This is partly due to higher parallelism and also because the distances that have to be covered between robots, items, and workstation tend to be shorter. However, it should also be expected that there are limiting factors that counteract the positive effect of higher robot numbers from a certain point on. For example, depending on the grid size, very high numbers of robots probably lead to more collisions and hence broken robots that cannot contribute anymore. Therefore, one important question that could be investigated by means of a simulation experiment is to see whether there is in fact a limit for the number of robots at which a congestion appears.
Another significant factor for the efficiency of the delivery robots system is the strategy used by the coordinator to assign delivery tasks. So far, this has been a rather simple one that was already shown in Figure 3.11 and Fig-ure 3.13. With this strategy, the coordinator selects any robot that is not currently assigned to a delivery task and then chooses the closest item to that robot that has not been assigned to another robot, yet. Clearly, the assign-ments that are created could be rather inefficient when a robot is selected that
defselect_item2(station: Entity, ctx: EvaluationContext=None, **kwargs):
dist = (lambdar: np.abs(r.xpos - station.stationX) + np.abs(r.ypos - station.stationY))
robot_distances = [(dist(r), r)forrinctx.getDomain("robot")ifr.unassigned]
iflen(robot_distances) == 0:
returnNone, None
closest_robot = min(robot_distances)[1]
dist = (lambdai: np.abs(i.xpos - closest_robot.xpos) + np.abs(i.ypos - closest_robot.ypos))
item_distances = [(dist(i), i)foriinctx.getDomain("item")ifi.undelivered]
iflen(item_distances) == 0:
returnNone, None
closest_item = min(item_distances)[1]
returnclosest_robot, closest_item . . .
p = Procedure([
Iterate("self.request_queue", [ws], [ Assign([r, i], select_item2, [ws]), If("i != None and r != None",
Act("assign_task", [SELF, r, i, ws]))]) ])
Figure 3.24: Improved strategy for delivery task assignment.
is far away from the requesting workstation. A first possible improvement of the strategy might therefore be to select the unassigned robot that is closest to the workstation. This is shown in Figure 3.24 where the selection is done in-side a Python function that uses a very compact style leveraging Python’s list comprehensions andlambda functions for calculating the Manhattan distances (see [Bla06]) between robots and stations and between robots and items, re-spectively. Since the new selection function returns robot and item together as a pair, theSelectstatement used before in the coordinator’s control proce-dure (Figure 3.13) is removed and the result of the select function is assigned to the two variablesr andi at once.
In order to compare the performance of the two proposed strategies and to analyze the effects of the robot number, the experiment can be modified so that the number of robots and the strategy are used as controlled variables and the mean number of items delivered within a certain period is treated as the measured result. This is realized by the three nested loops shown in Figure 3.25. It can be seen that the number of robots is increased in steps of 5 from 5 to 100(since the second argument for Python’s range is exclusive),
fornum_robotsinrange(5, 105, 5):
forstrategyin[1, 2]:
foriinrange(10):
ifexperiment_path.joinpath("stop.txt").exists():
break else:
experiment = Experiment02(num_robots, strategy) experiment.initialize()
experiment.run(max_steps=500)
Figure 3.25: Experiment control loop for comparing delivery task selection strategies.
and for each number, 10 independent simulations are performed for the first strategy, and 10 for the second. What is not shown here is that instead of recording data for each simulation step as in the first experiment, this time a summary of each simulation run is logged, containing most importantly the number of robots and the number of items that could be delivered within the given period of500simulation steps. This is done by overwriting the life-cycle handler function after_run that the class Experiment02 inherits from the Experimentbase class.
The loop in Figure 3.25 conducts20×2×10 = 400independent simulations and writes the summary for each of them as one line to a comma separated val-ues (CSV) file. Due to the relatively high complexity of the logical progression performed in each step, the runtime of the simulations is significantly higher than it would be for an approach with a lower abstraction level. In fact, the time complexity of the progression step obviously grows approximately linearly in the number of fluents and entities in the system. For a configuration with50 robots, 10 workstations, and100items, this can mean durations of about two minutes for each simulation on a modern average desktop computer. However, since the simulations are independent, it is possible to run them in parallel, either on multiple cores on the same system of on a cluster of multiple ma-chines. The recorded results from all simulations can then simply be merged in order to achieve more precise analysis results. In fact, for the results shown below, the inner loop from Figure 3.25 was actually split and the simulations were distributed among10virtual machines on a cloud platform each of which conducted 2 simulations for each number of robots (one for each strategy).
For each simulation, a grid of 500×500 units was used that was populated with 10 workstations and 100 items with randomized initial positions. The probability pslot that any workstation slot generates a request in the current time step was set to0.01(see 3.1) in Section 3.4.2) and the number of slots per workstation was set to 100. This guarantee that there are always enough free
20 40 60 80 100
number of deployed robots
0 10 20 30 40 50 60
number of items / broken robots
avg. num. of delivered items (strategy 1) avg. num. of broken robots (strategy 1) avg. num. of delivered items (strategy 2) avg. num. of broken robots (strategy 2)
Figure 3.26: Mean count of delivered items and collisions by number of robots.
slots to generate tasks for all robots. Figure 3.26 shows the mean numbers of delivered items and the mean number of robots that were broken due to colli-sions, within500simulation steps for each combination of a number of robots and the chosen strategy. Each data point in the plot is a mean calculated from the results of 10 simulation runs. The plot clearly shows the expected advantage of the second strategy. It also confirms the anticipated congestion effect since a number of robots higher than55does not appear to improve the overall delivery performance significantly.