GSOC 2023: Multicopter swarm avoidance

Introduction
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.

Proposed work
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.

12 Likes

Really interesting
I did some Swarming Stuff a few years ago in this series of blogs

Will follow your progress and might be interesting to continue experimenting as well :wink:

1 Like

Yes, I read all blogs from that series. Those were really informative :slight_smile:.

2 Likes

Cool,
Funny I was reading this earlier this week

“The majority of current research on swarms follows the same pattern and either relies on offline computation or uses simple rule-based logic such as ‘don’t bump into your neighbor while following the leader.’ Computers are great at fast computation and implementing tactics, but humans can excel at strategic decision making. We want to combine these,” said Becker.

Great project, looking forward to seeing what comes out of it!

You might be interested in the avoidance algorithms we’ve developed and published earlier; the experiments described in these papers were performed using custom-built drones running a modified ArduPilot 3.6.x firmware. The avoidance algorithm itself was running on a companion computer.

We are also doing light shows and maintaining a fork of ArduCopter specifically tailored for drone shows so it would be great to see something like this implemented directly in ArduCopter.

2 Likes

Progress Update

Greetings, Ardupilot Community! I hope this blog post finds you well. I am excited to provide you with an update on my project. As mentioned in my previous blog post, my project focuses on developing multicopter swarm avoidance capabilities within the Ardupilot ecosystem. Let’s delve into the progress I have made thus far.

1. A central location database added

One of the crucial steps towards achieving our goal involves the storage of location information for objects to be avoided within the swarm. While Ardupilot already includes several databases that store location and position data for vehicles from various sources, we have taken a significant leap forward in this project. **We have implemented a robust global location database** (we call it location database but it also stores vital data like velocity, acceleration, and heading of objects). Yes, we agree that this is flash costly but this database offers numerous benefits.

Firstly, it allows the seamless availability of information to multiple libraries simultaneously. For instance, we can utilize the information stored in the database to avoid specific vehicles while simultaneously tracking or following another vehicle of choice. Furthermore, we can leverage this information to precisely point a gimbal at a specific object (a potential future development if time permits). By providing the relevant key associated with the object to be tracked or followed, users can effortlessly access the desired information from the location database. Notably, we have already made modifications to the AP_Follow library, enabling it to utilize the information from the location database to efficiently follow selected vehicles. Further details regarding this enhancement will be discussed in the subsequent paragraphs.

Furthermore, the database serves as a centralized repository for storing information from diverse data sources, consolidating it in one convenient location. Presently, we have incorporated support for storing information from MAVLINK messages such as GLOBAL_POSITION_INT and FOLLOW_TARGET, as well as from ADSB sources. It’s important to note that this implementation does not immediately replace existing databases, like the one in AP_ADSB, within the relevant libraries. However, our vision is to explore ways in which the global location database can eventually fulfill the role of these library-specific databases and completely supplant them. One potential approach could involve incorporating backends into the location database to accommodate the storage of specialized additional information specific to each data source.

The advantage of aggregating information from different sources is that various libraries consuming this type of data can now utilize information from any supported source. For example, the AP_Follow library can now seamlessly track ADSB vehicles, expanding its functionality beyond vehicles publishing information solely through MAVLINK. In the future, if we successfully integrate AIS data or the opendroneid data as a source within the location database, the same library would be able to track vehicles utilizing that data as well. This integration opens up possibilities for enhanced compatibility and versatility across different data sources for improved performance and functionality.

Additionally, we have conducted thorough unit testing of the database to ensure its seamless functionality and robustness. By implementing rigorous testing, we can confidently assert that the database is operating as expected. These tests not only verify the current performance but also serve as a safeguard against any potential future breakdowns. In the event of any issues, our testing framework allows us to promptly identify and rectify them, ensuring the reliability and stability of the database in the long run.

2. Mavproxy module to see location database data

