Over the past few years, unmanned aerial systems (UAS) have become increasingly important. On the one hand, a single UAS or a group of them can support many commercial and civilian applications, such as forest-fire detection [1], reconnaissance [2], search and rescue [3], and 3D mapping [4]. On the other hand, UAS can be connected with many ground-based devices to facilitate more applications, such as data collection [5], and so on.
In the literature, many researchers have been working on the design of UAS platforms focusing on control [6], communications [7][8][9], networking [10], and so on. Nevertheless, we notice that the computation aspect of the UAS platforms has been largely neglected. For instance, most existing UAS platforms have limited computing capability and can perform only essential functionality, such as flight control, image/video capturing, and sensor data collection [11][12][13][14]. Consequently, computation-intensive tasks are often offloaded to the ground stations or to the cloud, which may lead to many issues. For instance, such a computing model may lead to significant transmission delays or failures, and thus cannot support many delay-sensitive applications. Moreover, for many high-bandwidth applications, such as real-time object detection and tracking, such a model requires large communication bandwidths, which may not be feasible in certain scenarios.
With the rapid development of Internet of Things (IoT) and the proliferation of mobile devices, the demand for computing resources is increasing dramatically among mobile devices. To address this challenge, mobile edge computing (MEC) [15] is deemed a promising solution, which allows computation-intensive and/or delay-sensitive tasks to run on resource-limited mobile devices, by moving computing resources to the edge of cellular networks. Recently, researchers propose to use UAS equipped with computing capability as computing servers to assist MEC. Such UAS-enabled MEC [16], once proposed, has attracted an increasing research attention, which allows on-demand computing services to be provided anytime and anywhere, even in the absence of communication infrastructure. This is especially useful in emergency scenarios where mobile users can leverage the onboard computing resources of the UAS to perform advanced data analysis for damage assessment [17].
Although researchers have realised the great potentials of UAS as a computing platform, existing studies on UAS-enabled MEC [17][18][19][20][21][22][23] are mainly based on theoretical analyses and simulations, and consider problems such as computation offloading and UAS trajectory design, and so on. The fundamental issue of how to design a UAS platform with advanced onboard computing capability has not been addressed. For instance, Jeong et al. [18] studied the computation offloading process from a static mobile device to a UAS with predetermined trajectory, and proposed an optimal bit allocation strategy for communication and computing to minimise the mobile energy consumption under maximum latency constraints. Extended from this study, Jeong et al. [17] further considered multiple mobile devices and UAS with unknown trajectory, and developed a strategy that jointly optimises bit allocation and UAS trajectory to minimise the total mobile energy consumption under both maximum latency constraints and UAS's energy budget constraint. As Jeong et al. [17,18] assume all local data are offloaded to the UAS for computing, which may be impractical in reality due to the limitation of mobile devices' transmit power, Hua et al. [19] further generalised the approach and introduced a resource partitioning strategy, allowing part of the computation task to be executed locally for reduced communication energy consumption. Xiong et al. [20] studied a similar problem, but considered a different UAS movement pattern and the binary offloading paradigm, where the computation task is either completed locally or offloaded to the UAS. As real computational tasks are generated randomly, the stochastic computation offloading was explored in [21], where a stochastic queue model is used to simulate the arrival of computation tasks. To address the scenarios where mobile devices have limited battery energy for offloading or other computing tasks, Zhou et al. [22,23] proposed a UAS-enabled wireless powered MEC system, where UAS also functions as an energy transmitter to provide power supply to mobile users through radio-frequency signals.
In this paper, we aim to fill the research gap and develop a new UAS-based airborne computing platform, which not only has advanced computing capability to allow data captured by UAS to be processed directly onboard of UAS, but also supports broadband wireless communication and networked UAS control to facilitate various network-based UAS research development, applications and services. Besides advancing UAS research, the proposed airborne computing platform also promotes the development of MEC. Compared with ground computing platforms, the UASbased MEC is advantageous in that it allows computing services to be provided at anytime and anywhere, even in the absence of communication infrastructure, due to the 3D mobility and high manoeuvrability of UAS. Our airborne computing platform is open to the community and can be accessed through our project website [24].
Our main contributions include the following three parts: hardware design, software design, and applications.
(1) Hardware design: We first investigate how to design and implement the hardware of the UAS-based airborne computing platform. Specifically, we discuss the desired features for the airborne computing platform, especially according to the unique UAS structure and applications. We then conduct a comprehensive analysis and systematic study on ten state-of-the-art single-board computers regarding the computation performance, power consumption, size, and weight. Based on the thorough comparison, we choose NVIDIA Jetson TX2 as the computing unit for the platform. A prototype is then designed and implemented, which integrates Jetson TX2 for onboard computations, UAS, broadband communication system, and networked control system.
(2) Software design: With respect to the software of the platform, we aim to design an airborne computing platform with sufficient flexibility and programmability. A key technology to achieve this goal is virtualisation, because it can efficiently manage resources, can enable concurrent applications, and can enhance the security of the computing platform. In this paper, we investigate two key virtualisation techniques: (i) virtual machine (VM) using KVM [25] and (ii) container using Docker [26]. To understand the impact of virtualisation on UAS applications, we conduct extensive experiments to measure the performance of the two virtualisation techniques from the aspects crucial for UAS applications, including computing, networking, isolation, power consumption, and so on. The performance trade-offs are also discussed. These experiments verify the feasibility of virtualising UAS and demonstrate the potentials of virtualisation in enhancing UAS' onboard computing capability. The insights obtained from the comparison results between KVM and Docker also provide guidelines for the selection of appropriate virtualisation techniques for UAS applications.
(3) Applications: Using the prototype with virtualisation supports, we further test the performance of several real UAS applications that may benefit from the onboard computing capability. For instance, we test UAS image processing tasks of different complexities to evaluate the benefit of virtualisation. We also test the feasibility of performing real-time object detection onboard of UAS. To understand the potentials of distributed computing over a UAS network, we also implement an advanced coded distributed computing approach for efficient matrix multiplication, which is one of the most critical computing tasks for many artificial intelligent applications.
The rest of this paper is organised as follows. In Section 2, we discuss the hardware selection for UAS-based airborne computing, and we present the details for the design of a prototype. Next, in Section 3, we elaborate on the use of virtualisation to extend the functionality of the airborne computing platform and we present extensive experimental results on performance of the computing platform with the virtualisation capability. We then further investigate, in Section 4, the benefits of using the proposed airborne computing platform for real computation-intensive UAS applications. Finally, in Section 5, we conclude the paper with a brief summary and future works.
In this section, we investigate the hardware design for UAS highperformance onboard computing. In particular, we first discuss the desired features for the onboard computing hardware. We then analyse ten state-of-the-art single-board computers and provide guidelines for choosing a suitable single-board computer as the computing unit. A prototype designed based on a selected singleboard computer is then described.
Since the onboard computing hardware is carried by a UAS, there are some unique considerations for the selection of a single-board computer. First, the computing hardware should be of light weight and compact size, due to the limited payload and space provided by the UAS. Second, because of the limited power capacity of the UAS-carried batteries, it is preferable to have an efficient power management system to reduce the power consumption. Third, in terms of computing, the hardware should have a powerful CPU, sufficient memory and storage to support most computing needs. Moreover, a powerful GPU is also necessary to enable real-time image processing and deep learning capabilities onboard of UAS. Last but not the least, the single-board computer should have extensive community support, such that developers and users can share experience and seek online support during their system development. In addition, it is also very important to have sufficient open access design documentation and configuration toolboxes.
In the literature, several single-board computers are commonly used for UAS operations, including Raspberry PI [27], Odroid XU [28], Arduino Board [29], Cubieboard [30], Arndale Board [31], and so on. In our study, we do not consider them because they are not powerful enough to fulfill computation-intensive tasks.
Unlike the aforementioned computing devices, more powerful single-board computers have not been fully investigated for UAS. Recently, Shang and Shen [32] investigated the computing power of NVIDIA Jetson TX1 [33] with 4 CPU cores, 256 Maxwell CUDA GPU cores, and 4GB memory. Their studies show that NVIDIA Jetson TX1 is still not sufficient enough to achieve realtime 3D reconstruction and mapping using the simultaneous localisation and mapping algorithm.
To select a suitable single-board computer to enable UAS highperformance onboard computing, we consider those with computing capability comparable to Jetson TX1. In particular, ten state-of-the-art single-board computers, including NVIDIA Jetson TX2 [34], UDOO X86 ULTRA [35], Intel Aero Compute Board [36], LattePanda Alpha [37], Up Squared [38], NVIDIA Jetson Xavier [39], DJI Manifold [40], HiKey960 [41], Rock960 [42], and Jetson TX1 [33], are found and compared in detail from various aspects (see Table 1 for the comparison results).
As shown in Table 1, Jetson Xavier with 8 CPU cores and 512core Volta GPU with Tensor cores has the highest computing power. Jetson Xavier also excels in memory capacity. However, it is the most power consuming and costly, and it does not natively support Wi-Fi communications. Jetson TX2 with 6 CPU cores, 256-core NVIDIA Pascal GPU, and 8GB memory is the second powerful single-board computer. It provides an out-of-the-box high-throughput wireless local area network (WLAN) interface, and is also the smallest in size. UDOO X86 ULTRA outperforms others in power consumption and operating system (OS) support; Intel Aero Compute Board is the lightest among those with known weight information; Rock960 is of the lowest cost; and Up Squared has the largest storage. All these single-board computers support virtualisation.
The above analysis provides us with guidelines to select proper single-board computers for UAS high-performance onboard computing. A trade-off should be achieved among different performance aspects based on the needs of specific applications. For instance, if flight time is more critical than real-time processing, UDOO X86 ULTRA that consumes less power or the lightweight Intel Aero Compute Board may be selected. If cost is of the major concern, Rock960 can be a good choice.
In this study, we select the NVIDIA Jetson TX2 as the computing hardware for the airborne computing platform. As shown in Table 1, its overall computing capability is above the average, especially considering the availability of a powerful GPU. Both the power consumption (7.5 W) and weight (85 g) are around the average. Another attractive factor is that there is an open-access online support community including FAQ and forum [43], which is very helpful for project developers.
While Jetson TX2 has a small size of 50 mm×87 mm, the development board provided by NVIDIA is very large (17 cm × 17cm). To address this issue, we design a new carrier board, as shown in Fig. 1a, based on the following technical specifications. The carrier board has a dimension of 88 mm×65 mm with weight
With Jetson TX2 chosen as the computing unit, we then develop a prototype of the airborne computing platform [44,45] that also incorporates a quadcopter unit for lifting and mobility, a communication unit for UAS-to-UAS (U2U), UAS-to-ground (U2G) and ground-to-UAS (G2U) communications, and a control unit for addressing communications, networking, UAS navigation and application needs (see Fig. 2).
The quadcopter unit serves as a platform carrier to carry other units. Compared with fixed-wing UAS, quadcopters are easier to operate, allow vertical taking off and landing, and can hover in the air. Here we select DJI Matrice 100 [46] as the quadcopter unit, due to its nice properties in terms of payload, expandability, stability, and operability. For instance, the maximum weight allowed for the DJI Matrice 100 while taking off is 3.6 kg, which exceeds the total weight of the whole system of 3.13 kg. With a LiPo 6 s battery, our prototype can fly for around 18 min.
The communication unit supports the U2U and U2G/G2U communications. For U2U communication, we choose Ubiquiti Nanostation Loco M5 [47], a directional antenna, to enable long-range and broadband communication between two UAS. The transmission rate achieves up to 150 Mbps, allowing real-time video transmission. The maximum transmission distance is 10 km. For U2G/G2U communication, Huawei WS323 [48] is selected as the Wi-Fi router to enable communication between ground devices and the UAS, where ground devices connect to the router through the WLAN. Through this link, sensor data such as videos captured by the UAS can be transmitted to the ground for visualisation and analysis.
The control unit consists of two sub-units: UAS flight control and directional antenna control. In particular, the UAS flight control sub-unit makes the UAS follow desired trajectories, while maintaining stability. It translates high-level control commands received from the remote pilot to motor pulse width modulation (PWM) signals, based on UAS state measurements captured by sensors such as GPS and inertial measurement unit. The directional antenna control sub-unit controls the heading direction of the directional antenna to maximise the performance of directional communication. This subunit is composed of a rotating motor, a tunable plate, a motor driver, and a compass. The tunable plate carries the directional antenna and the compass. To rotate the plate to a specified angle, the motor driver takes the control signal generated by the computing unit and translates it to PWM signals. The motor then drives the plate to rotate based on the PWM signals.
Here we select MTI-3-8A7G6T Xsens and Adafruit TB6612 as the compass and the motor driver, respectively.
In this section, we investigate two key virtualisation techniques, VM [49] using KVM and container using Docker [26], to improve the flexibility and programmability of the airborne computing platform. In particular, we first provide a brief overview of the current research status in the field of virtualisation. To understand the impact of virtualisation, we then conduct a series of experiments to study their performances from multiple aspects, including computing, networking, isolation, power consumption, and so on, as well as the trade-offs among them.
To support diverse computing tasks on the same UAS platform, one of the key technologies is virtualisation. First, virtualisation provides powerful resource management capabilities, so that it can efficiently enable an application with specific computing requirements, such as CPU, memory, storage, networking, and so on. Second, virtualisation can facilitate concurrent execution of multiple applications on the same UAS. Third, in terms of security, virtualisation can isolate unreliable and untrustworthy functionality, and improve the resilience of UAS to malicious attacks [50]. In addition to these advantages on a single Virtualisation for mobile devices is more relevant to this study, which has aroused increasing attention with the wide use of mobile devices and the fast evolution of ARM processors, but is still under development [54]. In the last few years, several studies have investigated the performance of virtualisation on different mobile devices, such as Raspberry PI 2 [55], Cubieboard2 [56], ARM Chromebook [57], Banana Pi [58], and Insignal Arndale board [59], and so on. However, since these studies were not directed to UAS, their performance analysis was limited to CPU, memory, and disk in a single device. The unique features of UAS such as small payload, power constraint, and real-time computing need, as well as the special characteristics of multi-UAS applications such as U2U communications and network connectivity were also not considered in these studies.
Virtualisation has also played a critical role in emerging computing paradigms including IoT, fog computing, and MEC. For instance, container-based virtualisation is applied in [60,61] to enable data processing at IoT devices. A Docker-based fog computing framework over Raspberry PI is described in [62]. In [63], the integration of IoT and fog computing with virtualisation deployed in fog nodes is studied.
Despite the abundant works on virtualisation, virtualisation for UAS has been rarely studied. Among the limited studies we can find, paper [50] utilises virtualisation to enhance the resilience of UAS to malicious attacks, where Raspberry PI 2 is adopted as the onboard computing unit. Nutanix recently released a commercial UAS cloud platform, called Acropolis [64], which can hold multiple VMs. In [65], virtualisation is implemented on fog servers to provide computing services for UAS fire detection. Overall, a comprehensive investigation of virtualisation for UAS to enable high-performance onboard computing and advanced UAS applications is still lacking.
Virtualisation can extend the computing capabilities of UAS, at a cost of performance overheads, due to resource partition, isolation, and emulation. To understand the impact of virtualisation, we next investigate the performances of two key virtualisation techniques, KVM [25] and Docker [26], which are representatives of the hypervisor-based and container-based virtualisation techniques, respectively. Please refer to [66] for a brief introduction of the two virtualisation techniques, and the instructions to implement these techniques on Jetson TX2. In this study, both guest (VM or container) and host systems in Jetson TX2 implement Ubuntu 16.04 LTS with Linux kernel version 4.4 as the OS.
In this subsection, we investigate the impact of KVM and Docker on the CPU and GPU computing performances of the proposed airborne computing platform, which is crucial for the success of many time-critical UAS applications.
To measure the computing performance of the airborne computing platform with virtualisation capability, we create a VM that virtualises CPU or GPU resources using KVM (or container using Docker) on the platform, and install the Rodinia Benchmark Suite [67] in the VM (or container). We then run the Stream Cluster (SC) application in the benchmark, which performs clustering for data streams. The execution time of the SC application indicates the computing performance. To reduce experimental uncertainty, each experiment is repeated for ten times and the average execution time of the SC application is presented. This procedure is also applied to each experiment conducted in following studies.
In the experiment on the CPU performance, as the benchmark supports CPU multi-threading, which allows applications to be executed by multiple CPU cores in parallel, we vary the number of threads to test the parallel CPU computing performance. Note that each thread uses one CPU core. As only four ARM A57 CPU cores can be virtualised using KVM, up to four threads are evaluated for KVM. Docker successfully virtualises all six CPU cores in Jetson TX2, and thus up to six threads are evaluated for Docker.
In the experiment on the GPU performance, as KVM does not support CUDA based GPU [68], we only evaluate the impact of Docker on the GPU performance, which adopts the PCI passthrough technique [69] to achieve GPU virtualisation. We also compare the GPU performance of the airborne computing platform with its best CPU performance, i.e. using six threads. In both experiments, we vary the size of the input data stream in the SC application to test the scalability of the computing platform.
Experimental results: Fig. 3 shows the CPU performance of the airborne computing platform before and after implementing KVM or Docker. As shown in the figure, both KVM and Docker introduce performance overheads, and KVM degrades the computing performance more. This is because KVM adopts more complicated procedures to allocate memory resources, in particular using second-level address translation [25], while Docker achieves this by directly utilising the Linux system utility, i.e. control groups (cgroups) [26]. Our experiments also show that running five or six threads on Denver CPU cores does not improve the efficiency when the size of the data stream is small (see Fig. 3a). This is due to the overheads for coordinating different CPU processors.
Fig. 4 compares the performance of GPU and that of the CPU in two scenarios, i.e. before and after implementing Docker. As we can see from the figure, the computing performance of GPU is slightly worse than that of the hex-core CPU when the problem size is small, but GPU significantly outperforms the CPU when the problem size is large.
In this subsection, we investigate the impact of KVM and Docker on the networking performance of the airborne computing platform, which is crucial for reliable and timely information sharing between UAS and ground mobile devices as well as among UAS.
In this study, we conduct experiments to evaluate the networking performance for both the G2U/U2G and U2U communication links. To test the G2U/U2G communication link, we connect the airborne computing platform to a ThinkPad E540 laptop with the bandwidth of the Wi-Fi route set to 40 Mbps. To test the U2U communication link, we consider two scenarios: (i) the omni-directional antenna based short-distance communications and (ii) directional antenna based long-distance communications. These two scenarios are tested by linking two computing platforms using the Wi-Fi router and the Ubiquiti Nanostation Loco M5, respectively.
To measure the networking performance, we install the Iperf benchmark [70] on airborne computing platforms and the Thinkpad laptop. This benchmark measures the throughput between two connected devices by sending data streams from one device (called client) to the other (called server). To obtain a comprehensive understanding of the networking performance, we vary the role of the airborne computing platform (client or server) and also vary the transmission protocol (TCP or UDP).
The networking performance of the airborne computing platform before and after implementing KVM or Docker under different networking configurations is shown in Fig. 5.
In all these experiments, Docker shows less impact on the networking performance than KVM. This is due to the simplicity of Docker in network virtualisation. In particular, unlike KVM that requires emulation of network devices in VMs to enable communications, Docker containers can directly build network connections by using the Linux system utilities, e.g. network namespace [26]. Another phenomenon observed in all experiments is that higher bandwidths are achieved when the UDP transmission protocol is adopted, as UDP sends packets continuously without acknowledgements. Now let us analyse each subfigure. Fig. 5a shows that the bandwidth of the G2U/U2G communications increases when the airborne computing platform acts as a server. This is mainly caused by the use of different network devices in Jetson TX2 and ThinkPad laptop. In cases when two identical airborne computing platforms are connected to simulate the U2U communications, the bandwidth measured at the server side is smaller than that measured at the client side (see Figs. 5b andc). This is because VM or container requires port forwarding to receive packets, which introduces some overheads [71,72]. The comparison between Fig. 5c and the other two subfigures suggests that the high bandwidth is achieved by directional antennas, demonstrating their advantage over omni-directional antennas. Of interest, in Fig. 5c, when the TCP transmission protocol is adopted, the bandwidth measured at the client side increases after virtualisation. This may be caused by the bridge network in KVM and Docker, which buffers packets sent from the guest to the host network interface and in turn helps alleviate traffic congestion and increases the packet transmission rate.
Virtualisation can enhance the security of UAS applications, by isolating unreliable functionality. It can also enable concurrent execution of programs with different system requirements on the same airborne computing platform, by running these programs in different VMs (or containers). The success of these applications relies on how well VMs (or containers) are isolated, which is investigated in this subsection.
To test the isolation performance of KVM and Docker, we follow similar experimental setups in [73]. In particular, we create two guests (VMs or containers) in the airborne computing platform, and assign each guest with two ARM A57 CPU cores exclusively. We then install the Isolation Benchmark Suite (IBS) [74] to evaluate the isolation performance, which works by measuring the impact of a misbehaved guest (runs a stress test) on a well-behaved one (runs a baseline application). The smaller the impact is, the better the two guests are isolated. In this study, we run the lower-upper Gauss-Seidel solver (LU) application in the well-behaved guest, which performs a synthetic computational fluid dynamics calculation for a cubic region [75]. We here set the cubic size to 64 × 64 × 64. In the misbehaved guest, we run different stress tests available in IBS to test the performance of KVM and Docker in isolating different hardware resources.
To evaluate the impact of the misbehaved guest on the wellbehaved one, we measure the performance degradation of the wellbehaved guest using the following equation:
where T n and T s represent the execution time of the LU application before and after running the stress test in the misbehaved guest, respectively.
Table 2 shows the isolation performance of KVM and Docker in different stress tests. In particular, Docker demonstrates less performance degradation than KVM in the CPU, memory, disk I/O, and network intensive stress tests, indicating relatively better performance in isolating these hardware resources. This is because Docker directly uses Linux namespaces to achieve isolation, but KVM utilises the hypervisor's trap-and-emulate mechanism that hangs the rest of the VMs when one traps to the hypervisor [25]. In the fork bomb test that generates large amount of processes to overwhelm the OS, the performance of Docker degrades significantly compared to KVM, as containers share the same OS kernel with the host system. Overall, both KVM and Docker perform well in isolating CPU resources, as different VMs or containers occupy different CPU cores. However, both are relatively weak in isolating the other hardware resources.
In this section, we study the impact of KVM and Docker on power consumption, which directly influences the flight endurance of the proposed airborne computing platform.
To measure the power consumption of the airborne computing platform, we use the built-in three-channel INA 3221 monitors in Jetson TX2 [76]. Two experiments are then conducted to evaluate the impact of KVM and Docker on the power consumption of the airborne computing platform at different operating conditions. Particularly, in the first experiment, the airborne computing platform does not run any applications, and its power consumption is measured before and after implementing KVM or Docker. In the second experiment, the power consumption of the platform when running the SC application is measured.
The power consumption of the airborne computing platform before and after implementing KVM or Docker in the two experiments is shown in Fig. 6. As we can see, both KVM and Docker increase the power consumption slightly in the two experiments. KVM consumes more power than Docker, as it introduces more overhead. Also note that compared with the power consumed by running the SC application, the power consumed by virtualisation is negligible.
In the above comparative studies, we evaluate the performances of KVM and Docker from the aspects of computing, networking, isolation, and power consumption that are of major concern to UAS applications. In this subsection, we briefly discuss other performance aspects that are also of interest.
Compared with VMs, containers consume fewer resources and thus can be quickly deployed. To demonstrate this feature, we conduct a simple experiment to measure the resource usage of a bare VM (or container) created by KVM (or Docker). No applications run in the VM or container. Table 3 summarises the CPU, memory and storage usage of a bare VM or container measured using the sysstat and free Linux commands [77].
The live migration allows a running VM (or container) to be migrated from one computing platform to another, without interruptions during the migration process. Both Docker and KVM support live migration on server-based devices [49,78]. However, live migration on mobile devices has been rarely studied and KVM currently does not support live migration on ARM-based devices. In addition, no solution is currently available for the Docker container-based live migration on Jetson TX2. We expect that this can be realised using checkpoints and restore utility [79], which we will leave to the future work.
On ARM-based Linux single-board computers, KVM supports unmodified guest OSs [25], such as Ubuntu and openSUSE. However, Docker only supports ARM-based images [80], such as arm64v8/ubuntu, windows/nanoserver, and windows/ iotcore.
KVM is more resilient to malicious attacks than Docker. As VMs have their own OSs and kernels, the collapse of one VM does not influence others. However, containers share the kernel with the host OS. Therefore, once one container is attacked, other containers or even the whole system may collapse. For verification, we conduct a simple test. Specifically, we run the fork bomb, a denial-of-service attack, in the VM and container, respectively. As shown in Fig. 7, the host OS works properly when the VM is under attack, but collapses when the container is attacked. In summary, Docker achieves better performance than KVM in most aspects relevant to UAS applications, including computing, networking, isolation of CPU, memory, disk I/O and network resources, power consumption, and resource usage. Docker successfully virtualises all CPU cores and GPU in Jetson TX2, but KVM can only virtualise the four ARM A57 CPU cores. On the other hand, KVM provides higher security. To enable more advanced UAS applications, the strengths of KVM and Docker need to be integrated. Live migration on ARM-based devices also needs to be realised for both KVM and Docker.
In this section, we investigate the performance of the proposed airborne computing platform in supporting real UAS applications. In particular, we first use OpenDroneMap for UAS image processing to illustrate the benefits of virtualisation. We then further investigate the performance of two advanced UAS onboard computing tasks, real-time object detection and coded distributed computing.
OpenDroneMap is an open-source UAS image processing software [81]. In this study, we first use the image resizing and 3D model reconstruction functions in OpenDroneMap that require different amount of computing resources to investigate the impact of virtualisation on the computing performance. Fig. 8 shows the average execution time of the two functions to process a UAS image with size of 3.9 MB in different virtualisation environments [UAS images are downloaded through this link: https://github.com/ OpenDroneMap/odm_data_copr.git.]. The results demonstrate the advantage of Docker over KVM, especially in computing complicated UAS onboard computing tasks. The 3D geographical model reconstructed from 41 2D UAS images is shown in Fig. 9. We next use OpenDroneMap to demonstrate the benefits of virtualisation in facilitating resource management for UAS. Generally, virtualisation provides developers with the convenience to run multiple applications simultaneously without considering resource sharing and context switches among processes, which will increase the execution time of the applications. To illustrate this fact, we first conduct experiments to show the consequence of running two applications simultaneously when virtualisation is not applied. Fig. 10a shows the execution time of the LU application (cubic size is set to 36 × 36 × 36) and the image resizing function in OpenDroneMap (processes 41 UAS images) when they run separately on the airborne computing platform compared to the case when they run simultaneously. As we can see from this figure, when the two applications run simultaneously, the execution time of both applications increases significantly, and the LU application even takes more time than the OpenDroneMap application.
We then implement virtualisation on the airborne computing platform, and run the two applications simultaneously but in different guests. For better overall performance, the guest that runs the LU application is allocated with one CPU core, and the one that runs the more computation-intensive OpenDroneMap application is allocated with three CPU cores. As shown in Fig. 10b, virtualisation helps improve the overall computing performance significantly through resource allocation and isolation, despite the associated overhead.
Real-time object detection is crucial for many UAS applications including search and rescue, traffic monitoring, infrastructure inspection, and reconnaissance. As this type of task is computationally demanding, it is typically executed at ground stations or the cloud. In this study, we show that real-time object detection can be achieved onboard of UAS even with virtualisation.
Consider the scenario where UAS is dispatched to detect and track humans in a search and rescue mission. To achieve this, we implement a deep neural network (DNN) model [82] on the airborne computing platform, which is built on GPU and uses NVIDIA TensorRT and cuDNN. This model has been pre-trained for human detection. We use ten images captured from a UAS action video [83]
The onboard computing performance of UAS can be further enhanced by allowing tasks to be distributed over multiple platforms. Traditional distributed systems that allocate nonoverlapping tasks to different computing nodes are sensitive to system noises such as stragglers and communication bottlenecks [84] and thus may not be suitable for UAS of high mobility and uncertain trajectories. Recently, coded computation was developed in [84] to address this issue. In this study, we investigate the performances of both uncoded and coded computations on the proposed airborne computing platform. Before we show the experimental results, let us first use an example to describe the key ideas of the two approaches.
Consider the matrix multiplication problem described in [84], which aims to multiply a large input matrix X with another prestored matrix A. To reduce the computation time, the traditional approach (see Fig. 12a for an illustration) distributes the task by storing sub-matrices A i of A at different computing nodes called worker nodes, where A = [A 1 ; A 2 ; …; A n ] and n is the total number of sub-matrices. To compute AX, a master node first sends X to all worker nodes. Each worker node then computes A i X and sends the result back to the master node. As the master node cannot recover AX until all results are received, the efficacy of this approach is bounded by the slowest worker node, i.e. the straggler. The coded computation (see Fig. 12b for an illustration) addresses this issue by introducing redundancy into the computation through erasure codes. For instance, consider the matrix multiplication problem with n = 2, the coded approach introduces an additional worker node that stores A 1 + A 2 . Therefore, the master node can recover AX upon receiving the results from any two worker nodes. For instance, if A 1 X and (A 1 + A 2 )X arrive at the master node first, AX can be recovered by AX = [A 1 X;
To evaluate the performances of the uncoded and coded computations, we implement each approach to solve the matrix multiplication problem with n = 2. In particular, we create three containers as the worker nodes in one airborne computing platform, and one container as the master node in another platform. Each container is assigned with one CPU core. Containers on different airborne computing platforms are linked through the Loco M5 to simulate the directional-antenna based long-distance U2U communications. We then create two 800 × 800 random matrices, A and X. Matrix A is divided equally into two sub-matrices A 1 and A 2 of size 400 × 800. The execution time of the two approaches to compute AX is provided in Table 4, where two scenarios are evaluated. In the first scenario, only matrix multiplication is performed within each container and thus no straggler exists. In the second scenario, a CPU stress test is executed concurrently in one of the worker nodes to consume its computing resources. This worker node thus becomes a straggler. The results shown in Table 4 illustrate the robustness of the coded computation to system noises such as stragglers. In the future, we will extend this study to achieve optimal task allocation and resource management for networked airborne computing using coded computation.
In this paper, we developed a new UAS-based airborne computing platform to address the onboard computing limitations of existing UAS platforms so as to support UAS-enabled MEC and to enable more advanced UAS applications. This airborne computing platform was designed from three aspects: hardware, software, and applications. To design the hardware, we first investigated the desired features for the onboard computing hardware, and then conducted a comprehensive comparison study among state-of-theart single-board computers to select a suitable one as the computing unit. A prototype was then designed and implemented, which not only contains the computing unit, but also hardware for UAS mobility, communications, and control. To design the software, we investigated two representative virtualisation techniques, VM using KVM and container using Docker, and evaluated their performances from various aspects. Through comprehensive experimental studies, we find that Docker outperforms KVM in most performance aspects, including computing, networking, isolation of most hardware resources, power consumption, and resource usage. Docker also successfully virtualises all CPU cores and GPU in Jetson TX2. On the other hand, KVM is more secure. Finally, we studied three real UAS applications, including UAS image processing, real-time object detection, and coded distributed computing, to demonstrate the performance, applicability and potentials of the proposed airborne computing platform.
In the future, we will investigate the integration of KVM and Docker to maximise their strengths. We will also study the KVM and Docker based live migration and distributed computing techniques to enable networked airborne computing that shares resources among multiple UAS. We will also explore UAS mobility control and computation offloading strategies [85] to optimise the computing services to ground users.
IET Commun. © The Institution of Engineering and Technology 2019
IET Commun. © The Institution of Engineering and Technology 2019
IET Commun. © The Institution of Engineering and Technology 2019