# Managing Redundancy in a Multiple-Robot Orienteering Problem for Equilibrium and Robustness
## 3 Results
### Simulation Results  
Our multi-robot planning scenario is characterized by five key parameters, which fall into three distinct categories: system parameters (the number of robots and the individual robot budget), topological parameters (the number of vertices and edges), and an adversarial parameter (the number of attackers). Figure 8 illustrates the influence of two critical parameters on the performance of the robotic system. In Figure 8a, the number of robots is varied from 2 to 6. The rewards remain consistent without a decrease. Notably, the RMOPWB algorithm demonstrates a substantial reduction in both the total budget and the load balancing value. Specifically, in the second subfigure of Figure 8a, as the number of robots increases, the budget required by the RMOP algorithm surges significantly, while the budget for the RMOPWB algorithm exhibits only a modest increment. This trend is attributed to the fact that, with other variables held constant, an increased number of robots leads to scene congestion and spatial limitations. A similar phenomenon can be observed in the workload balancing value. In Figure 8b, there are analogous results. As the budget expands, robots are permitted longer walks, suggesting an increasingly congested operational environment. Our RMOPWB reduces system redundancy and becomes increasingly more effective as the budget grows. Figure 9 illustrates the influence of two key parameters of the task topology: the number of vertices and the number of edges. First, we examine the impact of the number of vertices in Figure 9a. In this setup, the environment's topology is constructed as a _minimum spanning tree_ (MST), which is a planar graph. Thus, the number of edges is determined by the number of vertices. In contrast, Figure 9b shows the results as we directly increase the number of edges from 10 to 18. Both Figure 9a,b demonstrate that with our proposed algorithm, the total rewards collected by the robot team do not decrease. In both scenarios, increasing either the vertices or the edges leads to a sparser spatial distribution of the robots. This contrasts with the results shown in Figure 8 and causes the performance of the RMOPWB and RMOP algorithms to converge. Despite this convergence, our proposed RMOPWB algorithm still demonstrates a consistent, albeit smaller, improvement over RMOP. Lastly, \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Scene** & **UAV Num** & **Method** & **Reward** & **Budget** & **WBV** & **Runtime (ms)** \\ \hline City & & RMOP & 121.8 & 72.4 & 24.3 & 51 \\ \(|\mathcal{V}|=18\) & 3 & RMOPWB\({}^{1}\) & 121.8 & 66.5 & 23.4 & 192 \\ \(|\mathcal{E}|=22\) & & & RMOPWB\({}^{2}\) & 121.8 & 64.8 & 23.6 & 76 \\ \hline City & & RMOP & 228.5 & 125.3 & 26.1 & 95 \\ \(|\mathcal{V}|=18\) & 7 & RMOPWB\({}^{1}\) & 228.5 & 95.9 & 22.9 & 403 \\ \(|\mathcal{E}|=22\) & & & RMOPWB\({}^{2}\) & 228.5 & 91.4 & 23.0 & 151 \\ \hline City & & RMOP & 298.7 & 187.6 & 25.6 & 176 \\ \(|\mathcal{V}|=18\) & 11 & RMOPWB\({}^{1}\) & 298.7 & 122.5 & 21.1 & 783 \\ \(|\mathcal{E}|=22\) & & & RMOPWB\({}^{2}\) & 298.7 & 128.0 & 21.9 & 212 \\ \hline Maze & & RMOP & 82.1 & 56.7 & 28.3 & 42 \\ \(|\mathcal{V}|=15\) & 3 & RMOPWB\({}^{1}\) & 82.1 & 50.1 & 27.9 & 141 \\ \(|\mathcal{E}|=20\) & & & RMOPWB\({}^{2}\) & 82.1 & 51.8 & 27.1 & 59 \\ \hline Maze & & RMOP & 155.6 & 79.6 & 30.8 & 78 \\ \(|\mathcal{V}|=15\) & 7 & RMOPWB\({}^{1}\) & 155.6 & 64.2 & 26.8 & 286 \\ \(|\mathcal{E}|=20\) & & & RMOPWB\({}^{2}\) & 155.6 & 62.5 & 25.6 & 109 \\ \hline Maze & & RMOP & 218.9 & 116.8 & 32.7 & 116 \\ \(|\mathcal{V}|=15\) & 11 & RMOPWB\({}^{1}\) & 218.9 & 72.2 & 25.8 & 529 \\ \(|\mathcal{E}|=20\) & & RMOPWB\({}^{2}\) & 218.9 & 70.9 & 27.3 & 161 \\ \hline \hline \end{tabular} The distinction between RMOPWB\({}^{1}\) and RMOPWB\({}^{2}\) is whether the \(K\) Monte Carlo sampling steps in Algorithm 1 are performed with parallel processing. RMOPWB\({}^{2}\) utilizes parallelization, while RMOPWB\({}^{1}\) does not.  
\end{table}