WiSwarm: Age-of-Information-based Wireless Networking for Collaborative Teams of UAVs

AoI is an end-to-end metric that characterizes how old the information is from the perspective of the destination [18]. Consider a multi-agent system in which updates from followers are time-stamped upon generation. Let $\tau_{i}(t)$ be the largest time-stamp of an update from follower $i$ received by the leader by time $t$. The AoI associated with follower $i$ is defined as $A_{i}(t):=t-\tau_{i}(t)$. The AoI increases linearly with time when no updates are delivered, representing the information getting older. At the moment a fresher update from follower $i$ is received by the leader, the value of $\tau_{i}(t)$ increases and the AoI reduces to the delay of the received update. This evolution of the AoI metric with time is illustrated in Fig. 3.

Over the past decade there has been a rapidly growing body of works analyzing AoI in different contexts (see surveys in [19, 20, 21]). Several theory-oriented papers have analyzed AoI in queuing systems [18, 22, 23, 24, 25, 26] and proposed novel network control mechanisms [27, 28, 29, 30, 31, 32, 33] that could potentially be leveraged in real-world applications.

More recently, a few works [34, 35, 36, 37, 38, 39, 40, 41] have considered system implementations. These system-oriented works can be separated into two categories: (i) measurement of AoI in real networks [34, 35]; and (ii) evaluation of communication networks that attempt to minimize AoI by looking at congestion control [36], traffic engineering [37], and medium access using Software Defined Radios (SDRs) [39, 40, 41, 38]. However, there has been no prior work on the experimental evaluation of the impact of an AoI-based networking solution in a real-world time-sensitive application, which is the focus of this work.

Data generation and queueing have significant impact on information freshness. The follower middleware architecture illustrated on the left in Fig. 2 receives updates at rates that are determined by sensors/applications, then it time-stamps and enqueues these updates. Upon receiving a polling request from the leader, the follower middleware releases a single update via UDP/IP to lower layers of the network protocol stack. Our middleware incorporates two key ideas from the AoI literature to enable information freshness - a mechanism to control the update generation rate, and an implementation of Last-In First-Out (LIFO) queues.

First-In First-Out (FIFO) queues are the default queuing implementation in most communication networks. However, to manage AoI, they require careful control of the arrival rate. If updates are generated at a low rate, then the information updates are too infrequent. On the other hand, if updates are generated at a very high rate, then the FIFO queue will often be backlogged and fresh updates will have to face large queueing delays. To address this problem, we implement a rate control mechanism at the followers that can be used when applications use FIFO queues.

Rate Control: To adjust the update generation rate, the rate control mechanism only updates its queue at fixed intervals of time, dropping any updates generated in between. This mechanism ensures that the middleware only accepts new updates at the desired rate. Note that finding the optimal generation rate for a given network setup is a nontrivial task, as the optimal rate depends on the network’s topology, traffic load, link reliability, and Medium Access Control (MAC) mechanism. To illustrate the impact of the generation rate on information freshness, we plot in Fig. 7(a) the AoI of a standard WiFi system (that uses FIFO queues at the MAC layer) with different update generation rates, including the optimal rate which is obtained by grid search.

LIFO Queues: Last-In First-Out (LIFO) queues transmit the most recently generated update first, making them ideal for applications that rely on the knowledge of the current state of the system, such as mobility tracking. When an update is generated, the LIFO queue simply replaces the old head-of-line update with the fresh update. A higher update generation rate at the followers can only lead to fresher updates at the leader and, hence, a lower AoI. LIFO queues have been shown to be optimal for minimizing AoI in a wide variety of network settings [26, 42]. However, LIFO queues are rarely implemented at the transport, MAC, or physical layers in practice. Our middleware supports both FIFO and LIFO queues at the application layer, while also supporting rate control, providing the system designer with two important tools to manage AoI.

The multiple access mechanism controls the method by which followers and leader share information using the limited communication resources. WiFi employs a distributed random access mechanism that works well for small-scale underloaded networks. However, for large-scale congested networks, it leads to excess packet collisions that in turn lead to lower throughput and higher latency, and ultimately poor performance for real-time applications.

