RAPTURE: a Remotely Accessible Platform of Testbeds for UAS
Research and Education
Justin S. Lee∗ , Nicholas Palmer† , Junfei Xie‡ , Yan Wan§ , Kejie Lu¶ , Shengli Fu‖
The development of unmanned aerial systems (UAS) is a highly cross-disciplinary subject,
demanding a broad range of expertise to construct complete systems from scratch. Open and standardized hardware testbeds have the potential to accelerate UAS development and mitigate the barrier to entry in this rapidly growing field. In this paper, we aim to develop an open platform that offers users remote access to a shared network of UAS testbeds, thereby making UAS development more accessible for both research and educational use.
I. Introduction n recent years, we have witnessed rapid progress and increasing interest in unmanned aerial systems (UAS) within I both industry and academia. UAS have been successfully applied to wildfire management[1], package delivery [2], crop monitoring[3], search and rescue[4], and plenty of other niche uses. Recent advances in automation, computer vision, and artificial intelligence offer computationally complex solutions to solve problems in these applications. Within the advanced computing context of many new UAS applications, much of the research is focused on developing software solutions [5, 6] instead of enhancing the hardware design of the UAS. For example, a user developing aerial photogrammetry may only need a generic drone to get their system airborne along with a generic set of sensors and computing resources to support their application. To evaluate the proposed software solutions, many existing studies in the field of UAS have predominantly relied on simulations, largely attributed to the difficulties and expenses in building a UAS hardware testbed from scratch and the restrictions posed by FAA regulations on conducting flight tests. Nonetheless, hardware testing is crucial for thorough validation. This transition from simulations to hardware testing remains a major hurdle in UAS development. Surmounting this hurdle could involve creating an open multi-UAS hardware testbed that offers public remote access, allowing users to test diverse software solutions on it. Yet, there have been limited endeavors in this direction. One related initiative is the FIT IoT-Lab[7], which is an open hardware platform geared toward research in wireless communications technologies. The platform hosts thousands of nodes in various hardware configurations that users can execute experiments on. However, the FIT IoT-Lab concentrates on RF validation through embedded systems, and is not tailored for UAS applications. In our previous studies [8–12], we developed a flexible and extensible networked airborne computing platform that consists of multiple UAS with full functionality. Each UAS comprises four core units to enable control, communication, and computing functionalities, including (1) a quadcopter unit for lifting and mobility; (2) a control unit for mobility control of UAS; (3) a communication unit for ground-to-air/air-to-ground and air-to-air communications, and (4) a computing and storage unit for onboard processing and data storage. In this paper, we aim to enable remote access to our hardware platform, allowing users around the world to test their UAS software solutions on realistic hardware testbeds. This will greatly lower the barrier to entry for participating in UAS development, by eliminating the necessity for developers to invest in or construct their own testbeds. To make our networked airborne computing platform remotely and easily accessible, containerization is a promising technique. Containerization in the cloud computing infrastructure has become an integral factor in the trend toward portable micro-service oriented computing and is beginning to be adopted in more edge-centric areas like UAS both in industry and among the research community. The "tactical cloudlets" introduced in [13] exemplifies this trend. These mobile cloud computing resources, situated near the edge, are designed to support computation offloading and data staging from handheld devices, demonstrating enhanced overall performance, energy efficiency, and availability. More recently in [14], Red Hat describes their collaboration with Lockheed Martin utilizing the MicroShift Kubernetes ∗ Undergraduate Student, Department of Electrical and Computer Engineering, San Diego State University, AIAA Student Member † Undergraduate Student, Department of Electrical and Computer Engineering, San Diego State University, AIAA Student Member ‡ Associate Professor, Department of Electrical and Computer Engineering, San Diego State University, AIAA Senior Member, Corresponding
Author, email: jxie4@sdsu.edu
§ Distinguished Professor, Department of Electrical Engineering, The University of Texas at Arlington, AIAA Associate Fellow ¶ Professor, Department of Electrical and Computer Engineering, University of Puerto Rico at Mayagüez ‖ Professor and Chair, Department of Electrical Engineering, University of North Texas
1 platform to handle AI computer vision workloads on-board the small Stalker military UAS platform. Recognizing the capability of containerization to facilitate robust and concurrent execution of software applications in UAS, this paper introduces RAPTURE, a Remotely Accessible Platform of Testbeds for UAS Research and Education. RAPTURE incorporates containerization within our networked airborne computing platform. Utilizing Kubernetes [15], a state-of-the-art container orchestration software, RAPTURE efficiently isolates user applications, simplifies and streamlines their deployment, and facilitates generic hardware abstractions for users. Through a user-friendly public web portal, RAPTURE allows users to upload their software solutions, conduct remote testing on our networked airborne computing platform, and seamlessly gather experimental results. In the rest of the paper, we first present the system design for RAPTURE and the preliminary results we have obtained so far in Section II. The results to be included in the final paper are then discussed in Section III.
II. System Design
In this section, we begin with an overview of the proposed system. We then delve into the details of how Kubernetes is utilized for managing user applications, along with its application architecture. Finally, we
A. Overview of the Proposed System
Fig. 1 depicts the architecture of the proposed system. Users first connect to our platform through a web portal, where they can remotely submit experiments to be run on our UAS network and access experiment results. For our initial design, our platform will only support Python applications for submission. We deemed this appropriate as Python brings support for rich libraries in UAS development such as PyTorch for machine learning, SciPy for computing, or ROS[16] for robot applications. Kubernetes is unable to run applications directly and instead needs them to be packaged into a container image. Automatically building these container images can be enabled by requiring users to provide Python applications with a consistent entry point and a list of Python module dependencies. This allows users to utilize the full suite of Python libraries, develop their applications with limited change to software architecture, and avoids requiring users to build container images themselves. Overall, the user needs to provide the following for each application: 1) The source files. 2) A requirements.txt file listing Python module dependencies.
Fig. 1 Block diagram of the proposed system.
2 3) Network ports to be forwarded. 4) Specifications for how the application should be allocated within the UAS testbeds. It is important for users to be able to specify how their application is allocated within the UAS network. This is particularly true in a network with heterogeneous testbed hardware, which can be expected as this project is scaled and developed further. If a user application requires a camera module for example, we need to verify the UAS it is allocated to actually possesses that capability. Likewise if the user wants two applications to run on the same UAS, or separate UAS for that matter. Kubernetes supports this functionality through a feature called "selectors." We will tag each robot in the network to be distinguishable via Kubernetes selectors and allow users to specify these allocation requirements in the web portal. A central server known as the server node within the Kubernetes cluster manages deployment of user applications across the UAS testbeds. Each UAS testbed acts as an agent within the Kubernetes cluster. Kubernetes’ core functionality of container orchestration makes it trivial to instantiate applications in the cluster. The primary challenge lies in adapting the cloud computing paradigm, characterized by numerous redundant containers focused on software services, to our use case that involves single instances of applications that frequently interface with device hardware. We plan to resolve this with a helper application running in a non-virtualized environment. This helper application will act as an interface through which containers can access underlying hardware resources that are otherwise inaccessible. Additionally, we plan to include a Python module that user application can import. This module will provide functions that allow users to more easily communicate with the web portal to report experimental results back, as well as to control hardware resources through the non-virtualized helper application.
B. Kubernetes Distribution Selection
A major aspects of our project is the use of Kubernetes to manage applications within the UAS network, so it is important a suitable choice is made for our Kubernetes distribution. There are many distributions available tailored to different applications; the four distributions we considered for this project are K8s, MicroK8s, MicroShift, and K3s. K8s, or Kubernetes, is the standard upstream distribution of Kubernetes. K8s is commonly used in industry for cloud computing. However, standard K8s it isn’t targeted at a resource-constrained environment like a UAS, so we looked into more lightweight options. All of the other distributions we examine are purpose-built to be lightweight and used in edge devices. MicroK8s is backed by Canonical[17], the company behind Ubuntu, and is available as a snap package for Linux environments. MicroShift is backed by Red Hat[18] and is targeted toward enterprise applications with edge devices. MicroShift is relatively new, so it is less mature than the other options and doesn’t have support for as many CPU architectures. The final distribution we examined was K3s[19], which is an open-source distribution and the most popular of the lightweight options we considered. It allows for single-command installation and cluster initialization, is packaged into a single binary, and uses a more lightweight database than the other options. After evaluating each Kubernetes distribution, we settled on K3s. We found the most valuable benefit of K3s to be its ease of use—with installation and cluster initialization able to be executed in a single command on a fresh device. This ease of use can aid future growth of the platform when more UAS testbeds are added to the network or if others want to recreate similar systems. Additionally, K3s’s use of a more lightweight database has been found to result in nearly an order of magnitude lower disk utilization compared to K8s and MicroK8s [20].
C. Kubernetes Application Architecture
Kubernetes is certainly the most integral component in our management of applications within the UAS network. We are primarily employing two Kubernetes object types in our system: Deployments and Services. To understand what each of these objects are, we will examine the use case of a client-server interaction between two applications managed by Kubernetes. Each of the client application and server application would have its own Deployment, which itself is composed of a Pod that runs a container image for the application. This hierarchy is depicted in Fig. 2.
3 Fig. 2 Hierarchy between Deployment, Pod, and Container within Kubernetes.
Deployments allow us to run the individual applications on our testbeds, but they are isolated with no way to communicate with each other. Kubernetes Services enable inter-process communication by forwarding network ports to the intended Pod. A complete diagram of the basic client-server system using Services can be seen in Fig. 3. It is noted that a single Kubernetes Deployment can have multiple redundant Pods running the server application container; and these Pods may be hosted on separate cluster nodes or devices within the network. In this case, the Service would split incoming requests between the redundant Pods—multiple robots. In the context of a UAS network where consistent communication with individual agents is desirable, this behavior should be circumvented. Therefore, our Deployments will be structured to contain only one Pod, which houses one Container. This configuration ensures that each Service corresponds to only one application instance and thus only one UAS.
Fig. 3 Communication between containerized applications using Kubernetes Service.
D. Preliminary Results
1. Cluster of Singe-board Computers
A significant portion of efforts we have made so far has been dedicated to developing the underlying Kubernetes system. We have created a K3s cluster of multiple Raspberry Pi devices and used it to arrive at the system architecture described in Section II.A. Additionally, we have written scripts for building container images from Python application source files and automatically deploying them to the cluster.
4 2. Prototype Web Interface
Fig. 4 Screenshot of an early prototype of the web interface for uploading experiments.
Fig. 4 shows a mock-up of the web interface that allows users to upload code files and experiment configuration. Our next step is to integrate the web portal experiment submission and the scripts for automatic container image building and deployment described earlier to enable running applications on the cluster fully remotely.
III. Future Results to be Included in Final Paper
The following section provides a brief outline of results to be included in the final paper.
A. Implementation of Proposed System
We will implement our proposed system and make it available for use on a public web portal. The primary areas that need to be worked on still for this are: (1) developing the non-virtualized helper application for interfacing containerized applications with hardware resources; (2) developing the Python module for communicating with the non-virtualized helper application and the web portal from the containerized user applications; and (3) expanding the web portal user interface to give a more cohesive experience in the platform.
B. Demo Projects Utilizing our Platform
Difficulties are to be expected when integrating any new system to a project development workflow, and we especially expect this to be the case with our platform due to its nature of remote access. To aid in understanding how to use our platform and its features, we will include a set of demo projects utilizing our platform. These demo projects will demonstrate how our platform can be used in an actual project and will be packaged with comprehensive documentation. Our demo projects will cover examples in navigation, cooperative computing, and computer vision.
5 C. Analysis of Platform Overhead Kubernetes can be resource intensive especially for resource-limited environments like UAS. We hope to partially mitigate this issue by using the lightweight edge-designed K3s implementation of Kubernetes. To evaluate our overhead, we will run a series of stress tests with our platform versus without our platform. Key performance metrics will include: latency, bandwidth, CPU utilization, memory usage, and disk utilization.
Acknowledgments We would like to thank the National Science Foundation under Grants CAREER-2048266 and CCRI-2235157/2235158 /2235159/2235160 for the support of this work.
References [1] Islam, S., and Hu, X., “Real-time On-board Path Planning for UAS-based Wildfire Monitoring,” IEEE International Conference on Unmanned Aircraft Systems, IEEE, Athens, Greece, 2021, pp. 527–535. https://doi.org/10.1109/ICUAS51884.2021.9476725.
[2] Grzybowski, J., Latos, K., and Czyba, R., “Low-cost autonomous UAV-based solutions to package delivery logistics,” Advanced, Contemporary Control: Proceedings of KKA 2020—The 20th Polish Control Conference, Łódź, Poland, 2020, Springer, 2020, pp. 500–507.
[3] Arriola-Valverde, S., Villagra-Mendoza, K., Méndez-Morales, M., Solórzano-Quintana, M., Gómez-Calderón, N., and Rimolo- Donadio, R., “Analysis of Crop Dynamics through Close-Range UAS Photogrammetry,” IEEE International Symposium on Circuits and Systems, IEEE, Seville, Spain, 2020, pp. 1–5. https://doi.org/10.1109/ISCAS45731.2020.9181285.
[4] Niedzielski, T., Jurecka, M., Miziński, B., Pawul, W., and Motyl, T., “First Successful Rescue of a Lost Person Using the Human Detection System: A Case Study from Beskid Niski (SE Poland),” Remote Sensing, Vol. 13, No. 23, 2021. https://doi.org/10.3390/rs13234903.
[5] Su, J., Zhu, X., Li, S., and Chen, W.-H., “AI meets UAVs: A survey on AI empowered UAV perception systems for precision agriculture,” Neurocomputing, Vol. 518, 2023, pp. 242–270.
[6] Huda, S. A., and Moh, S., “Survey on computation offloading in UAV-Enabled mobile edge computing,” Journal of Network and Computer Applications, Vol. 201, 2022, p. 103341.
[7] Adjih, C., Baccelli, E., Fleury, E., Harter, G., Mitton, N., Noel, T., Pissard-Gibollet, R., Saint-Marcel, F., Schreiner, G., Vandaele, J., and Watteyne, T., “FIT IoT-LAB: A large scale open experimental IoT testbed,” IEEE World Form on Internet of Things, IEEE, Milan, Italy, 2015, pp. 459–464. https://doi.org/10.1109/WF-IoT.2015.7389098.
[8] Wang, B., Xie, J., Li, S., Wan, Y., Gu, Y., Fu, S., and Lu, K., “Computing in the air: An open airborne computing platform,” IET Communications, Vol. 14, No. 15, 2020, pp. 2410–2419. https://doi.org/10.1049/iet-com.2019.0515.
[9] Zhang, H., Wang, B., Wu, R., Xie, J., Wan, Y., Fu, S., and Lu, K., “Exploring Networked Airborne Computing: A Comprehensive Approach with Advanced Simulator and Hardware Testbed,” Unmanned Systems, 2023.
[10] Wang, B., Xie, J., Ma, K., and Wan, Y., “UAV-based Networked Airborne Computing Simulator and Testbed Design and Implementation,” 2023 International Conference on Unmanned Aircraft Systems (ICUAS), IEEE, 2023, pp. 479–486.
[11] Lu, K., Xie, J., Wan, Y., and Fu, S., “Toward uav-based airborne computing,” IEEE Wireless Communications, Vol. 26, No. 6, 2019, pp. 172–179.
[12] Li, S., He, C., Liu, M., Wan, Y., Gu, Y., Xie, J., Fu, S., and Lu, K., “Design and implementation of aerial communication using directional antennas: learning control in unknown communication environments,” IET Control Theory & Applications, Vol. 13, No. 17, 2019, pp. 2906–2916.
[13] Lewis, G., Echeverría, S., Simanta, S., Bradshaw, B., and Root, J., “Tactical Cloudlets: Moving Cloud Computing to the Edge,” IEEE Military Communications Conference, IEEE, IEEE, Baltimore, MD, USA, 2014, pp. 1440–1446. https://doi.org/10.1109/MILCOM.2014.238.
[14] Red Hat, “Lockheed Martin, Red Hat Collaborate to Advance Artificial Intelligence for Military Missions,” Red Hat Press Releases, 2022. URL https://www.redhat.com/en/about/press-releases/lockheed-martin-red-hat-collaborate-advance-artificial- intelligence-military-missions.
[16] Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T., Leibs, J., Wheeler, R., and Ng, A., “ROS: an open-source Robot Operating System,” IEEE International Conference on Robotics and Automation Workshop on Open Source Software, 2009.
[20] Telenyk, S., Sopov, O., Zharikov, E., and Nowakowski, G., “A Comparison of Kubernetes and Kubernetes-Compatible Platforms,” IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications, Vol. 1, IEEE, Cracow, Poland, 2021, pp. 313–317. https://doi.org/10.1109/IDAACS53288.2021.9660392.
