# Advanced Software Ground Station and UAV Development for NLoS Control Using Mobile Communications

Authors: Amr AbdElHamid; Peng Zong; Bassant Abdelhamid
Journal: Discrete Dynamics in Nature and Society
 (2015)

---

## Abstract

Over the last decades, Unmanned Aerial Systems (UASs) have gained much attention due to their various applications in different sections. However, their communication range is limited to utilized communication equipment. Therefore, utilization of GSM channels opens a new prospect towards long distance UAV missions and mobile command and control centers. This paper demonstrates new design and development of a small-scale UAV and a Ground Control Station (GCS) using GSM bidirectional communications for Non-Line of Sight (NLoS) long range control. GCSs are considered the front end node in UAV guidance process. Therefore, the proposed GCS employs a two-layer framework to consider all ground pilot requirements. Moreover, a new exploitation of global weather forecast data is added to the GCS. On the other hand, the proposed airborne system utilizes a new integration of different Commercial off-the-Shelf (COTS) components and excludes short range receivers. The ground and flight tests show that stable bidirectional GSM communication is established, reliable hardware integration is accomplished, real time performance is achieved, GCS functional fidelity is obtained, and low cost is maintained. Finally, some qualitative aspects of the proposed platform are presented to address the detailed features.


---

## Body

## 1. Introduction

Recently, Unmanned Aerial Vehicles (UAVs) have a great potential in Research and Development (R&D) sections, due to their vital role in academic, industrial, and military applications [1]. Their applications domains cover search and rescue, reconnaissance, intelligent traffic monitoring, border patrol, disaster monitoring, and fire detection (just to name a few) [2]. Small-scale UAV copters, such as quadcopters and helicopters, have attracted many researchers for their unique characteristics. Quadcopters have Vertical Takeoff and Landing (VTOL) capability and perform different flight missions ranging from hovering to cruising with quite good agility and maneuverability. It is considered an ideal platform for nonlinear control law research and a good test bench for trajectory planning algorithms for both remotely piloted and autonomous missions. Designing and implementing a small-scale UAV quadcopter is considered a challenging job [3], due to its role in reducing the gap between the theoretical studies and practical engineering methodologies. During the implementation, researchers might get stuck with many difficulties such as UAV platform specification, airborne systems, communication links, Ground Control Station (GCS) software capabilities [4], and the multiplexed data logging of different inputs and outputs for the Unmanned Aerial System (UAS). Owing to the advent of Microelectromechanical System (MEMS) technology, the airborne systems are shrinking in size and weight. Moreover, using the Commercial off-the-Shelf (COTS) components, it is possible to develop airborne avionics system for a small-scale UAV quadcopter with attributes of low cost, small size, light weight, and high performance. Moreover, Global System for Mobile (GSM) communications provides a remarkable connectivity between two mobile stations (MS) for voice or data, which represents a good infrastructure for different long range and Non-Line of Sight (NLoS) applications.The main objectives of this paper are as follows:(1)
Develop an advanced GCS and a small-scale quadcopter using bidirectional terrestrial mobile networks and COTS components. The proposed scheme exploits GSM networks to provide a long NLoS control range, and COTS components maintain the low budget.
(2)
Introduce a new vision of exploiting nonlimited range weather forecast data for different GCS operational procedures. This new feature is utilized as a replica for traditional weather equipment [5].
(3)
Provide a large number of Pulse Width Modulation (PWM) control signals for payload control.
(4)
Demonstrate a new centralized high accuracy online data logging algorithm.Towards fulfilling these objectives, bidirectional cellular network communication using Point-to-Point Protocol (PPP) is introduced for exchanging the GCS flight commands and receiving the UAV feedback (surveillance data). The proposed scheme exploits VB.NET as a development language for the GCS software. The GCS is designed based on modular concept. The modular design is not only to simplify the future modifications [6] but also to minimize the budget [7]. The GCS software architecture employs two-layer framework [8]. The foreground layer contains an innovative Graphical User Interface (GUI) with geographic maps, mission planning, functional set of gauges, and state views. Additionally, a new weather forecast module is developed to support the mission designer decisions during the mission planning and the real flight. The background layer handles communication interfaces, web resources, and the data logging. The new data logging module is developed not only to record whole platform parameters, but also to measure the processing load of different software modules with a very high resolution up to 10
-
7 seconds. The GCS development utilizes many advanced programming techniques like Application Programming Interface (API), threads, Component Object Model (COM) technology, datasets, stopwatch, and many other components. On the other hand, COTS components are utilized to compose the new airborne system (avionics systems). The traditional short range RC receivers are replaced with COTS PWM controller [9, 10]. This integration facilitates controlling up to 32 PWM channels for different effective payloads. Moreover, an advanced Attitude Heading Reference System (AHRS) integrated with Global Positioning System (GPS) module is employed to deliver the UAV flight parameters to the GCS via the GSM channel.The test procedures cover many characteristics such as(
1
) GSM communication latency using communication worst-case scenarios; (2) processing delays for different input/output (I/O) interface modules; (3) ground tests of the proposed avionics system using bidirectional GSM communication; and (4) flight test for whole platform for performance evaluation. Finally, some qualitative aspects of the proposed scheme and other similar systems are demonstrated. Results show that the developed GCS software achieves a NLoS bidirectional control for the UAV using PPP GSM communications at 9600 bps (as a communication worst-case scenario) with a delay less than 300 ms, the software processing delay is accurately measured and satisfies the system constraints, and the ground/flight tests validate the whole developed systems.Many difficulties and challenges have been conquered toward fulfilling the mentioned objectives:(
1
) integration of different COTS components in a compatible scheme; (2) integration of real weather forecast data with the GCS platform; (3) instantaneous handling of multiple inputs and outputs interfaces by different software modules simultaneously; (4) high resolution online data logging module which is in order of 10
-
7 seconds; (5) preparation and evaluation procedures for the ground and flight tests; and (6) exploitation of GSM in PPP for exchanging bidirectional real time data.Unlike [11–19], the proposed scheme (
1
) achieves a bidirectional GSM communication for both uplink and downlink with latency less than 300 ms, (2) opens new prospect towards controlling UAV from a moving GCS, (3) provides long range NLoS control for aerial vehicle, (4) provides a large number of controlled PWM channels (up to 32 channels) for more payload control, (5) obtains advanced capabilities via integrating real weather forecast data, (6) consider worst communication scenarios (low baud rates) for bidirectional communication channel, (7) provides online recording with high resolution, and (8) maintains high functional fidelity and low budget.The rest of this paper is organized as follows: Section2 presents the related work to the proposed system, Section 3 demonstrates the developed UAV description, Section 4 illustrates the control and communication scheme and ground station development, Section 5 comprehensively presents the conducted tests and results, Section 6 addresses some qualitative aspects of the proposed platform, and, finally, the conclusions are presented in Section 7.


## 2. Related Work