Once the location database was successfully implemented, our subsequent objective was to develop a Mavproxy module that would allow us to visualize the data stored in the database and display the objects/vehicles on a map. To achieve this, we initially implemented an AP_Filesystem backend, enabling Mavproxy to fetch the relevant information from the location database through FTP. Subsequently, we proceeded to write the Mavproxy module, which parses the retrieved data and provides visual representation on the map.

To optimize the data transfer process, we implemented a mechanism to transmit only the fields that are populated for each item. For example, if we lack information about the velocity of a particular vehicle in the location database, we do not transfer the velocity field for that item. This selective transfer approach reduces the size of each item, making the overall process highly efficient. At present, the module is functioning well, but we are looking to further enhancing its efficiency in transmitting information.

These visuals provide a glimpse of the module’s functionality and its ability to present the stored data on a map.

3. Enhance AP_Follow to use location database information to follow vehicles

As part of our efforts to showcase the advantages of the global location repository, we have implemented enhancements to the AP_Follow library. This enhancement allows the library to utilize information from the location database, enabling it to track vehicles from all supported sources. We have introduced a new parameter that provides flexibility for users to choose whether they want to follow a vehicle exclusively through MAVLINK or utilize the location database to specify the vehicle to be followed.

Based on the user’s selection using this parameter, they can either provide the MAVLINK sysid or the location database key to initiate vehicle tracking. Extensive testing on the SITL platform has demonstrated the successful operation of this feature. To further illustrate its functionality, we have prepared a video demonstration showcasing a user selecting a location database item to follow, resulting in the vehicle initiating its follow behavior.

4. Vehicle avoidance in Auto and Guided Mode

Now let’s discuss our primary objective: enabling a vehicle to avoid other vehicles in its vicinity. With the information stored in the location database about all nearby vehicles, we can seamlessly integrate it into the AC_Avoidance library to facilitate effective avoidance maneuvers. The initial approach we adopted was to enhance the bendy ruler algorithm, which proves to be a suitable option for this purpose. The algorithm already demonstrates successful avoidance capabilities in AUTO mode and GUIDED mode.

By leveraging the information from the location database, we have improved the bendy ruler algorithm to effectively avoid vehicles in its path. Initial tests conducted in the SITL environment have yielded good results. The vehicle successfully avoids nearby vehicles, showcasing the algorithm’s efficiency. While the algorithm performs admirably when encountering stationary objects, adjustments were made to the lookahead parameter to ensure that the vehicle anticipates and avoids fast-moving objects in a timely manner. This proactive measure helps prevent potential collisions.

We are pleased to share some images captured during the SITL tests, illustrating scenarios where two vehicles approaching each other head-on successfully avoid collision:




Here is another video of a copter avoiding another copter in AirSim environment.

These visuals provide a clear demonstration of the improved bendy ruler algorithm effectively enabling avoidance behavior between vehicles. The results achieved thus far are encouraging, and we will continue refining and fine-tuning the algorithm to enhance its performance even further.

Next tasks

Moving forward, we have outlined several key tasks to advance our project:
  • Enhancing the Mavproxy Module: Our focus will be on refining and expanding the functionality of the Mavproxy module. We aim to add additional features, and optimize the transfer efficiency of information from the location database.

  • Expanding Source Support in the Location Database: Currently, the location database incorporates information from MAVLINK messages and ADSB sources. Our next step is to broaden the support by integrating additional sources like AIS.

  • Implementing Multicast Support in Mav_ESP8266: In order to enhance real-world connectivity among vehicles, we will explore adding multicast support to the Mav_ESP8266 firmware. This improvement will enable multiple vehicles equipped with these radios to establish seamless connections, fostering efficient communication in practical scenarios.

  • Advancing Avoidance Algorithms: We are committed to further refining and improving the avoidance capabilities of the system. In addition to enhancing the bendy ruler algorithm, we will explore the utilization of other avoidance algorithms, such as the simple avoidance algorithm.

I am extremely grateful to my mentors, @peterbarker and @rishabsingh3003, for their support and guidance throughout this project. Thank you for always helping me whenever I got stuck and for answering my (never-ending) questions. I look forward to continuing my collaborative journey on this project with them and delivering increasingly valuable results.
Thanks!