We design the leader middleware, illustrated on the right in Fig. 2, to: (i) prevent packet collisions; (ii) enable dynamic prioritization of the transmissions that are most valuable to the application; and (iii) facilitate integration with existing multi-agent systems that use WiFi. The middleware drives the underlying distributed WiFi network to behave like a centralized network with support for polling. Specifically, the leader middleware coordinates the flow of information in the network by sending polling packets to the followers selected for transmission. At every decision time $t$, the leader selects the next follower to poll based on an application-centric transmission scheduling policy $\pi$, which can be a function of the current AoI of the followers $A_{i}(t)$, the reliability of the WiFi links $p_{i}(t)$, where $p_{i}(t)\in(0,1]$ represents the probability of a successful transmission from follower $i$ to the leader, and the application-defined priority weights $w_{i}(t)\geq 0$, which represent the relative importance of each follower’s information to the overall application goal. For example, in a mobility tracking application, the estimated velocities of the moving objects can be assigned as application weights $w_{i}(t)$, since faster objects may require more updates than slower objects in order to achieve the same tracking performance.

To capture application priorities and information freshness, we define the expected time-average of the weighted sum of AoIs across the entire network as

$$\frac{1}{T}\mathbb{E}\left[\sum_{i=1}^{N}\left(\int_{t=0}^{T}w_{i}(t)A_{i}(t)dt\right)\right]\;,$$

(1)

where $N$ is the number of followers, $T$ is the time-horizon, and the expectation is with respect to the randomness in the link’s reliability $p_{i}(t)$ and the policy $\pi$.

Many theoretical works [27, 28, 29, 30] have studied the structure of scheduling policies that attempt to minimize objective functions of the form (1). A key take away from these works is that, given the knowledge of the application weights $w_{i}(t)$, link reliabilities $p_{i}(t)$, and information freshness $A_{i}(t)$ of every follower $i$, the Whittle’s Index Policy is a near-optimal solution to the problem of minimizing (1). The Whittle’s Index Policy selects, at every decision time $t$, the follower $i^{*}$ that satisfies

$$i^{*}\in\textstyle\operatorname{argmax}_{i}\left\{w_{i}(t)p_{i}(t)A^{2}_{i}(t)\right\}\;,$$

(2)

with ties being broken arbitrarily. Intuitively, the Whittle’s Index Policy is polling the followers associated with high application weights, reliable WiFi links, and outdated information at the leader.

Recent works have developed similar Whittle’s Index Policies to address generalizations of (1). Specifically, [30] addressed the problem of minimizing general non-decreasing cost functions of AoI, $f_{i}(A_{i}(t))$, as opposed to simply minimizing $A_{i}(t)$, and [31] considered network settings with time-varying, unknown and even adversarial application weights $w_{i}(t)$. This suggests that Whittle’s Index Policies are remarkably robust and can be applied to a wide variety of applications. Moreover, the Whittle’s Index Policy has low computational complexity: it only requires solving the maximization in (2) and computing estimates of $w_{i}(t)$, $p_{i}(t)$, and $A_{i}(t)$.

We describe the networking middleware illustrated in Fig. 2, which incorporates both the application-centric queueing at the followers and transmission scheduling at the leader.

Followers collect information updates about their immediate environment (e.g., video, pictures, laser scans, and temperature) and about their own platforms (e.g., position, attitude, velocity, and battery level). These updates are sent to the follower middleware to be prepared for transmission.

The rate control mechanism decides whether each update is discarded or enqueued. The follower middleware time-stamps each update that is not discarded at the time of collection and enqueues them. These time-stamps are used to compute $A_{i}(t)=t-\tau_{i}(t)$ at the leader upon delivery. The queuing discipline, update rates, and queue buffer sizes can be controlled by the middleware to satisfy the requirements of the application.

When the follower receives a polling packet, it releases a single information update from its queue. Assuming that the update does not exceed the maximum length of the UDP payload (or any threshold set by the system designer), the released update can be simply forwarded via UDP/IP to lower layers of the networking protocol stack. However, if the update is too large, then the middleware divides the update into fragments. Fragments are stored in a separate FIFO queue and then transmitted one-by-one to the leader. Each fragment is transmitted via UDP/IP over standard WiFi. Since the maximum WiFi frame length can be smaller than the UDP payload size, it is possible that WiFi will require multiple successful over-the-air transmissions to deliver a single fragment to the leader. If WiFi fails to deliver a fragment, the middleware attempts to re-transmit the fragment using an error-control mechanism based on acknowledgements at the fragment level.