Software engineering plays an active role in the growth picture of UAV development due to its simple maintenance procedures and large Mean Time Between Failures (MTBF). In [11], a complete road surveillance system consisting of a UAV and over 30 Unattended Ground Sensors (UGSs) was designed and simulated. The system was also flight tested in a realistic operating environment. The system employs LoS Wi-Fi communications for data exchange and gathering. On the other hand, National University of Defense Technology had developed its own small-scale UAV based on Raptor 90 hobby helicopter, LoS RC transmitters and RF modems, and digital signal controller as an airborne CPU [12]. In [18], software and hardware architectures are used in the design and implementation of a small semiautonomous fixed-wing UAV. The presented system utilizes RC transmitter/receiver (70 MHz LoS link) for guidance commands, video downlink (2.4 GHz LoS link) for onboard camera, and bidirectional data link (900 MHz LoS link) between the autopilot and the GCS. The data-logger commands the autopilot to store the state of the UAV for a specified period of time. When the log is completed, it is transmitted back to the ground station for viewing. In [15], the development of UAV system is introduced for remotely piloted missions using telemetry data link and Futaba RX Control Module (FCM) for up to two miles.In [13], a web access to real time flight data for a modern GCS is achieved, in addition to some standard functions, such as receiving data in real time, storing data, and displaying data. Authors in [14] developed a systematic approach for Micro Aerial Vehicle (MAV) trajectory generation addressing the characteristic issues of MAV flights in winds. In [16], the guidance, navigation, and control system of a small Vertical Takeoff and Landing (VTOL) unmanned tripropeller air vehicle based on a six-degree-of-freedom nonlinear dynamic model is designed and developed. In [17], the development of a real time embedded onboard computer and GCS software system for a UAV helicopter is introduced. An embedded computer system is attached at the lower portion of HeLion helicopter to perform multiple tasks including data acquisition and measurement, servo driving, automatic flight control implementation, communications, and data logging, while the presented GCS gives a graphical user interface for monitoring the real time status of the UAV. The GUI consists of four views including command window view, curve view, state view, and 3D view. In [19], a balloon airship is controlled via Remote Control (RC) transmitter using two different communication links. The GSM and GPRS are utilized for uplink and downlink to establish the flight control and surveillance system, respectively.Additionally, the National University of Singapore has presented UAV software designing [21] and hardware modules [22, 23]. At Georgia Institute of Technology, a small Navigation, Guidance, and Control (NGC) system was developed using Field Programmable Gate Array (FPGA) and Digital Signal Processor (DSP) technologies for advanced UAV behavior [24, 25]. Moreover, some other different institutes developed their own UAVs due to their impact on the growth picture of the scientific R&D roadmap [26–28].According to the aforementioned literature, the surveyed platforms miss some key features like the following:(
1
) the long distance and NLoS operating range with low bidirectional latency; (2) the large number of PWM control signals at the onboard system for extended payload control; (3) the real weather forecast capabilities during mission planning and real operational flight; (4) the online ground based accurate data logging; (5) the functional fidelity of the developed GCS software; and (6) ease of development requirements.Thus, this paper demonstrates a new advanced software-based GCS and UAV quadcopter implementation to facilitate advanced long range NLoS remotely piloted missions to fulfill the above-mentioned aspects.


## 3. Proposed UAV Description

This section focuses on demonstrating the UAV description with important onboard components integration such as (a) advanced AHRS with integrated GPS module, (b) multiple channel PWM signal controller, and (c) the proposed integrated avionics module with GSM communication device. Figure1 illustrates the final form of the custom UAV quadcopter development, which consists of Tarot 650 carbon fiber frame. It is equipped with four Electronic Speed Controllers (ESC), four brushless motors, two pairs of carbon fiber propellers, and ardupilot mega 2650 as a flight controller. The power source is provided through Lithium-Polymer (Li-Po) battery pack with a capacity of 10000 mAh. The detailed specification of the utilized quadcopter is listed in Table 1. The following subsections illustrate the proposed avionics components and their final integration form to achieve the mentioned objectives.Table 1
Quadcopter specification.
Specification
Value
Frame model
Tarot 650
Frame materials and propellers
Carbon fiber
Motors
T-motors MN-4012 480 KVA
ESC
60 A opto 2–6 LiPo/600 Hz
Battery
6-cell, 10000 mAH, 25C
Flight controller
Ardupilot MEGA 2.6
Communication system
Wavecom GSM modem
Developed COTS avionics system
GSM, AHRS plus GPS module, and PWM controller
Weight
2.75 KgFigure 1
Proposed UAV quadcopter.


### 3.1. Advanced Attitude and Heading Reference System Plus GPS Module

For small-scale quadcopter, it is necessary to have the vital information about the vehicle during the mission, such as flight essential signals and the vehicle coordinates during the entire flight profile. Therefore, an advanced AHRS plus GPS module is provided. AHRS provides 3D orientation by integrating gyroscopes and fusing this data with accelerometer data and magnetometer data. With sensor fusion, drift from the gyroscopes integration is compensated by reference vectors, namely, gravity and the earth magnetic field. This makes AHRS a more cost effective solution than conventional high-grade Inertial Measurement Units (IMUs) that only integrate gyroscopes and rely on a very high bias-stability of the gyroscopes.As shown in Figure2(a), a light weight, small size compact enhanced COTS AHRS integrated with GPS on the same board is selected to deliver the UAV measurements. As illustrated in Figure 2(b), it consists of three-axis MEMS gyroscope, three-axis accelerometer, three-axis compass, and pressure/temperature sensors and integrated with a GPS receiver based on u-blox module. The manipulation of all components is performed using the ARM Cortex microcontroller (STM32F103). The specification of the COTS AHRS plus GPS module is shown in Table 2. This combination of MEMS sensors is manipulated by the ARM microcontroller to produce three types of data messages (labeled as A1, A2, and A3): (
1
) Message (A1) contains the attitude data, altitude, pressure, and temperature (18-byte data frame); (2) Message (A2) contains the raw sensors measurements gyroscope, accelerometer, and magnetic compass (22-byte data frame); (3) Message (A3) contains the GPS data longitude, latitude, altitude, number of locked satellites, heading, and speed (19-byte data frame). Furthermore, using TTL to RS232 converter, all these data are transmitted to the airborne GSM mode to be delivered for the GCS.Table 2
COTS AHRS plus GPS specifications.
Specification
Value
Specification
Value
Yaw accuracy
0.1°
Three-axis accelerometer
Programmable full scale range of ±2 g, ±4 g, ±8 g, and ±16 g
Pitch accuracy
0.1°
Longitude accuracy
10−6°
Roll accuracy
0.1°
Latitude accuracy
10−6°
Altitude accuracy
0.1 m
Size
64 mm × 20 mm × 5 mm
Temperature accuracy
0.1°C
Operating temperature
−10°C–60°C
Pressure accuracy
10 Pa
Weight
20 gramsFigure 2
Attitude Heading Reference System. (a) Printed Board Layout (b) detailed components.
(a)
(b)As the GPS signals in altitude channel miss some accuracy, the altitude signal from pressure sensor is important to correct any missed accuracy. The integrated barometer is able to provide altitude signal through detecting the change of air pressure. It can provide calibrated digital air pressure and temperature information. The formula for converting the air pressure to altitude is as follows [12]:(1)
h
bar
=
h
0
+
T
b
L
b
·
P
bar
P
b
-
R
·
L
b
/
g
0
·
M
-
1
,where h
bar is the barometric altitude, h
0 is the height at the bottom of atmospheric layer (sea level height), T
b is the temperature at sea level in kelvin [K], L
b is the standard temperature lapse rate =
-
0.0065
K
/
m, P
bar is the barometer pressure measurements, P
b is the pressure at sea level [Pa], R is universal gas constant =
8.31432
N
·
m
/
mol
·
K, g
0 is the gravitational acceleration constant =
9.80665
m
/
s
2, and M is the molar mass of Earth’s air =
0.0289644
[
kg
/
mol
].Hence, the air pressure is affected by various factors; then barometric attitude will be also affected. As a result, the measurement of barometric altimeter cannot be used directly. According to real measurements for a fixed location over different time, barometric altitude is found quite different. However, due to the short flight time, such difference can be modeled as a constant bias [12]. This calculation is performed by the GCS which has more processing capabilities. It is worthily noted that the onboard GPS antenna can be replaced with another external one upon the user demands (if this module will be mounted on a metal case).


### 3.2. PWM Servo Motor Controller

The majority of UAVs utilizes servo motors for controlling the control surfaces or ESCs for brushless motors. These pieces of equipment utilize PWM signals as a control input. As shown in Figure3(a), an integrated COTS PWM servo motor controller is selected to provide the required PWM signals for the flight controller [9]. The selected PWM controller can provide up to 32 control signals simultaneously. Additionally, it is interfaced via RS-232 directly with custom user adjustment for the baud rate. Moreover, the PWM signals supply voltage can be powered from the controller power or can have external power supply. As providing RC guidance device with 32 channels costs a large budget, designing the proposed UAV quadcopter with this PWM controller provides a large number of channels with low cost. This is considered one of the conquered challenges in this paper. As shown in Figure 3(b), the data format for such controller consists of fixed headers and footer and dynamic part, which represent the channel number, and the PWM value. As a result, when the GCS captures the RC guidance device commands, it encapsulates the received data into the illustrated format to be delivered to the PWM controller through the GSM link.Figure 3
Multiple channel PWM controller. (a) Printed Board Layout [9], (b) four-channel data format sample.
(a)
(b)


### 3.3. Proposed Integrated Avionics Module

