2018
Swarm demo in AirSim
A swarm of KUKA YouBot's base simulated in Gazebo
As a member of the Sprinter team for DARPA OFFensive Swarm-Enabled Tactics (OFFSET) Program, I am currently developing swarm robotics simulation at Cornell University Autonomous Systems Lab (ASL).
The goal is to simulate a decentralized swarm of 250 air/ground robots in an urban setting on different simulation platforms such as Gazebo, Unity, and AirSim.
My contribution includes: 1) integrating discrete controller synthesis, continuous controller implementation, and simulation platforms into a single pipeline 2) improving continuous controller implementation 3) realize decentralization using multiprocessing and cloud computing services.
The simulation pipeline needs to have an architecture that supports the same set of inputs and controller on different platforms. The platforms we used, Gazebo, Unity, and AirSim, have different interfaces for controlling the robots.
Gazebo
This flow chart shows the simulation pipeline using Gazebo. The orange blocks are the input to the simulation, the green blocks are the pipeline components specific to Gazebo, and the blue blocks are independent pipeline components. The orange and blue blocks are the same for Unity and AirSim.
Velocity commands are sent to robot models in Gazebo using rostopics, and the location of each robot can be obtained by subscribing to model states from the Gazebo world.
A map example for executing tasks
RQT graph of a swarm of three robots in Gazebo
AirSim
Velocity commands are sent to robot models in AirSim using rosservices, and each robot has a simulated GPS for giving our Longitude, Latitude, and Altitude, which are then converted to x y z positions.
Swarm demo with 4 robots in AirSim
The continuous controller implementation considers three aspects: nominal controller, collision avoidance and region invariance, and deadlock mitigation [1]. In this paper, the controller is implemented on Sphero. However, when it is implemented on larger robots such as KUKA YouBot and Drones in smaller maps in Gazebo or AirSim, blocking might happen when a robot has reached its goal and blocks latter robot from going forward. Also since no padding was added to the walls for path-wall-intersection calculation, the robots actually end up rubbing against the walls when trying to avoid collision. I improved the continuous controller implementation to address these problems by the following:
Instead of using the same goal position for all robots heading to the same polygon region, each robot's goal position is a randomly selected point inside this goal region. This effectively prevents blocking from happening when region is large compared to the size of robots.
To avoid collision with the walls, I calculate the intersection between robot's path and four padding lines around the wall instead of the wall itself.
-077.png)
I integrated continuous controller into simulation and scripted tools for automatically generating URDFs of maps and walls in Gazebo, as well as for scaling and translating maps in AirSim.
Currently even though the controller for each robot is calculated based on a decentralized model, the communication between each robot is still implemented in a centralized manner, i.e. a single script collecting all model states from simulation world and pass them to each robot's controller in a loop.
To accurately simulate a decentralized swarm, I am exploring multiprocessing libraries in an attempt to run each robot's controller as a separate process. Also I am working on integrating Amazon Web Services to be used as controllers to take advantage the capability of using multiple machines on ROS.
[1] J. Chen, S. Moarref, and H. Kress-Gazit, “Verifiable Control of Robotic Swarm from High-level Specifications” [Online]. Available: http://ifaamas.org/Proceedings/aamas2018/pdfs/p568.pdf. [Accessed: 01-Dec-2018].