The Leader’s responsibilities include coordinating both the flow of information in the WiFi network and the followers’ behavior. To do so, the leader manages the generation and transmission of polling packets and control information. Since follower’s updates are transmitted only upon reception of a polling packet, the leader has almost full control of the flow of information in the WiFi network, irrespective of the number of followers and the amount of data they generate.

The leader uses the Whittle’s Index Policy (2) to decide the next follower to poll. After transmitting a polling packet, the leader waits for the reception of a fragment. If this waiting period exceeds a timeout interval (e.g., $300$ milliseconds), the attempt is assumed to have failed. Upon receiving a fragment or after a timeout, the leader prepares for the transmission of the next polling packet.

Prior to transmitting the next polling packet, the leader takes a series of steps that depend on whether the received fragment was the final fragment of an information update or not. If the received fragment from follower $i$ was not the final one, then the leader middleware simply updates $p_{i}(t)$. On the other hand, if the received fragment was the final, then the leader: (i) updates $p_{i}(t)$; (ii) combines fragments to obtain the original information update; (iii) extracts the associated time-stamp and updates $A_{i}(t)$; (iv) sends the information update to the application for processing; and (v) updates both $w_{i}(t)$ and the control information based on the results of this processing.

To estimate $p_{i}(t)$, the leader computes $\hat{p}_{i}(t)=D_{i}(t)/W,$ where $D_{i}(t)$ is the number of polling packets which received a successful response from follower $i$ out of the last $W$ polling packets sent to it. To accurately compute $A_{i}(t)=t-\tau_{i}(t)$, where $t$ is the current time measured by the leader and $\tau_{i}(t)$ is the largest time-stamp received from follower $i$, the clock at follower $i$ should be synchronized with the leader’s clock. The middleware performs periodic clock synchronization across all followers and the leader, at every $120$ seconds using NTP [43].

After performing the necessary updates, the leader middleware transmits a new polling packet to the selected follower. The latest control information is broadcast to all followers along with every polling packet.

Consider a setting where multiple UAVs are tracking moving objects on the ground. Clearly, outdated information about the position of the objects has a direct impact on the tracking capability of the UAVs. Ideally, the UAVs would like to receive fresh information about the objects continuously. One simple system design that achieves this goal consists of UAVs with high on-board computational power that are able to process video frames acquired from their cameras to detect and track objects. The continuous stream of images is processed locally, adding almost no delay, which keeps the UAVs updated about the position of the objects. A critical drawback of this approach is the prohibitively high cost of deploying numerous UAVs with high on-board computational power.

The separation of computing and sensing allows for more scalable system design - with one leader-node that has plenty of on-board computational power, and numerous low-cost sensing-UAVs that have little computational power but can effectively collect sensor data and communicate over a wireless network. Figure 4 illustrates an example of this system design approach. In general, the leader node could be an UAV with a powerful on-board computer such as a Jetson TX2, a compute node located at the wireless edge, or even a cloud server performing high-speed inference and sending back control commands.

In our specific implementation of the mobility tracking application, the sensing-UAVs capture video of the immediate environment below them and send the captured video frames (without any pre-processing) to the leader compute node. The leader processes the received frames, infers the position of the objects, and sends trajectory updates to the sensing-UAVs via WiFi. The main challenge of this design approach is to manage the limited wireless resources efficiently in order to keep information at the UAVs as fresh as possible. WiSwarm, an instantiation of our networking middleware, ensures information freshness and scalable tracking performance by carefully controlling the flow of information over the network.

Next, we describe the different individual components involved in our application - the mobile objects to be tracked, the sensing-UAVs, the leader compute node. We also discuss how WiSwarm is implemented at the sensing-UAVs and the leader compute node.

We use small autonomous cars equipped with RasPis (3B) as the moving objects whose mobility is tracked by the UAVs. Figure 5(b) shows one such car, with the ArUco marker tag on top, which is used for uniquely identifying and tracking the position of the cars by the leader compute node.

The sensing-UAV consists of two subsystems: a quadcopter drone and a RasPi (Zero W). Figure 5(a) shows a sensing-UAV with a RasPi on board the quadcopter drone, along with its sensing and communication peripherals.

