Greetings, Ardupilot Community! I am Shiv Tyagi, hailing from Delhi, India. Participating in Google Summer of Code with Ardupilot last year was an incredible experience for me. I am thrilled to announce that I have been given the chance to participate in GSoC 2023 once again, with Ardupilot. I would like to express my heartfelt gratitude to my mentors, @peterbarker and @rishabsingh3003, for their trust in me and for providing me with this opportunity once more. I am filled with anticipation for another enriching learning journey and the creation of lasting memories this summer. During this program, I will be working on multicopter swarm avoidance project. In this blog post, I will provide a brief overview of the work we have planned and kindly request your valuable feedback on our endeavors.
Multicopter swarming has a wide range of applications, including drone light shows, search and rescue operations, and delivery services. However, safety is a critical concern when drones are flying in a swarm. This project aims to enhance the capabilities of ardupilot to enable drones to fly in swarms while avoiding collisions with each other.
The main objective of this project is to improve the arducopter firmware such that it can identify the positions of other drones in a swarm, store the data in a location database, and enable the drones to avoid each other by using the AC_Avoidance class.
Accomplishing the aforementioned task broadly entails three key elements. The first step involves establishing communication links among the vehicles. The second aspect revolves around storing the location data of neighboring vehicles within each individual drone. Lastly, leveraging this collected data to effectively avoid collisions and ensure safe maneuvering. Below, I will outline the proposed approaches for each of these crucial steps.
– Communication between vehicles –
WiFi multicasting is a method of sending data packets from one sender to multiple receivers over a wireless network. It is efficient in conserving network bandwidth by transmitting the same data to multiple devices at once, reducing the need for individual data transmissions to each device.
Hence, we can use wifi multicasting to transmit and listen to position messages by the vehicles on the network. There are already certain examples of establishing communication among vehicles using multicast. The following scripts in ardupilot tree serve good example for multicasting mavlink messages from a vehicle:-
ESP8266 is a cheap and easily available wifi radio. It can be used as a bridge to connect a GCS to a vehicle over wifi. ESP8266 connected to the vehicle over its serial interface and then relays the mavlink messages to and from the vehicle over wifi. The radio can be loaded with the mavesp8266 firmware and can be used to configure and enable communication between the vehicles. However, the firmware currently only allows unicast communication links.
The firmware can be modified to emit and subscribe to the multicast messages over a multicast group ip and relay the communication to the vehicle. I would also work on adding multicast support to the mavesp8266 firmware as a part of this project
– Storing the location of neighboring vehicles –
To effectively store the location information of neighboring objects, I propose the implementation of a global repository or database. This repository will serve as a centralized storage system capable of receiving location data from various vehicles and objects through relevant information sources. Each entry in this database will be associated with a unique key, allowing for easy identification of objects. To maintain the integrity of the database, the libraries responsible for feeding information should carefully manage the keys and ensure their uniqueness. It’s worth noting that this location database has versatile applications beyond just collision avoidance, including object tracking and targeting. The consumer of the information only needs to possess the key corresponding to the object they wish to track, follow, or avoid. To ensure the reliability and proper functionality of all components, I will be writing multiple unit tests for this database, enabling us to detect any unexpected behavior resulting from code changes in future.
– Avoiding the neighboring vehicles –
This is the last but the most important part of the project. The algorithm referred to as the “bendy ruler” in the AC_Avoidance library effectively avoids obstacles that are stored in the OA_Database. In light of the previous discussion regarding the integration of a global location database, it is feasible to store vehicle information within that database, which the bendy ruler algorithm can then utilize to evade such obstacles. However, modifications to the bendy ruler algorithm might be needed given that vehicles also have velocity associated with them.
An additional algorithm at our disposal is the “simple avoidance” algorithm. Presently, this algorithm is capable of real-time avoidance of objects through proximity sensors without any recorded storage of the objects. However, in order to extend the functionality of the simple avoidance algorithm to include nearby vehicles, integration with the location database is necessary. While currently only utilized in manual modes, it is conceivable to investigate the behavior of the vehicles by utilizing this algorithm in automatic modes. At present, the simple avoidance algorithm simply halts or glides along encountered obstacles, but there is potential to augment this algorithm to include the capability of retracting if the vehicle is in close proximity to other nearby vehicles.
The aforementioned location database would also be leveraged by the AP_Follow library for following objects.
– Testing –
In order to ensure effective testing of the project, a systematic approach should be used. Initially, efforts will be focused on the development and testing of the new location database and writing good unit tests to ensure error free working of the operations on the database. Apart from the unit tests, the existing follow library would be serving as the primary testing platform. The objective of this preliminary testing phase is to determine the feasibility of utilizing one vehicle to track another in a simulated environment.
Subsequently, the location database will be integrated with the avoidance algorithms for further testing. Specifically, the goal of this phase is to evaluate the capability of the avoidance algorithms to effectively avoid nearby vehicles in a simulated environment. Additionally, this phase will also facilitate the assessment of the communication between vehicles over MAVLink using multicast (in SITL).
As a next step, testing will be conducted to evaluate the functionality of multicast on ESP8266. This testing phase will involve launching multiple SITL instances in order to simulate a real-world scenario and assess the ability of the vehicles to share information with one another via multicast over ESP8266.
Finally, a real-world test will be conducted utilizing a physical vehicle to assess its response to simulated vehicle data. Specifically, fake GLOBAL_POSITION_INT messages will be generated and transmitted to the vehicle, simulating the presence of nearby vehicles. The vehicle’s response to this simulated data will be carefully observed and analyzed, in order to assess the effectiveness of the implemented algorithms in real-world scenarios. I also intend to conduct tests involving a copter and a ground-based rover. By adjusting the avoidance radius, I will examine whether the copter successfully avoids entering the designated sphere around the rover. This testing methodology will enable us to assess the accuracy and reliability of the avoidance mechanism.
Once again, I would like to thank the whole ArduPilot community for always being supportive. Your feedback and suggestions on the project are always welcome. Feel free to post your thoughts here. Thank you so much.