7 Likes

Looking forward to your progress. Will the code run on the newer type ESP32’s (C3, S2, S3 etc.) too? The ESP8266 start to get dated…

@shiv-tyagi can correct me if I am wrong, but I think the current plan is to work on top of GitHub - tridge/mavesp8266: ESP8266 WiFi Access Point and MAVLink Bridge, which doesn’t support ESP32

1 Like

Yes, right. That’s the plan.

1 Like

Hi shiv-tyagi! Great project!

I just want to give you an idea. Maybe it inspires you.
Think for a moment not of flying quadcopters but maybe of a swarm of drone boats. Drone boats might not only avoid each other but they might also seek each other. Think i.e. of a swarm of waste-collecting boats. These might not just stay away from each other but they might also build a row formation, a very close diagonal formation like gooses like to fly, or a train-formation one following another one in a close proximity row.
They even might attach to each other somehow.
Maybe these ideas inspire you for your work, or some of your ideas might apply to these use cases. Just saying.

3 Likes

There’s at least one fork of mavesp8266 on Github that supports ESP32 (see here ) and I believe it should be relatively easy to merge it back to upstream if there’s interest in supporting ESP32 in the long-term. I am definitely considering it to merge it back into our own fork.

1 Like

Final Blog Post: Wrapping Up an Exciting Journey

Greetings, Ardupilot Community! As we approach the culmination of an incredible journey, I am delighted to share the final update on the multicopter swarm avoidance project that I’ve had the privilege of working on during this year’s Google Summer of Code. From the initial steps to the latest developments, this blog post will encapsulate the progress, challenges, and achievements we’ve encountered along the way.

From the outset, this project aimed to enhance the capabilities of Ardupilot in enabling drones to navigate safely within swarms while avoiding collisions. Working alongside my mentors, @peterbarker and @rishabsingh3003, has been an enriching experience that has significantly shaped the project’s trajectory and outcomes. In this final update, I will provide an overview of the accomplishments achieved, the lessons learned, and the path forward as we embrace the project’s conclusion.

1. Multicast support for MAVESP8266 Implemented

One of the significant advancements achieved in this project is the successful integration of multicast support into the MAVESP8266 firmware. This improvement facilitates seamless information sharing among multiple vehicles and ground control stations (GCS) within a network using multicast communication.

To use multicast, the user needs to connect to the esp8266 module and open the setup page for the module on the web browser. While configuring the setup, users need to select the Station interface - a crucial step as multicast on ESP8266 is exclusively supported through the Station interface. After this, users specify the multicast group IP and port number for sending and receiving data packets.

To further enhance usability, two multicast modes have been introduced: Full Multicast and Conservative Multicast. The Full Multicast mode encompasses the exchange of all types of packets within the multicast group, including various MAVLink traffic. However, this approach can potentially saturate the ESP module and lead to packet delays when there are many vehicles on the network. Addressing this, the Conservative Multicast mode has been introduced. This mode focuses solely on the exchange of GLOBAL_POSITION_INT and FOLLOW_TARGET messages, which are pivotal for sharing vehicle locations for follow and avoidance purposes. This streamlined approach ensures efficient data transfer without unnecessary traffic, enhancing overall performance. Of course, this functionality can also be achieved by adjusting the MAVLink stream rates on the autopilot and allowing only these specific messages on designated channels. However, I firmly believe that providing a dedicated mode for this within the ESP firmware offers significant user benefits. Users can conveniently restrict unwanted traffic with a simple click, promoting a more user-friendly experience.

To implement this functionality, users set the multicast IP, port, and select the appropriate casting mode. Subsequent to these configurations, a reboot of the MAVESP8266 is required. Once completed, vehicles actively emit and listen to messages within the same multicast group and port can seamlessly exchange location information.

I have already tested this functionality on my own vehicles as well as with SITL (by connecting a real rover with multiple SITL copter instances using multicast), and the results have been highly promising. Additionally, I have submitted the pull requests for this feature, which I am confident will be merged into the ArduPilot’s mavesp8266 repository soon.

