The system consists of the following main entities:

• The vUAV that represents a virtual quadcopter that can perform a flight in the context of a mission. vUAVs can be configured to run in a software-in-the-loop (SITL) mode within a VM, or in a hardware-in-the-loop (HITL) mode natively on the hardware of an embedded computer.

 

• The wireless network simulator that is responsible for simulating the wireless communication among the vUAVs (optionally also between the vUAVs and the RAWFIE testbed).

 

• The virtual camera sensor service (VCS) that is responsible for serving aerial images to one or more vUAVs.

 

• The RAWFIE testbed, which is the entry point of the AeroLoop system, and runs the RAWFIE Resource Controller through which vUAVs interact with the rest of the RAWFIE infrastructure.

 

• The AeroLoop manager that is used to perform the necessary initialization and control of the previous system entities.

 

For better modularity and flexibility, each of these system entities is packaged as a separate Linux-based Virtual Machine (VM) that runs on top of the KVM hypervisor. The VM integrates all the software components that are required for the implementation of the respective functionality as well as for the interconnection and management of these entities. As an exception, when a vUAV is configured in the HITL mode, the software stack runs directly on an embedded computing platform, which is the same as the one used for the WIZZIT quadcopters.

The system-internal data exchange and management interactions between the AeroLoop manager and the management agents of the vUAV, WiFi and VCS entities, are performed via the dedicated management channel of the AeroLoop system. This is implemented using the native virtual networking facility of KVM, and is accessed within each system entity via the wired network interface eth0. All management components are implemented in Python, and interact with each other using two different mechanisms. On the one hand, the AeroLoop manager issues control commands to the vUAV, WiFi and VCS agents via RPCs using the zerorpc framework. On the other hand, the position updates of the vUAVs are propagated within the AeroLoop system via a pub/sub scheme using the zmq framework. More specifically, each vUAV agent periodically publishes the vehicle’s position, and the WiFi agent, VCS agent and the AeroLoop manager subscribe for position messages.

The application running on the vUAVs can communicate with each other and the RAWFIE testbed using the WiFi and Ethernet channels. The WiFi channel is implemented using the NS3 simulation environment, and is accessed within the VMs via the wireless network interface wlan0. It is intended for the ad-hoc wireless communication among the vUAVs. Optionally, it can also be used for the communication between the vUAVs and the RAWFIE testbed. The Ethernet channel is primarily intended for the communication between the vUAVs and the RAWFIE testbed. Like the management channel, it is implemented using the native virtual networking facility of KVM, and is accessed within the VMs via the wired network interface eth1. Compared to the WiFi channel, the Ethernet channel allows for a more reliable communication between the vUAVs and the RAWFIE testbed, and can be used to mimic more robust telecommunication links that do not suffer any interference or collisions from the ad-hoc WiFi communication that takes place among the vUAVs.