Finally, the airborne system could be integrated as shown in Figure4. The developed avionics module consists of three layers’ structure. The GSM modem is at the bottom layer, the PWM controller is in the middle layer, and the AHRS plus GPS module is at the top layer (for maximum signal strength of the GPS signals). All these modules are mounted on Tarot 650 carbon fiber base. Typically, the integration between GSM module and the PWM controller is considered a replica for traditional RC receiver to obtain long range of NLoS control with more control channels.Figure 4
Integrated airborne system structured layers.


## 3.1. Advanced Attitude and Heading Reference System Plus GPS Module

For small-scale quadcopter, it is necessary to have the vital information about the vehicle during the mission, such as flight essential signals and the vehicle coordinates during the entire flight profile. Therefore, an advanced AHRS plus GPS module is provided. AHRS provides 3D orientation by integrating gyroscopes and fusing this data with accelerometer data and magnetometer data. With sensor fusion, drift from the gyroscopes integration is compensated by reference vectors, namely, gravity and the earth magnetic field. This makes AHRS a more cost effective solution than conventional high-grade Inertial Measurement Units (IMUs) that only integrate gyroscopes and rely on a very high bias-stability of the gyroscopes.As shown in Figure2(a), a light weight, small size compact enhanced COTS AHRS integrated with GPS on the same board is selected to deliver the UAV measurements. As illustrated in Figure 2(b), it consists of three-axis MEMS gyroscope, three-axis accelerometer, three-axis compass, and pressure/temperature sensors and integrated with a GPS receiver based on u-blox module. The manipulation of all components is performed using the ARM Cortex microcontroller (STM32F103). The specification of the COTS AHRS plus GPS module is shown in Table 2. This combination of MEMS sensors is manipulated by the ARM microcontroller to produce three types of data messages (labeled as A1, A2, and A3): (
1
) Message (A1) contains the attitude data, altitude, pressure, and temperature (18-byte data frame); (2) Message (A2) contains the raw sensors measurements gyroscope, accelerometer, and magnetic compass (22-byte data frame); (3) Message (A3) contains the GPS data longitude, latitude, altitude, number of locked satellites, heading, and speed (19-byte data frame). Furthermore, using TTL to RS232 converter, all these data are transmitted to the airborne GSM mode to be delivered for the GCS.Table 2
COTS AHRS plus GPS specifications.
Specification
Value
Specification
Value
Yaw accuracy
0.1°
Three-axis accelerometer
Programmable full scale range of ±2 g, ±4 g, ±8 g, and ±16 g
Pitch accuracy
0.1°
Longitude accuracy
10−6°
Roll accuracy
0.1°
Latitude accuracy
10−6°
Altitude accuracy
0.1 m
Size
64 mm × 20 mm × 5 mm
Temperature accuracy
0.1°C
Operating temperature
−10°C–60°C
Pressure accuracy
10 Pa
Weight
20 gramsFigure 2
Attitude Heading Reference System. (a) Printed Board Layout (b) detailed components.
(a)
(b)As the GPS signals in altitude channel miss some accuracy, the altitude signal from pressure sensor is important to correct any missed accuracy. The integrated barometer is able to provide altitude signal through detecting the change of air pressure. It can provide calibrated digital air pressure and temperature information. The formula for converting the air pressure to altitude is as follows [12]:(1)
h
bar
=
h
0
+
T
b
L
b
·
P
bar
P
b
-
R
·
L
b
/
g
0
·
M
-
1
,where h
bar is the barometric altitude, h
0 is the height at the bottom of atmospheric layer (sea level height), T
b is the temperature at sea level in kelvin [K], L
b is the standard temperature lapse rate =
-
0.0065
K
/
m, P
bar is the barometer pressure measurements, P
b is the pressure at sea level [Pa], R is universal gas constant =
8.31432
N
·
m
/
mol
·
K, g
0 is the gravitational acceleration constant =
9.80665
m
/
s
2, and M is the molar mass of Earth’s air =
0.0289644
[
kg
/
mol
].Hence, the air pressure is affected by various factors; then barometric attitude will be also affected. As a result, the measurement of barometric altimeter cannot be used directly. According to real measurements for a fixed location over different time, barometric altitude is found quite different. However, due to the short flight time, such difference can be modeled as a constant bias [12]. This calculation is performed by the GCS which has more processing capabilities. It is worthily noted that the onboard GPS antenna can be replaced with another external one upon the user demands (if this module will be mounted on a metal case).


## 3.2. PWM Servo Motor Controller

The majority of UAVs utilizes servo motors for controlling the control surfaces or ESCs for brushless motors. These pieces of equipment utilize PWM signals as a control input. As shown in Figure3(a), an integrated COTS PWM servo motor controller is selected to provide the required PWM signals for the flight controller [9]. The selected PWM controller can provide up to 32 control signals simultaneously. Additionally, it is interfaced via RS-232 directly with custom user adjustment for the baud rate. Moreover, the PWM signals supply voltage can be powered from the controller power or can have external power supply. As providing RC guidance device with 32 channels costs a large budget, designing the proposed UAV quadcopter with this PWM controller provides a large number of channels with low cost. This is considered one of the conquered challenges in this paper. As shown in Figure 3(b), the data format for such controller consists of fixed headers and footer and dynamic part, which represent the channel number, and the PWM value. As a result, when the GCS captures the RC guidance device commands, it encapsulates the received data into the illustrated format to be delivered to the PWM controller through the GSM link.Figure 3
Multiple channel PWM controller. (a) Printed Board Layout [9], (b) four-channel data format sample.
(a)
(b)


## 3.3. Proposed Integrated Avionics Module

Finally, the airborne system could be integrated as shown in Figure4. The developed avionics module consists of three layers’ structure. The GSM modem is at the bottom layer, the PWM controller is in the middle layer, and the AHRS plus GPS module is at the top layer (for maximum signal strength of the GPS signals). All these modules are mounted on Tarot 650 carbon fiber base. Typically, the integration between GSM module and the PWM controller is considered a replica for traditional RC receiver to obtain long range of NLoS control with more control channels.Figure 4
Integrated airborne system structured layers.


## 4. Proposed Control and Communication Scheme