RasPi (Zero Ws) have very little computation capability (1 GHz single-core CPU and 512 MB RAM), but can effectively interact with multiple sensors and also communicate over WiFi. They are also extremely cost-efficient ($10), making them ideal for use in the sensing-UAVs. Each UAV is also equipped with a micro-controller unit (MCU) that runs state estimation and flight control algorithms. The state estimator combines measurements from an on-board inertial measurement unit (IMU) with global position and orientation measurements. These global measurements are obtained from a motion capture system and received by an Xbee WiFi module mounted on the UAV. When motion capture data is not available, the Xbee module can be replaced by an alternative data source, such as a global navigation satellite system (GNSS) receiver.

The RasPi is connected to a camera that captures video of the area below the UAV. Along with each frame, the RasPi also collects the position and orientation at which the frame was collected by asking for this information from the MCU using an asynchronous serial connection. Following the discussion in Sec. II-B, we know that fresh frames are the most useful for tracking, so we set the queuing discipline at the sensing-UAVs to be LIFO and the buffer size to be such that it can accommodate only one frame at a time.

The RasPi is connected to the leader compute node over 2.4 GHz WiFi using a high gain (8 dBi) antenna. Whenever the RasPi receives a polling packet, it transmits the most recent update in its LIFO queue to the compute node. The RasPi also collects the control information transmitted by the compute node which contains the times and locations (in global coordinates) where the UAV should be in the future in order to track the moving object. The RasPi sends these waypoints over the serial connection to the UAV MCU. The UAV MCU then plans and executes a trajectory that reaches the specified waypoints at the specified future time instants. It does this by interpolating the waypoints to obtain a continuous trajectory that is followed using the flight control algorithm described in [44]. This completes the control loop.

The compute node collects video-frames received from sensing-UAVs in response to polling requests. These video-frames are stored in separate LIFO queues - one for each sensing-UAV. The compute node runs an image processing thread which goes over the queues maintained by WiSwarm in a round-robin manner and processes the received video-frames whenever it finds a non-empty queue.

For each video-frame, the image processing thread attempts to locate the car that the UAV was assigned to track. If the car is found, it uses the relative location of the tag in the frame and the absolute position and orientation at which the frame was captured to compute the global coordinates of the car. The thread also keeps a record of the last known locations of the car. Using the current and previous locations, the image processing thread obtains: (i) the relative velocity between the car and the sensing UAV; and (ii) a list of future waypoints and the time-stamps at which it expects the car to reach these coordinates. In our implementation, we use a simple linear extrapolation scheme to predict future waypoints.

The image processing thread sends the waypoints and time-stamps to WiSwarm along with information about the relative velocity between the car and the sensing-UAV. WiSwarm uses the relative velocity information to update its application-defined priority weights

$$\textstyle w_{i}(t)\leftarrow\alpha w_{i}(t^{-})+(1-\alpha)\hat{v}_{i}(t),$$

(3)

where $\hat{v}_{i}(t)$ is the estimate of relative velocity between the car and the associated sensing UAV, and $\alpha=0.8$. Since velocity estimates are noisy and car velocities are time-varying, we use an exponential moving average motivated by the adaptive AoI-based scheduling algorithms proposed in [31]. WiSwarm updates link reliabilities $p_{i}(t)$ by using the number of successful fragment deliveries, as described in Sec. II-D.

With updated application weights $w_{i}(t)$ and link reliabilities $p_{i}(t)$, WiSwarm uses Whittle’s Index Policy (2) to select the sensing-UAVs that need to be scheduled for transmission most urgently. Together with the unicast transmission of a polling packet, WiSwarm broadcasts the most recent list of future waypoints and time-stamps for every sensing-UAV. This repeated broadcast ensures redundancy in the delivery of control information.

In this section, we discuss the performance improvements of WiSwarm over WiFi for three different metrics: (i) AoI, (ii) throughput, and, most importantly, (iii) tracking error. Each data-point in the following discussion represents 16 minutes worth of experiments, split into 4 batches of 4 minutes each. We calculate the time-average of the performance metric over the entire 4 minutes of each batch and then the mean and standard deviation across batches.

Experimental Setup. The experiments involve multiple RasPis running an emulated virtual UAV application. This application does two things. First, each RasPi has a video simulating the movement of cars stored on it. Using this video, the RasPis create cropped frames of size 224x224, based on the current location of the virtual UAV, which capture the local Field-of-View (FoV). These video frames are generated at a specified rate that can be set using the rate control mechanism, and are forwarded to WiFi or WiSwarm for delivery. The frames are stored as unencoded grayscale yuv images (1 byte per pixel), so each video frame is 49 kB in size. Second, the application decodes the control packets received from the Compute Node and updates the virtual UAV’s location by moving between control waypoints at a specified speed. Figure 6 shows a frame from the video used for simulating movement of the car tags, along with two examples of 224x224 frames that the RasPis send to the Compute Node for processing.

