We have worked on integrating our GUI (which we previously integrated with our algorithm for solving the mTSP) with the actual hardware while it is executing in real-time. Afterwards, besides testing our system as a whole, we also tested our genetic algorithm for solving the mTSP on a larger scale than required by our current project.
Overall System
We assembled our testing setup of the 5 stores and our 2 robots in the lab as shown in figure 1. Accordingly, we edited our GUI to reflect the final locations of the stores, as shown in figure 2.
Figure 1: Our testing setup of 5 stores and 2 robots in the lab.
Figure 2: Updated store locations in our GUI design.
We then integrated our GUI with the ROS environment. The GUI is now aware of the robots’ positions and headings at all times; which means the GUI’s plot is now updated in real-time as shown in figure 3. In addition, given the current positions of all robots and stores, the estimated time of arrival (ETA) of each robot to each assigned store is calculated. Hence, the GUI’s tracking panel is appropriately updated as also shown in figure 3.
Figure 3: GUI’s tracking panel and plot updated according to robots’ current positions & headings.
Next, we tested that each of our robots was able to receive the list of stores assigned to it. We then tested how well they were capable of navigating to those desired stores. As evident in figure 4, we needed to carry out significant tuning of the controllers’ gain parameters in order to make sure that the robots followed the desired paths. Several issues arose due to:
- Wheel Slippage
- Low Battery Capacity
- Motion Capture Occlusion
- Wheel Axes Miss-Alignment
(a)
(b)
Figure 4: (a) Robots follow the initial path well. (b) One of the robots struggle to re-orient in order to move towards the next path point
Larger Scale Testing of mTSP
Instead of 5 stores and 2 robots, we tested our algorithm for 20 stores and 5 robots. We experimented with population sizes of 30, 80 & 130. We also compared between 3 different sets of CR & MR:
- 0.5MR0.5CR
- DHM/ILC (MR: 0.9375 –> 0.0625, CR: 0.0625 –> 0.9375)
- ILM/DHC (MR: 0.0625 –> 0.9375, CR: 0.9375 –> 0.0625)
For every configuration, we ran the algorithm 10 times and recorded the average:
- optimal Min-Max time
- generation number of optimal solution
- computational time
The results were as shown in figure 5.
(a)
(b)
(c)
Figure 5: Results of a large scale testing of our mTSP.
As can be seen from figure 5(a), the results associated with different sets of MRs & CRs were very close. It can be noticed though that as we increase the population size, the algorithm is able to arrive at a slightly more optimal solution. This makes sense because a greater population size allows the algorithm to perform a broader search and assess the fitness of a larger number of solutions (individuals) every iteration of the algorithm. For the same reason, we can see from figure 5(b) that as the population size increases, the algorithm arrives at the optimal solution at an earlier generation. It can also be noticed that the 0.5MR0.5CR version arrived at the solution at overall earlier generations. This means that the algorithm was able to terminate faster, which justifies why the computational times associated with this version were less as shown in figure 5(c). Figure 5(c) also shows that as the population size increases, the algorithm’s computational time increases. This is very intuitive since, as stated earlier, a larger population means a greater number of individual solutions are evaluated every iteration.
Future Work
In the future, we would like to:
- Relax some assumptions of the MRTA algorithm to more realize the problem:
- Consider battery life
- Consider amount of sanitization liquid
- Consider robot heading
- Consider static obstacles in the environment (example: booths in the mall)
- Carry out further tuning/controlling of the GA parameters
- Simulate 20 robots on Gazebo/Webot
- Apply our algorithm to existing sanitization bots
Multi-Agent Robot System for Mall Sanitization 