Before describing the proposed scheme, it is mandatory to mention targeted platform requirements to know the complete scope of the proposed UAS. Taking into consideration the general UAS requirements in [29], the proposed platform has to fulfill the following requirements rather than other systems in the literature. These requirements could be summarized as follows:(1)
Achieve NLoS latency for both uplink and downlink less than 300 ms.
(2)
Consider communication worst-case scenario by using 9600 bps baud rate.
(3)
Support an operational altitude up to 1000 m.
(4)
Software modules responsible of I/O operations (RC interface module and GSM interface module) should consume less than 1 ms to be negligible with respect to the NLoS latency (300 ms).
(5)
Avoid airborne data logging to prevent data loss in case of any crash. It should be allocated at GSC with resolution up to10
-
7 seconds.
(6)
Provide bidirectional NLoS communications for the proposed COTS avionics (PWM controller, AHRS), while whole system is running to check that sensors measurements are consistent and noise free.
(7)
Achieve good functional fidelity via advanced GUI capabilities (mapping, gauges, synthetic weather map, etc.) during real flight missions.Finally, the proposed platform should be validated via a complete flight test to ensure the performance and the consistency of different sensors measurements (such as GPS, barometer, and magnetometer data).Towards fulfilling the mentioned requirements, Figure5 demonstrates the proposed control and communication scheme, which consists of two main systems: (
1
) the ground system which contains standard RC transmitter, portable laptop equipped with the developed GCS software package, and the communication device (GSM modem) to communicate with the UAV; (2) airborne system which consists of UAV quadcopter (motors, ESCs, and flight controller), integrated AHRS plus GPS, multiple PWM channel controller, and an airborne GSM modem. In Figure 5 the labeled numbers demonstrated the data flow sequence of the proposed scheme which is as follows. (
1
) The GCS software captures the ground pilot guidance commands from the connected RC transmitter. (2) After reformatting the guidance command, it is transmitted to the GSM modem. (3) The GSM modem passes the commands to the cellular network to the airborne modem (uplink communication). (4) The airborne GSM modem sends the data to the PWM controller to generate the required signals to the flight controller in (5). (6) The AHRS module sends the measured data (feedback) to the airborne GSM modem. (7) The airborne modem passes the feedback to the cellular network to be delivered to the GCS (downlink communication). (8) The GCS manipulates the feedback data to provide the ground pilot with the required advanced visualization.Figure 5
Proposed control and communication scheme.It can be deduced that, after the GSM modems establish an active bidirectional communication link, the ground pilot commands are directly captured by the GCS software and transmitted to the GSM modem. As a result, the operation UAV range is not limited to the transmission range of the RC transmitter any more. The proposed platform can control the UAV at any point covered by the terrestrial cellular network using NLoS communications. Typically, for traditional RC transmitter/receiver, the more channels are obtained, the more budget is required. However, the proposed scheme replaces the traditional limited channel RC receiver with the 32-channel COTS PWM controller and maintains the low cost criteria. The proposed scheme facilitates dynamic movement of both the GCS and the UAV, which represents a feasible, low cost, and real time solution towards mobile command and control centers. Also, these features are considered to be some of the conquered challenges in this paper. This communication topology is validated for UAS for its tiny time constraints, but not limited to this, and the proposed GSM bidirectional communication can be extended to other ground or surface remote control vehicles (conditional to GSM coverage).On the other hand, to build a GUI for the targeted GCS, several commercial and open source existing frameworks can be used such as visual studio.NET (including VB.NET and C#) and python. In this paper, VB.NET is selected as a high level programming language due to its various capabilities such as hardware interfacing, in-memory database, threading, APIs, stopwatches, data storage/manipulation, and COM technology.As shown in Figure6, the proposed GCS block diagram is illustrated, which represents a two-layer framework (foreground and background layers). The GCS software consists of interfacing modules, geographical modules, web resources manipulation, data logging, and playback. Since the proposed GCS extremely relies on software modules and components, therefore, the main development components are demonstrated in the following subsections.Figure 6
Ground Control Station block diagram.


### 4.1. GCS Graphical User Interface Console

The most important component in the GUI is the geographic reference map. It allocates all main important objects in the GCS (GCS coordinates, UAV coordinates, and waypoints). For globalization purpose, the geographic reference map should be in a standard format and style, for more compatibility with other commercial packages. A standard mapping module is developed to facilitate the use of maps, routing, geocoding from map providers. The maps module achieves a mouse move accuracy for the GUI console up to10
-
6 degrees. Via the utilization of the map provider APIs, this module can achieve accessibility to the global map resources.Typically, there is no successful mission training without a powerful and accurate mission planning module. Therefore, whatever the type of the operation (real/simulated or remotely piloted/autonomous), mission planning is considered an important feature of the GUI console. The mission trajectory and the way points design are overlaid over the geographic map, while a distance measurement module is developed to calculate the designed trajectory length. The mission designer stores the trajectories into a standard Keyhole Markup Language (KML) file [29] which provides a bidirectional importing/exporting of designed mission with standard packages like Google Earth. Moreover, during the real flight, the mission viewer module loads the targeted mission into in-memory database for rapid access.


### 4.2. Remote Control Guidance Device Interface

A complete software module is developed to capture the RC transmitter commands according to the delivered Interface Control Document (ICD). This RC interface module is implemented in a separate thread to be independent of the GCS activities. The complete flowchart of RC interface thread is illustrated in Figure7. It is clear that the RC interface thread is an endless one, starts when the GUI application starts, detects the event which indicates that Human Interface Device (HID) is connected, gets handle of the RC HID object, reads the HID device parameters to adjust the receive buffers, reads RC data message, extracts the guidance commands from the message, saves the extracted commands to global memory, and repeats the loop for continuous capture of ground pilot commands. If the RC device is disconnected at any time, the thread will wait until it is connected again and immediately trigger a red warning in the GUI status bar.Figure 7
Remote control guidance device interface flowchart.


### 4.3. Global Weather Forecast Capability

As the proposed scheme targets long distance control via NLoS GSM communications, it is remarkable to achieve a weather data along the mission trajectory (not only at the GCS site). Therefore, by selecting an appropriate weather provider (local country or worldwide), the weather forecast data could be achieved. Obviously, this could be done after accomplishing some registration and interfacing procedures. Most of worldwide weather providers use APIs for supplying weather data to customers. The proposed GCS exploits “WorldWeatherOnline” as a worldwide instantaneous weather provider (as a sample to validate the concept). The weather provider online API explains the structure and formats of this data exchange service.Figure8(a) demonstrates the flowchart of the proposed weather interface module (which is implemented as a standalone thread). This module is responsible for the web communication with the weather providers through the implementation of the provider’s APIs. Furthermore, this module parses the provider responses into useful information and stores them into the in-memory database. These activities are controlled from mission planning tab. However, Figure 8(b) represents the useful weather data and its effect on the mission planning (for long range UAVs). It can be deduced that the overlaid weather layer supports the mission designer to setup a safe trajectory for the mission. Because of the existence of such weather layer, the mission designer avoids a side wind of speed 12 m/sec coming from direction 216 (which is illustrated in red dashed circle).Figure 8
Integration of global weather forecasting reports with the mission planning process (a) weather interface module flowchart and (b) mission planning using synthetic graphical weather layer.
(a)
(b)


### 4.4. Centralized Online Data Logging and Playback Features

The data logging module plays a vital role in recording all incoming and outgoing traffic for the whole platform. The data logging is developed using an accurate time stamping for all events. The resolution unit is measured in ticks (where 1 Tick = 10−7 seconds). All GCS interfaces, flight control commands, UAV feedback, and exchanged data among different modules are recorded. Threads are used to achieve the data logging goals to avoid any conflict with the GCS modules. However, multiple threads utilization may cause data violation and data loss. Therefore, an efficient technique is implemented to assure the consistency and integrity of all data and to maintain the high recording time resolution. This implementation relies on the thread safe containers that exist in VB.NET, which grantees the read and write operations without data violation. Algorithms 1, 2, and 3 represent 3 simultaneous threads to implement the proposed centralized data logging. It records different data sources using thread safe containers. This technique stores one multiplexed file for all received data.Algorithm 1:Proposed collecting data thread.
(1)Lock Access (Global_Buffer Array List)
(2)AddTime Stamp in Ticks
(3)AddRecording Source Label
(4)AddRecording Source Data
(5)Unlock Access (Global_Buffer Array List)Algorithm 2:Proposed data logging thread.
(1)Initialize Global_Buffer of the Type (Synchronized Array List)
(2)Initialize File_Buffer of the Type (Synchronized Array List)
(3)  Start File Manipulation Thread
(4)Loop
(5)
IfGlobal_Buffer Elements >0 then
(6)
Lock Access (Global_Buffer Array List)
(7)
Copy Global_Buffer → File Buffer
(8)
Clear All Global_Buffer
(9)
Unlock Access (Global_Buffer)
(10)Else
(11)GoTo (4)
(12)End if
(13)End loopAlgorithm 3:Proposed file manipulation thread.
(1)Loop
(2)IfFile_Buffer Elements >0 then
(3)
Lock Access (File Buffer)
(4)
Copy File_Buffer → Temp_Buffer
(5)
Clear All File_Buffer
(6)
Unlock Access (File_Buffer)
(7)Else
(8)GoTo (1)
(9)End if
(10)Loop (Temp_Buffer)
(11)
Seek to end of File
(12)
Write Temp_Buffer Data
(13)
Clear Temp_Buffer Data
(14)End Loop
(15)End loopAs a result, the playback functionalities will become more accurate, because accessing one unified time stamped file is much efficient, convenient, and faster than accessing multiple files. This software module achieves advanced data logging capabilities without the need for extra hardware equipment. Typically, this is considered to be one of the conquered challenges in this paper. The resultant high resolution data logging capabilities clearly appear in all recording activities (as will be shown in Section5).


### 4.5. Bidirectional GSM Communication (Ground and Airborne Modems)

The GSM data communications could be established through many setup profiles. The proposed scheme utilizes the PPP mode for controlling the UAV. The PPP consists of two communication parties, one of them is the master (who initiates the communication request), while the other one is slave (who answers the call). Typically, through the standard AT commands [30], the GCS can play the master role and can initiate the communication request. Figure 9 illustrates the flowchart of GSM interface module. It can be inferred that handling the dial-up connections requires more programming effort and sensitive data handling (rather than the leased line or wireless modem), due to the switching between the data and commands modes and detecting any disconnect events. As a benefit for the proposed NLoS architecture, the GCS call can be initiated either from a GSM modem or from a traditional land line modem using the Public Switched Telephone Network (PSTN) (as shown in Figure 5). This feature is an option for the stationary GCS, while for mobile GCS the proposed GSM modem is much suitable.Figure 9
Detailed flowchart of GSM interface module.


## 4.1. GCS Graphical User Interface Console

The most important component in the GUI is the geographic reference map. It allocates all main important objects in the GCS (GCS coordinates, UAV coordinates, and waypoints). For globalization purpose, the geographic reference map should be in a standard format and style, for more compatibility with other commercial packages. A standard mapping module is developed to facilitate the use of maps, routing, geocoding from map providers. The maps module achieves a mouse move accuracy for the GUI console up to10
-
6 degrees. Via the utilization of the map provider APIs, this module can achieve accessibility to the global map resources.Typically, there is no successful mission training without a powerful and accurate mission planning module. Therefore, whatever the type of the operation (real/simulated or remotely piloted/autonomous), mission planning is considered an important feature of the GUI console. The mission trajectory and the way points design are overlaid over the geographic map, while a distance measurement module is developed to calculate the designed trajectory length. The mission designer stores the trajectories into a standard Keyhole Markup Language (KML) file [29] which provides a bidirectional importing/exporting of designed mission with standard packages like Google Earth. Moreover, during the real flight, the mission viewer module loads the targeted mission into in-memory database for rapid access.


## 4.2. Remote Control Guidance Device Interface

A complete software module is developed to capture the RC transmitter commands according to the delivered Interface Control Document (ICD). This RC interface module is implemented in a separate thread to be independent of the GCS activities. The complete flowchart of RC interface thread is illustrated in Figure7. It is clear that the RC interface thread is an endless one, starts when the GUI application starts, detects the event which indicates that Human Interface Device (HID) is connected, gets handle of the RC HID object, reads the HID device parameters to adjust the receive buffers, reads RC data message, extracts the guidance commands from the message, saves the extracted commands to global memory, and repeats the loop for continuous capture of ground pilot commands. If the RC device is disconnected at any time, the thread will wait until it is connected again and immediately trigger a red warning in the GUI status bar.Figure 7
Remote control guidance device interface flowchart.


## 4.3. Global Weather Forecast Capability

As the proposed scheme targets long distance control via NLoS GSM communications, it is remarkable to achieve a weather data along the mission trajectory (not only at the GCS site). Therefore, by selecting an appropriate weather provider (local country or worldwide), the weather forecast data could be achieved. Obviously, this could be done after accomplishing some registration and interfacing procedures. Most of worldwide weather providers use APIs for supplying weather data to customers. The proposed GCS exploits “WorldWeatherOnline” as a worldwide instantaneous weather provider (as a sample to validate the concept). The weather provider online API explains the structure and formats of this data exchange service.Figure8(a) demonstrates the flowchart of the proposed weather interface module (which is implemented as a standalone thread). This module is responsible for the web communication with the weather providers through the implementation of the provider’s APIs. Furthermore, this module parses the provider responses into useful information and stores them into the in-memory database. These activities are controlled from mission planning tab. However, Figure 8(b) represents the useful weather data and its effect on the mission planning (for long range UAVs). It can be deduced that the overlaid weather layer supports the mission designer to setup a safe trajectory for the mission. Because of the existence of such weather layer, the mission designer avoids a side wind of speed 12 m/sec coming from direction 216 (which is illustrated in red dashed circle).Figure 8
Integration of global weather forecasting reports with the mission planning process (a) weather interface module flowchart and (b) mission planning using synthetic graphical weather layer.
(a)
(b)


## 4.4. Centralized Online Data Logging and Playback Features

The data logging module plays a vital role in recording all incoming and outgoing traffic for the whole platform. The data logging is developed using an accurate time stamping for all events. The resolution unit is measured in ticks (where 1 Tick = 10−7 seconds). All GCS interfaces, flight control commands, UAV feedback, and exchanged data among different modules are recorded. Threads are used to achieve the data logging goals to avoid any conflict with the GCS modules. However, multiple threads utilization may cause data violation and data loss. Therefore, an efficient technique is implemented to assure the consistency and integrity of all data and to maintain the high recording time resolution. This implementation relies on the thread safe containers that exist in VB.NET, which grantees the read and write operations without data violation. Algorithms 1, 2, and 3 represent 3 simultaneous threads to implement the proposed centralized data logging. It records different data sources using thread safe containers. This technique stores one multiplexed file for all received data.Algorithm 1:Proposed collecting data thread.
(1)Lock Access (Global_Buffer Array List)
(2)AddTime Stamp in Ticks
(3)AddRecording Source Label
(4)AddRecording Source Data
(5)Unlock Access (Global_Buffer Array List)Algorithm 2:Proposed data logging thread.
(1)Initialize Global_Buffer of the Type (Synchronized Array List)
(2)Initialize File_Buffer of the Type (Synchronized Array List)
(3)  Start File Manipulation Thread
(4)Loop
(5)
IfGlobal_Buffer Elements >0 then
(6)
Lock Access (Global_Buffer Array List)
(7)
Copy Global_Buffer → File Buffer
(8)
Clear All Global_Buffer
(9)
Unlock Access (Global_Buffer)
(10)Else
(11)GoTo (4)
(12)End if
(13)End loopAlgorithm 3:Proposed file manipulation thread.
(1)Loop
(2)IfFile_Buffer Elements >0 then
(3)
Lock Access (File Buffer)
(4)
Copy File_Buffer → Temp_Buffer
(5)
Clear All File_Buffer
(6)
Unlock Access (File_Buffer)
(7)Else
(8)GoTo (1)
(9)End if
(10)Loop (Temp_Buffer)
(11)
Seek to end of File
(12)
Write Temp_Buffer Data
(13)
Clear Temp_Buffer Data
(14)End Loop
(15)End loopAs a result, the playback functionalities will become more accurate, because accessing one unified time stamped file is much efficient, convenient, and faster than accessing multiple files. This software module achieves advanced data logging capabilities without the need for extra hardware equipment. Typically, this is considered to be one of the conquered challenges in this paper. The resultant high resolution data logging capabilities clearly appear in all recording activities (as will be shown in Section5).


## 4.5. Bidirectional GSM Communication (Ground and Airborne Modems)

The GSM data communications could be established through many setup profiles. The proposed scheme utilizes the PPP mode for controlling the UAV. The PPP consists of two communication parties, one of them is the master (who initiates the communication request), while the other one is slave (who answers the call). Typically, through the standard AT commands [30], the GCS can play the master role and can initiate the communication request. Figure 9 illustrates the flowchart of GSM interface module. It can be inferred that handling the dial-up connections requires more programming effort and sensitive data handling (rather than the leased line or wireless modem), due to the switching between the data and commands modes and detecting any disconnect events. As a benefit for the proposed NLoS architecture, the GCS call can be initiated either from a GSM modem or from a traditional land line modem using the Public Switched Telephone Network (PSTN) (as shown in Figure 5). This feature is an option for the stationary GCS, while for mobile GCS the proposed GSM modem is much suitable.Figure 9
Detailed flowchart of GSM interface module.


## 5. Testing Results and Evaluation

The testing of UASs usually passes through different procedures to avoid any hazard during flight missions. This section describes the conducted tests and methods that are used to evaluate the proposed scheme, which is divided into two major sections: ground tests and flight test. The ground tests include different procedures to measure various parameters, validate the data logging module, and measure critical modules processing delay (I/O interface modules) for better evaluation [31–33]. On the other hand, the flight test is conducted to demonstrate the GUI capabilities and to verify the performance of the developed avionics, check the consistency of different sensors measurements, and test the whole proposed control and communication scheme.


### 5.1. Ground Tests

#### 5.1.1. GSM Communication Latency and I/O Interface Modules Processing Delay

Communication delay is considered one of the most challenges for UAV uplink flight controls and downlink surveillance data. Thus, as shown in Figure10, a practical experiment is conducted to measure the round trip delay of GSM communication channel. The illustrated infrastructure shows that the airborne GSM modem is connected with RS-232 loopback, while the submitted data are the RC guidance commands as in real flight. The GSM in PPP is established between the GSM modems. The data logging module is adapted to compare the transmitted and received data and to measure the round trip delay in ticks. Table 3 lists a data logging sample for the loopback data transfer. It can be deduced that this experiment validates the proposed high resolution online data logging module, considers the communication worst-case scenario (9600 bps), and measures the average uplink/downlink latency to be in order of 286 ms. Therefore, according to these results, many requirements are achieved. Moreover, it is worthily noted that employing cellular data modems for UAS is experimentally approved for heights up to 1000 m [20].Table 3
GSM communication delay measurements.
Msg size (B)
Transmit time  (ticks)
Receive time  (ticks)
Round trip delay  (ticks)
Average  uplink/downlink delay (ticks)
Average  uplink/downlink delay (ms)
29
635551560641752484
635551560647604261
5851777
2925888.5
292.5888
29
635551560647634952
635551560653605129
5970177
2985088.5
298.5088
29
635551560653640420
635551560659494641
5854221
2927110.5
292.7110
29
635551560659532802
635551560665385290
5852488
2926244
292.6244
29
635551560665416008
635551560670875085
5459077
2729538.5
272.9538
29
635551560670913652
635551560676948354
6034702
3017351
301.7351
29
635551560676984607
635551560682878280
5893673
2946836.5
294.6836
29
635551560682916203
635551560688272173
5355970
2677985
267.7985
29
635551560688310562
635551560693719847
5409285
2704642.5
270.4642
29
635551560693754578
635551560699582413
5827835
2913917.5
291.3917
29
635551560699615279
635551560705263850
5648571
2824285.5
282.4285
29
635551560705294142
635551560710838137
5543995
2771997.5
277.1997
29
635551560641752484
635551560647604261
5851777
2925888.5
292.5888
29
635551560647634952
635551560653605129
5970177
2985088.5
298.5088
29
635551560653640420
635551560659494641
5854221
2927110.5
292.7110Figure 10
Experimental infrastructure for GSM delay measurements.As the proposed GCS relies deeply on software, thus, it is important to measure the processing delay of different data manipulation software modules. The most critical processing delays are the interface modules (I/O modules), which are responsible for the RC transmitter and GSM data manipulation. These two modules are responsible for capturing the serial data, parsing and extracting the required parameters, and, finally, submitting data to demanded destination. As shown in Figure11, the average processing delay to manipulate the mentioned RC data format is 2901 ticks (0.29 ms). On the other hand, the processing delay of the GSM software interface module is divided into uplink delay (for sending UAV commands) and downlink delay (for receiving UAV flight parameters). As shown in Figure 12, the average processing delays of GSM uplink and downlink are 2545 ticks (0.255 ms) and 8150 ticks (0.815 ms), respectively. It can be concluded that I/O processing delays are considered negligible with respect to the GSM round trip delay, which satisfies the mentioned requirements in Section 4.Figure 11
Processing delay of RC interface module.Figure 12
Software processing delay of GSM data manipulation module.


#### 5.1.2. Avionics Module and Bidirectional Data Transmission

The purpose of this test is to ensure that there is no malfunctioning of the proposed avionics functionality, while whole pieces of equipment are powered up and motors are running. In other words, it is required to verify the PWM controller outputs and to collect AHRS data via GSM communications while motors are running.During this test, the engine was powered on at 70% throttle, while the rotor blades were not installed to follow the safety procedures. The UAV quadcopter was allocated in an arbitrary orientation and position about 200 meters away from the GCS. The GCS established a call route to UAV SIM card as mentioned in Section4. After establishing the connection at 9600 bps, the data logging was activated to record all RC guidance device commands (which is transmitted via the GSM uplink) and avionics feedback (which is received via the GSM downlink). This test lasts continuously for 15 minutes. Figure 13 demonstrates a recorded sample for the GCS transmitted commands (PWM signals), which shows the capability of the COTS controller to generate the correct PWM signals similar to the traditional RC receiver signals. On the other hand, Figure 14 presents consistent receiving of AHRS data with tiny vibration effect due to motor running with no interference on AHRS sensors measurements, which fulfills the requirements in Section 4.Figure 13
Flight control PWM signals in the ground test.
(a)
(b)
(c)
(d)Figure 14
Ground test signals playback for the proposed UAV platform via GSM data communication channels.
(a)
(b)
(c)
(d)
(e)
(f)


### 5.2. Flight Tests

This section introduces the proposed GUI capabilities during flight test and also presents a complete set of surveillance data, which validates the overall performance and proves the consistency of different sensors measurements. Following the ground test, multiple remotely piloted flight test missions were conducted via the bidirectional GSM communication to verify the performance of the proposed software and hardware components.In Figure15(a), the GCS is located at the home symbol, while the proposed UAV is controlled to follow the planned trajectory, via bidirectional NLOS GSM channel over a distance more than 5 Km. The innovative GUI allocates all static and dynamic entities on the geographic reference map, while the detailed UAV feedback is presented in tabular form in the right panel. Additionally, a set of convenient gauges are presented to simplify the guidance process and to increase the functional fidelity of the proposed GCS [34]. Moreover, Figure 15(b) demonstrates a zoom in view for the weather forecast layer overlaid over the geographic map; it shows the wind speed and its direction along the mission trajectory. The illustrated weather layer provides more real atmospheric conditions for the guidance operator for better environmental situational awareness. All demonstrated software capabilities can be exploited with other UASs with minor modifications in the interface modules, which should be adapted to manipulate the new data protocols.Figure 15
Proposed Ground Control Station GUI snapshot. (a) Operational panel and (b) mission trajectory with synthetic weather data layer.
(a)
(b)As shown in Figure16, the raw inertial data of COTS AHRS module are captured and transmitted efficiently through the GSM modems to the GCS. Blue line is used to represent the raw data from accelerometer signals directly and red line is used to represent the average value. The raw data show a significant vibration; however, when integrating the data, it delivers a smooth and stable position, velocity, and attitude values. Figure 17 illustrates the quadcopter attitude data (Euler angles) over 200 seconds. It can be observed from Figure 17(a) that the GPS heading and obtained AHRS sensors yaw measurements are correlated, which ensure the proposed platform performance, and prove the consistency of different sensors measurements. In Figures 17(b) and 17(c), it can be observed that the UAV roll and pitch angles are successfully captured from the ARHS sensors for further visualization by the attitude indicator gauge.Figure 16
Flight test accelerometer outputs.
(a)
(b)
(c)Figure 17
Euler angles during flight test.
(a)
(b)
(c)Furthermore, the environmental data (pressure and temperature) are presented in Figure18. The temperature accuracy (0.1°C) provides accurate measurements over different altitudes (as shown in Figure 18(a)), while Figure 18(b) presents (10 Pa) pressure resolution from barometer sensor during the flight. It is clear that the collected data are consistent, as the decrease in pressure is equivalent to incremental altitude, which leads to temperature decrease.Figure 18
Environmental online data measurements via GSM channels.
(a)
(b)According to Section3 (1), UAV altitude can be calculated from barometer readings. This feature could be used to correct the GPS altitude, or as an alternative altitude data source in case of GPS malfunctioning. Figure 19 shows the GPS altitude and the biased barometric altitude during the flight test. Finally, Figure 20(a) presents the GPS flight trajectory, while Figure 20(b) demonstrates the locked GPS satellites. GPS module is able to receive up to 12 satellite readings along the mission without the need for large GPS external antenna.Figure 19
Flight test altitude profile.Figure 20
Flight test GPS measurements: (a) GPS trajectory, (b) GPS locked satellites.
(a)
(b)From all previous flight test results, it can be concluded that the proposed quadcopter, avionics, GCS, and the whole control and communication scheme parameters (illustrated in Section4) are validated.


## 5.1. Ground Tests

### 5.1.1. GSM Communication Latency and I/O Interface Modules Processing Delay

Communication delay is considered one of the most challenges for UAV uplink flight controls and downlink surveillance data. Thus, as shown in Figure10, a practical experiment is conducted to measure the round trip delay of GSM communication channel. The illustrated infrastructure shows that the airborne GSM modem is connected with RS-232 loopback, while the submitted data are the RC guidance commands as in real flight. The GSM in PPP is established between the GSM modems. The data logging module is adapted to compare the transmitted and received data and to measure the round trip delay in ticks. Table 3 lists a data logging sample for the loopback data transfer. It can be deduced that this experiment validates the proposed high resolution online data logging module, considers the communication worst-case scenario (9600 bps), and measures the average uplink/downlink latency to be in order of 286 ms. Therefore, according to these results, many requirements are achieved. Moreover, it is worthily noted that employing cellular data modems for UAS is experimentally approved for heights up to 1000 m [20].Table 3
GSM communication delay measurements.
Msg size (B)
Transmit time  (ticks)
Receive time  (ticks)
Round trip delay  (ticks)
Average  uplink/downlink delay (ticks)
Average  uplink/downlink delay (ms)
29
635551560641752484
635551560647604261
5851777
2925888.5
292.5888
29
635551560647634952
635551560653605129
5970177
2985088.5
298.5088
29
635551560653640420
635551560659494641
5854221
2927110.5
292.7110
29
635551560659532802
635551560665385290
5852488
2926244
292.6244
29
635551560665416008
635551560670875085
5459077
2729538.5
272.9538
29
635551560670913652
635551560676948354
6034702
3017351
301.7351
29
635551560676984607
635551560682878280
5893673
2946836.5
294.6836
29
635551560682916203
635551560688272173
5355970
2677985
267.7985
29
635551560688310562
635551560693719847
5409285
2704642.5
270.4642
29
635551560693754578
635551560699582413
5827835
2913917.5
291.3917
29
635551560699615279
635551560705263850
5648571
2824285.5
282.4285
29
635551560705294142
635551560710838137
5543995
2771997.5
277.1997
29
635551560641752484
635551560647604261
5851777
2925888.5
292.5888
29
635551560647634952
635551560653605129
5970177
2985088.5
298.5088
29
635551560653640420
635551560659494641
5854221
2927110.5
292.7110Figure 10
Experimental infrastructure for GSM delay measurements.As the proposed GCS relies deeply on software, thus, it is important to measure the processing delay of different data manipulation software modules. The most critical processing delays are the interface modules (I/O modules), which are responsible for the RC transmitter and GSM data manipulation. These two modules are responsible for capturing the serial data, parsing and extracting the required parameters, and, finally, submitting data to demanded destination. As shown in Figure11, the average processing delay to manipulate the mentioned RC data format is 2901 ticks (0.29 ms). On the other hand, the processing delay of the GSM software interface module is divided into uplink delay (for sending UAV commands) and downlink delay (for receiving UAV flight parameters). As shown in Figure 12, the average processing delays of GSM uplink and downlink are 2545 ticks (0.255 ms) and 8150 ticks (0.815 ms), respectively. It can be concluded that I/O processing delays are considered negligible with respect to the GSM round trip delay, which satisfies the mentioned requirements in Section 4.Figure 11
Processing delay of RC interface module.Figure 12
Software processing delay of GSM data manipulation module.


### 5.1.2. Avionics Module and Bidirectional Data Transmission

The purpose of this test is to ensure that there is no malfunctioning of the proposed avionics functionality, while whole pieces of equipment are powered up and motors are running. In other words, it is required to verify the PWM controller outputs and to collect AHRS data via GSM communications while motors are running.During this test, the engine was powered on at 70% throttle, while the rotor blades were not installed to follow the safety procedures. The UAV quadcopter was allocated in an arbitrary orientation and position about 200 meters away from the GCS. The GCS established a call route to UAV SIM card as mentioned in Section4. After establishing the connection at 9600 bps, the data logging was activated to record all RC guidance device commands (which is transmitted via the GSM uplink) and avionics feedback (which is received via the GSM downlink). This test lasts continuously for 15 minutes. Figure 13 demonstrates a recorded sample for the GCS transmitted commands (PWM signals), which shows the capability of the COTS controller to generate the correct PWM signals similar to the traditional RC receiver signals. On the other hand, Figure 14 presents consistent receiving of AHRS data with tiny vibration effect due to motor running with no interference on AHRS sensors measurements, which fulfills the requirements in Section 4.Figure 13
Flight control PWM signals in the ground test.
(a)
(b)
(c)
(d)Figure 14
Ground test signals playback for the proposed UAV platform via GSM data communication channels.
(a)
(b)
(c)
(d)
(e)
(f)


## 5.1.1. GSM Communication Latency and I/O Interface Modules Processing Delay

Communication delay is considered one of the most challenges for UAV uplink flight controls and downlink surveillance data. Thus, as shown in Figure10, a practical experiment is conducted to measure the round trip delay of GSM communication channel. The illustrated infrastructure shows that the airborne GSM modem is connected with RS-232 loopback, while the submitted data are the RC guidance commands as in real flight. The GSM in PPP is established between the GSM modems. The data logging module is adapted to compare the transmitted and received data and to measure the round trip delay in ticks. Table 3 lists a data logging sample for the loopback data transfer. It can be deduced that this experiment validates the proposed high resolution online data logging module, considers the communication worst-case scenario (9600 bps), and measures the average uplink/downlink latency to be in order of 286 ms. Therefore, according to these results, many requirements are achieved. Moreover, it is worthily noted that employing cellular data modems for UAS is experimentally approved for heights up to 1000 m [20].Table 3
GSM communication delay measurements.
Msg size (B)
Transmit time  (ticks)
Receive time  (ticks)
Round trip delay  (ticks)
Average  uplink/downlink delay (ticks)
Average  uplink/downlink delay (ms)
29
635551560641752484
635551560647604261
5851777
2925888.5
292.5888
29
635551560647634952
635551560653605129
5970177
2985088.5
298.5088
29
635551560653640420
635551560659494641
5854221
2927110.5
292.7110
29
635551560659532802
635551560665385290
5852488
2926244
292.6244
29
635551560665416008
635551560670875085
5459077
2729538.5
272.9538
29
635551560670913652
635551560676948354
6034702
3017351
301.7351
29
635551560676984607
635551560682878280
5893673
2946836.5
294.6836
29
635551560682916203
635551560688272173
5355970
2677985
267.7985
29
635551560688310562
635551560693719847
5409285
2704642.5
270.4642
29
635551560693754578
635551560699582413
5827835
2913917.5
291.3917
29
635551560699615279
635551560705263850
5648571
2824285.5
282.4285
29
635551560705294142
635551560710838137
5543995
2771997.5
277.1997
29
635551560641752484
635551560647604261
5851777
2925888.5
292.5888
29
635551560647634952
635551560653605129
5970177
2985088.5
298.5088
29
635551560653640420
635551560659494641
5854221
2927110.5
292.7110Figure 10
Experimental infrastructure for GSM delay measurements.As the proposed GCS relies deeply on software, thus, it is important to measure the processing delay of different data manipulation software modules. The most critical processing delays are the interface modules (I/O modules), which are responsible for the RC transmitter and GSM data manipulation. These two modules are responsible for capturing the serial data, parsing and extracting the required parameters, and, finally, submitting data to demanded destination. As shown in Figure11, the average processing delay to manipulate the mentioned RC data format is 2901 ticks (0.29 ms). On the other hand, the processing delay of the GSM software interface module is divided into uplink delay (for sending UAV commands) and downlink delay (for receiving UAV flight parameters). As shown in Figure 12, the average processing delays of GSM uplink and downlink are 2545 ticks (0.255 ms) and 8150 ticks (0.815 ms), respectively. It can be concluded that I/O processing delays are considered negligible with respect to the GSM round trip delay, which satisfies the mentioned requirements in Section 4.Figure 11
Processing delay of RC interface module.Figure 12
Software processing delay of GSM data manipulation module.


## 5.1.2. Avionics Module and Bidirectional Data Transmission

The purpose of this test is to ensure that there is no malfunctioning of the proposed avionics functionality, while whole pieces of equipment are powered up and motors are running. In other words, it is required to verify the PWM controller outputs and to collect AHRS data via GSM communications while motors are running.During this test, the engine was powered on at 70% throttle, while the rotor blades were not installed to follow the safety procedures. The UAV quadcopter was allocated in an arbitrary orientation and position about 200 meters away from the GCS. The GCS established a call route to UAV SIM card as mentioned in Section4. After establishing the connection at 9600 bps, the data logging was activated to record all RC guidance device commands (which is transmitted via the GSM uplink) and avionics feedback (which is received via the GSM downlink). This test lasts continuously for 15 minutes. Figure 13 demonstrates a recorded sample for the GCS transmitted commands (PWM signals), which shows the capability of the COTS controller to generate the correct PWM signals similar to the traditional RC receiver signals. On the other hand, Figure 14 presents consistent receiving of AHRS data with tiny vibration effect due to motor running with no interference on AHRS sensors measurements, which fulfills the requirements in Section 4.Figure 13
Flight control PWM signals in the ground test.
(a)
(b)
(c)
(d)Figure 14
Ground test signals playback for the proposed UAV platform via GSM data communication channels.
(a)
(b)
(c)
(d)
(e)
(f)


## 5.2. Flight Tests

This section introduces the proposed GUI capabilities during flight test and also presents a complete set of surveillance data, which validates the overall performance and proves the consistency of different sensors measurements. Following the ground test, multiple remotely piloted flight test missions were conducted via the bidirectional GSM communication to verify the performance of the proposed software and hardware components.In Figure15(a), the GCS is located at the home symbol, while the proposed UAV is controlled to follow the planned trajectory, via bidirectional NLOS GSM channel over a distance more than 5 Km. The innovative GUI allocates all static and dynamic entities on the geographic reference map, while the detailed UAV feedback is presented in tabular form in the right panel. Additionally, a set of convenient gauges are presented to simplify the guidance process and to increase the functional fidelity of the proposed GCS [34]. Moreover, Figure 15(b) demonstrates a zoom in view for the weather forecast layer overlaid over the geographic map; it shows the wind speed and its direction along the mission trajectory. The illustrated weather layer provides more real atmospheric conditions for the guidance operator for better environmental situational awareness. All demonstrated software capabilities can be exploited with other UASs with minor modifications in the interface modules, which should be adapted to manipulate the new data protocols.Figure 15
Proposed Ground Control Station GUI snapshot. (a) Operational panel and (b) mission trajectory with synthetic weather data layer.
(a)
(b)As shown in Figure16, the raw inertial data of COTS AHRS module are captured and transmitted efficiently through the GSM modems to the GCS. Blue line is used to represent the raw data from accelerometer signals directly and red line is used to represent the average value. The raw data show a significant vibration; however, when integrating the data, it delivers a smooth and stable position, velocity, and attitude values. Figure 17 illustrates the quadcopter attitude data (Euler angles) over 200 seconds. It can be observed from Figure 17(a) that the GPS heading and obtained AHRS sensors yaw measurements are correlated, which ensure the proposed platform performance, and prove the consistency of different sensors measurements. In Figures 17(b) and 17(c), it can be observed that the UAV roll and pitch angles are successfully captured from the ARHS sensors for further visualization by the attitude indicator gauge.Figure 16
Flight test accelerometer outputs.
(a)
(b)
(c)Figure 17
Euler angles during flight test.
(a)
(b)
(c)Furthermore, the environmental data (pressure and temperature) are presented in Figure18. The temperature accuracy (0.1°C) provides accurate measurements over different altitudes (as shown in Figure 18(a)), while Figure 18(b) presents (10 Pa) pressure resolution from barometer sensor during the flight. It is clear that the collected data are consistent, as the decrease in pressure is equivalent to incremental altitude, which leads to temperature decrease.Figure 18
Environmental online data measurements via GSM channels.
(a)
(b)According to Section3 (1), UAV altitude can be calculated from barometer readings. This feature could be used to correct the GPS altitude, or as an alternative altitude data source in case of GPS malfunctioning. Figure 19 shows the GPS altitude and the biased barometric altitude during the flight test. Finally, Figure 20(a) presents the GPS flight trajectory, while Figure 20(b) demonstrates the locked GPS satellites. GPS module is able to receive up to 12 satellite readings along the mission without the need for large GPS external antenna.Figure 19
Flight test altitude profile.Figure 20
Flight test GPS measurements: (a) GPS trajectory, (b) GPS locked satellites.
(a)
(b)From all previous flight test results, it can be concluded that the proposed quadcopter, avionics, GCS, and the whole control and communication scheme parameters (illustrated in Section4) are validated.


## 6. Qualitative Aspects of the Proposed GSM Based UAV Platform

As presented in Table4, this subsection lists a brief comparison between the functions and features of the proposed UAV platform versus other different existing platforms. It can be observed from this table that the proposed platform achieves the following: (
1
) new bidirectional NLoS long communication range using challenging low bandwidth for a considerable height; (2) a large number of controllable PWM signals for extended payload control; (3) new environmental awareness during operational mission; (4) advanced GUI features; (5) online data logging; and (6) higher functional fidelity.Table 4
Proposed GSM based UAV platform versus other different existing platforms  (see Figure21).
Criteria
Proposed platform
Helicopter platform [12]
Balloon platform [19]
UAV type
Quadcopter
Raptor 90 Hoppy Helicopter
Balloon
GCS
GCS: 1 laptop, airborne system: COTS components
GCS: 1 laptop, avionics: digital signal controller TMS320F28335
GCS: 1 workstation, airborne system: ARM CPU + C8051
Communication device
2 GSM modems or 1 GSM + land line modem (optional)
RC guidance device + 2 Digi XTend-PKG RF modems
2 GSM modems + PSTN connection
Communication architecture
Uplink: GSM in PPPDownlink: GSM in PPP
Traditional 2.4 GHz receiver + wireless modems
Uplink: GSM in PPPDownlink: GPRS using TCP/IP
AT commands
Implemented
Not used
Implemented
Communication range
The cellular service provider coverage
Up to 64 Km in open field environment
The cellular service provider coverage
Link between GCS and UAV
NLoS
LoS
NLoS
Communication baud rates
Uplink: 9.6 KbpsDownlink: 9.6 Kbps
Up to 115.2 Kbps
Uplink: 9.6 KbpsDownlink: 9.6 Kbps
Average delay
Uplink: <0.3 secDownlink: <0.3 sec
Not explicitly mentioned
Uplink: <0.3 secDownlink: <0.85 sec
Ceiling altitude according to [20]
600–1000 m for consistent signal
Not explicitly mentioned
600–1000 m for consistent signal
Traditional short range receivers
Not existing
Exist
Not explicitly mentioned
Ease of development
AHRS plus GPS, PWM controller, and GSM modems are all COTS components
Need custom development using DSC (TMS320F28335)
Need custom development using ARM CPU + C8051
PWM channels
32
6
4
Real weather data for mission planning
Available
Not available
Not available
Real weather data during flight mission
Available
Not available
Not available
Real weather forecast data
Available up to 6 days
Not available
Not available
GCS capabilities
Geographical mapInnovative set of gauges  Mission planning  Mission viewer  Weather forecast features  Hardware interfacing  Precise recording  (10−7 s)Playback
Compass gaugesText data for UAV position  Curve style  UAV motion trajectory
GIS display
Data logging location
GCS
Onboard system using SD card
Not explicitly mentioned
Development languages
VB.NET
Not explicitly mentioned
Not explicitly mentioned
Functional fidelity
Above medium
Medium
MediumFigure 21
(a) Proposed platform. (b) Helicopter platform. (c) Balloon platform.
(a)
(b)
(c)


## 7. Conclusions

This paper illustrates the detailed development of a new bidirectional long range UAV flight control using mobile communications and COTS component. A new software package is developed for long range quadcopter UAV missions. The airborne system used employs a set of COTS components. Through the proposed control and communication scheme, traditional short range remote control receivers are no longer needed. On the other hand, the ground station software is proposed as a two-layer framework. The background layer is utilized for interfacing and data exchange, while the foreground layer is employed for the visualization and the operator activity. A new global real weather interface module is developed to support the human operator decisions during both mission planning and real operation. The software system has been thoroughly tested through different ground tests and real flight tests. The results show that the GCS established a stable data link with the UAV with latency average latency less than 300 ms. Moreover, developed software modules satisfied the real time processing requirements, GUI achieves a high functional fidelity, and high resolution data logging module facilitates an accurate and powerful evaluation. The flight tests validate the whole platform performance using GSM communications. Finally, as the development of universal software framework has a great potential in the near future, the illustrated software solution can also be used in other unmanned vehicles with minimal modifications.



---

*Source: 285746-2015-10-25.xml*