Figure 7 plots the mean AoI and tracking error per UAV for both WiFi-TCP and WiFi-UDP as the frame generation rate at the RasPis increases. This plot is for a system with $6$ transmitting RasPis. Note that lower AoI and lower tracking error are preferred in terms of performance.

We make two important observations from Fig. 7. First, the performance of both WiFi-TCP and WiFi-UDP degrades when the generation rate is high, since the network becomes congested. Second, WiFi needs optimization of the generation rate at the application layer to be anywhere close to working in practice. This optimization is challenging since it needs to be at the application layer and also adjust quickly to changes in the traffic load and link reliability, which can vary due to external interference. This is true for both TCP and UDP, i.e. TCP congestion control was unable to adjust to the optimal rate on its own.

Next, we compare the performance of WiSwarm with both fixed-rate versions of WiFi and rate-optimized versions of WiFi. We choose the frame generation rates from the set $\{1,3,5,7,10,15,20,25,50,100\}$ fps and the number of RasPis from the set $N\in\{2,4,6,8,10,12,$ $14\}$. We find the best performing rates for each value of $N$ from the rate set (based on tracking error).

To the best of our knowledge, there are no general purpose systems that can do application layer rate control for a wide variety of real-time applications, so the rate-optimized WiFi systems are overly optimistic baselines. Despite this, WiSwarm achieves significant performance gains over both fixed-rate and optimized rate versions of WiFi-TCP and WiFi-UDP.

AoI. Figure 8 plots the mean AoI per UAV as the system size $N$ increases. More sources in the system means more congestion, more packet collisions (in WiFi) and hence poor performance and scalability. We see this clearly in Fig. 8(a), where we compare the baseline versions of WiFi-UDP and WiFi-TCP to WiSwarm. The baseline versions of WiFi have fixed update generation rate of 50 fps at each source while WiSwarm uses the maximum generation rate of 100 fps. Mean AoI improves by 16x for $N=8$ and by almost 50x for $N=14$ compared to fixed-rate WiFi. A major cause of the poor performance of WiFi is buildup of FIFO queues once the network becomes congested. Fixed-rate TCP eventually starts outperforming fixed-rate UDP for larger $N$, due to its congestion control mechanism. WiSwarm does not suffer from the congestion problem due to the LIFO queues.

Figure 8(b) compares rate-optimized versions of WiFi-TCP and WiFi-UDP with WiSwarm. We observe that mean AoI still improves by 1.5x for $N=8$ and 2.2x for $N=14$. While the FIFO queues in WiFi are no longer congested due to careful tuning of the frame generation rates, there are still packet collisions due to the distributed nature of the CSMA protocol and external interference sources. WiSwarm avoids these collisions by centralizing medium access scheduling decisions and prioritizing sources with higher AoI.

Since AoI combines the idea of service regularity with latency, we are also interested in the tail of information freshness. Figure 9 plots the performance of baseline WiFi systems and WiSwarm for the $95th$ percentile of AoI, i.e. the value of AoI which is only exceeded $5\%$ of the time during an entire experiment. We observe very similar gains as mean AoI. For fixed rate, we observe an 18x reduction at $N=8$ and 36x reduction at $N=14$. For rate-optimized, we observe a 1.2x reduction at $N=8$ and a $1.7x$ reduction for $N=14$. Note that the tail AoI is important for our tracking application in addition to mean AoI, since a worse tail suggests a higher probability of the car going out of the UAV’s Field-of-View leading to lost tracking.

Throughput. Figure 10 plots the mean throughput per UAV for each of the considered systems as the number of UAVs increases. From Fig. 10(a), we observe that both fixed-rate WiFi-TCP and WiFi-UDP have higher per UAV throughput than WiSwarm. However, this doesn’t help in getting better AoI (as we saw earlier) or tracking performance (as we will see later). This supports the idea that high throughput alone is not sufficient and AoI is the right metric to optimize for in such real-time applications. For the rate-optimized versions of WiFi, we see a performance improvement in mean throughput per-UAV since WiSwarm can avoid packet collisions and deliver higher rates than the distributed CSMA mechanism while also ensuring lower AoIs. For $N=8$, WiSwarm achieves 1.2x higher throughput and for $N=14$, it achieves 2.7x higher throughput.