2. Implementation for AP_LocationDB added

Continuing from my previous blog posts, I am thrilled to share the successful implementation of a global repository designed for the storage of remote vehicle knowledge. This database serves as a foundational component within our project, enabling efficient sharing and retrieval of critical information. While I won’t delve into exhaustive details, as I’ve extensively covered this in earlier posts, I will highlight the significant developments we’ve achieved, especially since the mid-term evaluations.

A pivotal advancement made to the location database was the incorporation of support for performing fundamental CRUD (Create, Read, Update, Delete) operations through scripting. This enhancement has profound implications, allowing users to seamlessly push items into the database and retrieve them using Lua scripts. This functionality holds immense potential for various applications. For example, we can estimate the position of an object we are looking at using the ‘mount-poi’ Lua script and subsequently store this data in the database. This opens avenues for future utilization, such as using these stored items for circling purposes and beyond.

I am pleased to share that the pull request (PR) for merging the location database has already been submitted and I am confident that it will soon be merged into the main repository.

3. Follow Mode Improvements

As previously highlighted in my updates, significant strides have been made in enhancing the follow mode functionality within our project. While the core aspects of these developments were discussed before, I want to address the refinements and progress that have occurred post mid-term evaluations.

Although no major new features were introduced to the follow mode after the mid-term evaluations, the focus shifted towards meticulously polishing the functionalities established prior to that point. The objective was to fine-tune and optimize the user experience, ensuring seamless transitions and intuitive operations for both users and vehicles alike.

The PR to merge these changed into the master has been already submitted and is currently under review.

4. MAVProxy module for viewing LocationDB items

In alignment with my prior blog updates, I am delighted to present the successful development of a MAVProxy module that serves as a dynamic interface for visualizing Location Database (LocationDB) items. This module, a topic of previous discussions, has now undergone refinements and enhancements that bring us closer to our goals. While a comprehensive overview was provided in earlier posts, I’d like to highlight key progressions since the mid-term evaluations.

The MAVProxy module designed for the Location Database has proven to be an invaluable tool, enabling users to effortlessly list and display items stored within the database directly on a map interface. This feature streamlines the process of visualizing the location and status of various objects, enhancing situational awareness.

A significant advancement introduced post mid-term evaluation is the integration of a user-friendly feature. Now, when a vehicle operates in follow mode, users can seamlessly command the vehicle to follow a specific Location Database item with a single click. This enhancement significantly augments the user experience, enabling seamless switching between the objects that users wish to follow.

To visually demonstrate these developments, a concise video clip showcasing a Sitl (Software in the Loop) demonstration is posted below.

In this video, for quick testing purposes, I have simulated few copters circling near the main copter by using a simple python script to send fake GLOBAL_POSITION_INT messages to the main copter using pymavlink. The information contained in those messages is then stored in the location database and is visible on the mavproxy using the new locdb module. That module can be used to seamlessly switch between the vehicles to follow.

The pull request (PR) for merging this module into the ArduPilot’s mavproxy repository has been submitted and is currently under review.

5. Avoidance using BendyRuler

Following the mid-term evaluations, a significant portion of our efforts was directed towards refining and finalizing the establishment of multi-vehicle avoidance capabilities in auto and guided modes. This pivotal phase involved an extensive array of activities, encompassing comprehensive Sitl tests, simulations in AirSim (a 3D simulator), and practical tests conducted on real vehicles.

Throughout this post mid-term phase, we delved deep into optimizing and validating the implementation of the BendyRuler algorithm for multi-vehicle avoidance. This involved Sitl tests to simulate and validate avoidance scenarios. Additionally, we leveraged the capabilities of AirSim, a 3D simulator, to further verify the efficacy of our avoidance mechanisms.

