Multi-Agent Development
Here you can find an overview of our current and past multi-agent development projects.
Last updated
Here you can find an overview of our current and past multi-agent development projects.
Last updated
This branch of our research has only recently begun! Stay tuned for new projects in the future. For now we have listed our current preliminary findings to provide insight into the direction we are heading.
This branch of our research focuses on the process of using multiple robots to create a map of an area while also sharing that map with every agent. As a result, this problem can be broken down into the two focus areas of exploration and map merging. With map exploration, we are trying to create a system that dictates the locations that the robots will explore, as well as those that will be most efficient in developing a global map. Meanwhile, the concept of map merging focuses on the development of a process that will accurately piece together the global map.
When testing these processes, we chose to use Gazebo as a means to simulate multiple robots working together to map a single area. Specifically, we used the Turtlebot3 Burger and the turtlebot3_house environment as our testbed setting. Based on measurements performed in the Gazebo environment, this setting will require approximately 96.335127 square meters to be mapped between the three robots. In addition, to help speed up the evaluation of map merging packages, we made sure to use rosbag to record the individual robot map messages. This way, we could replay the scans and isolate any changes in performance to parameters that we explicitly set in our launch files.
If you would like to further explore the development environment we used for testing multi-agent communication, please visit this Github repository and clone it to your computer.
Currently, our testing of map merging has revolved around our usage of themultirobot_map_merge. This package is designed to subscribe to individual OccupancyGrid and OccupancyGridUpdates messages from each mapping robot, and publishes a combined map based on feature-matching. While it is possible to include the initial odometry, we chose to ignore this information in order to get a better idea of how well the node works in a "blind" environment. However, the downside of this approach is that this requires our robots to produce overlapping scans of the same area in order for the algorithm to find a high-probability match.
In addition to map merging, we have also begun researching exploration strategies that can be used to direct the robots towards unexplored areas as a means to efficiently generate a new map. This practice is known as "frontier exploration" and is defined as a practice where we direct the robot towards open spaces that have yet to be mapped. These spaces, or "frontiers," are determined by costmaps that can depict open spaces, boundaries, and unmapped spaces. If there is a boundary that consists of an open space and an unmapped space, then that is a frontier that the robot should explore [1]. Given the efficiency that is presented by this idea, we chose to pursue practices that used some form of frontier-exploration in order to build a local map that could later be merged by the map merging node. At this point in time, we have tested explore_lite, a node that implements frontier-exploration algorithms to create a map. While this has been shown to be efficient on a local front, there are issues with its lack of coordination that we are looking to solve.
In addition to the software side of multi-agent-mapping, we also researched different network topologies that would be beneficial for our goals. Specifically, we focused on mesh networking and a star topology. With mesh networking, it is possible to decrease the impact of range on our robot's communications as each device can focus on routing messages, instead of connecting to a singular router that may be further away. Meanwhile, a star topology could also solve this problem given that each of the connecting devices have a large enough range to work with.
This summer, most of our testing around networking has been with the XBee Series 2 and the Zigbee protocol. While the devices do support mesh networking, in reality we have mostly been working in a Point-To-Point topology. The advantage of using the XBee Series 2 Pro, instead of a traditional router, is that we are able to get a great deal of range out of a small form factor. However, this comes with a tradeoff that manifests in the form of a limited bandwidth. This can make it difficult to send data such as images, videos, or any other large messages over the network with limited latency. We did begin to research other hardware that we could use to help connect the robots, and we found that most of these devices focused on using a star topology instead of the mesh networking we would wish to employ.
[1] B. Yamauchi, "A frontier-based approach for autonomous exploration," Proceedings 1997 IEEE International Symposium on Computational Intelligence in Robotics and Automation CIRA'97. 'Towards New Computational Principles for Robotics and Automation', Monterey, CA, USA, 1997, pp. 146-151, doi: 10.1109/CIRA.1997.613851.