Tracking Error. This is where we see how all the pieces of our system design come together to deliver better application performance. Figure 11 plots the mean tracking error (in pixels) per UAV as the number of UAVs increases, for WiSwarm and WiFi implementations. From Fig. 11(a), which shows the fixed-rate baselines, we observe that tracking performance improves by 12x for $N=8$ and 4x for $N=14$. From Fig. 11(b), with rate-optimized WiFi versions, we observe that tracking error is reduced by 2x at $N=10$ and 4x at $N=14$ with WiSwarm. We also note that the gap in performance between WiSwarm and the WiFi baselines increases with the system size. In other words, the performance of WiFi-TCP and WiFi-UDP degrades much more quickly with $N$ leading to poor scalability.

While the stationary experiments allowed us to test our system in great detail and provide extensive comparisons, they did not involve implementing the application on real UAVs tracking actual mobile targets in a dynamic environment. Our flight experiments address exactly this setting. Broadly, we will observe that the mobility of UAVs and higher degree of interference leads to worse wireless connectivity and, in turn, more congestion and packet collisions for WiFi. This allows us to bring the robustness of WiSwarm into focus. We provide a video describing the setup and results from the flight experiments at [17].

Experimental Setup. In the flight tests, we replace the internal antenna of the RasPis with an external high-gain (8 dBi) antenna to improve range and reliability when the UAVs fly. We fly up to 5 UAVs at a time in our experiment space which is roughly 20 meters x 10 meters in size. The mobile objects are autonomous cars with RasPi 3Bs shown in Fig. 5(b). We program these cars to move in different polygonal trajectories over time and also stop occasionally at random for a few seconds. These trajectories are unknown to the UAVs and the Compute Node, and the job of the UAVs is to track the cars as closely as possible. Figure 1 depicts the setup for an experiment involving 5 UAVs tracking the corresponding cars.

We configure the Pi-Cameras at the UAVs to generate video frames at the maximum possible rate, which is 90 frames per second. For WiSwarm, we utilize this full rate, while for WiFi, we choose the optimized rate by using rate control. The video frames are 160x160 unencoded grayscale images in the yuv format (1 byte per pixel), with a total size of 25 kB per frame. Figure 12 shows two examples of frames sent to the Compute Node by RasPis from the flying UAVs during different experiments.

The sensing-UAVs implement a controller that requires knowledge of their own global position and orientation to be able to plan desired trajectories. A Motion Capture (MoCap) system provides this information to the UAVs (also via 2.4 GHz WiFi). These MoCap messages are sent to the UAVs in UDP messages at 30 messages/second and each message contains timestamp, position, and orientation of a single vehicle in 45 bytes. So the MoCap network usage is approximately 1.3 kB/s (or 11 kb/s) per UAV. Importantly, the MoCap system runs completely independently from the WiSwarm and WiFi systems and causes a low level of persistent interference in the channel. Thus, results from our flight experiments are a good measure of robustness of WiSwarm and WiFi to external interference.

Results. Figure 13 plots the coordinates of the sensing-UAVs and the target cars over time, for a two drone WiSwarm experiment, in both 2-D and 3-D. Similarly, Fig. 14 plots the coordinates of the sensing-UAVs and the target cars over time, for a two drone WiFi experiment. It is easy to see that WiSwarm allows for far better tracking than WiFi even for just two UAVs. This is further supported by the histograms of AoI and tracking error plotted in Fig. 15. The lower tracking error for WiSwarm is due to the fact that it can achieve lower AoI, and hence deliver fresher information.

We summarize the results of all of our flight experiments in Tables I and II. We average over 4 minutes of flight data for each experiment. Our main observation is as follows: while WiFi allows tracking for up to two UAVs at a time, WiSwarm can easily allow tracking for up to five UAVs at a time. In fact, when there are more than two sources in the system, WiFi is unable to deliver more than a handful of packets and essentially no UAV control is possible. The main reason for this is the high level of packet collisions for WiFi. WiSwarm is relatively robust to the unreliable wireless channels, interference and mobility issues encountered in flight experiments, due to our scheduler design that avoids packet collisions and prioritizes AoI.