Furthermore, I am excited to share a significant development facilitated by CubePilot (@proficnc), who generously sponsored a copter for our real vehicle testing. This generous support allowed us to conduct practical tests on real vehicle. The testing involved equipping both the copter and my rover with ESP modules to establish communication. With the copter flying at low altitudes over the rover, the goal was to ascertain the avoidance capabilities in real-world conditions. The results were highly promising, with the vehicle efficiently avoiding the rover, showcasing the real-world applicability of our avoidance enhancements.

Here are a couple of videos of AirSim and real vehicle tests.

Real vehicle test video

6. Future Improvements
i. Enhanced avoidance algorithm for Fast-Moving Vehicles: The BendyRuler avoidance algorithm has shown remarkable potential, but its efficiency in rapidly changing environments, particularly with fast-moving vehicles, can be further optimized. Future efforts will be dedicated to refining the algorithm to bolster its ability to navigate through dynamic and swiftly changing scenarios, ultimately expanding its scope of application.

ii. Efficient Database Item Transfer to GCS: While our current method of utilizing MAVFTP for location database item transfer has proven effective for smaller datasets, there’s room for improvement when dealing with larger quantities of items. We currently send read requests to vehicle, for database items, at regular intervals. As the number of items increases, individual FTP requests become time-consuming and susceptible to failures. Decreasing the frequency of fetching the database can be one solution to this problem. However, we could think of other efficient ways to transfer a large the location database items to the gcs at regular intervals.

iii. Streamlined Database Management (Eliminating Existing Databases): There are existing databases to store the items received over ADSB and AIS in the vehicle. Those database have fields which are specific to each source. We can look for ways to potentially eliminate those databases and store the information only in the new location database. One approach to achieve this could involve setting up individual backends for all potential information sources, coupled with a frontend that establishes a generalization of the information. This frontend would provide common information available from all sources, promoting greater coherence and efficiency in data management.

In concluding this journey, I extend my heartfelt gratitude to the entire ArduPilot community, my mentors, and everyone who supported me throughout this remarkable experience. The progress we’ve made together is a testament to collaborative dedication. I eagerly anticipate the opportunity to continue contributing to ArduPilot’s advancement and innovation. Thank you for being a part of this inspiring journey.

6 Likes

hi. i want to test swarm in real fly. where i can get esp12 binaries with conservative multicast mode? in official repository only old version 3 years old

Hey! That PR is still not merged sadly. You can find the source here.
This one does not include conservative multicast mode though. We dropped the idea of merging that because that can be done through other ways as well. If you are still interested in trying it out, you can find it here.

Remember, be very cautious while trying out avoidance on real swarm. It has not been tested in real. The bendly ruler algorithm which we used does not perform very well with fast moving vehicles.
Good luck!

Thank you! I correctly understood: if I use the new arducopter AP_LocationDB library in pixhawk with old ESP firmware in wifi modem. or new esp firmware in wifi modem with standard Arducopter firmware in pixhawk ? are these two different methods?

I didn’t understand your query properly.

The esp firmware facilitates the communication among the drones flying in a swarm. The location database stores that information. So you will have to use the new esp firmware on wifi module and install the firmware having the AP_LocationDB code on the pixhawk.
I hope I was able to explain it to you.

Thank you, now everything is clear. the master plays the role of a server and sends commands where the others should follow, apparently the master drone should use f7/h7 MCU to be able to control the shape of the swarm (left/right up/down position and distance of each node) through scripting, and the rest can be based on old MCUs because they only need to execute the “follow to” command

If you are willing to test the follow me thing, the master won’t even need the location database. Because the master would just be emitting its position data. It does not need to know about its followers. However, the followers would need to know about the master and hence would need the location database to store its location. And then that location entry can be used by the follow library to follow the master with the required offset.

First I’ll try the standard follow mode (Follow Mode — Copter documentation), with a Wi-Fi access point in conservative multicast mode installed on the master drone. and I will control the master via long range r/c. This will allow the Wi-Fi network to move with the swarm

1 Like

@Alexey_Kozin I’ve built the binaries with the conservative multicast mode for your convenience. You can find them here.

You can find the documentation to help upload the firmware to the module here.

1 Like