MAT-Fly: An Educational Platform for Simulating Unmanned Aerial Vehicles Aimed to Detect and Track Moving Objects

TL;DR

MAT-Fly is an open-source, modular simulation platform built in Matlab for educational purposes, enabling students to simulate UAV behavior in tracking moving objects using virtual reality and computer vision tools.

Contribution

It introduces a user-friendly, customizable simulation environment for UAV visual detection and tracking, integrating Matlab, VR, and CVS toolboxes for educational use.

Findings

Validated through simple testbeds demonstrating tracking capabilities

Platform is modular and easily customizable

Open-source release facilitates educational adoption

Abstract

The main motivation of this work is to propose a simulation approach for a specific task within the Unmanned Aerial Vehicle (UAV) field, i.e., the visual detection and tracking of arbitrary moving objects. In particular, it is described MAT-Fly, a numerical simulation platform for multi-rotor aircraft characterized by the ease of use and control development. The platform is based on Matlab and the MathWorks Virtual Reality (VR) and Computer Vision System (CVS) toolboxes that work together to simulate the behavior of a quad-rotor while tracking a car that moves along a nontrivial path. The VR toolbox has been chosen due to the familiarity that students have with Matlab and because it does not require a notable effort by the user for the learning and development phase thanks to its simple structure. The overall architecture is quite modular so that each block can be easily replaced with others simplifying the code reuse and the platform customization. Some simple testbeds are presented to show the validity of the approach and how the platform works. The simulator is released as open-source, making it possible to go through any part of the system, and available for educational purposes.

Tables

Table 1. TABLE I: Drone parameter values for the considered case study.

	Sym.	Value	Unit
Mass	$m$	$0.65$	$\mathrm{kg}$
Distance to center of gravity	$l$	$0.23$	$m$
Thrust factor	$b_f$	$7.5\cdot {10}^{-7}$	$\mathrm{kg}$
Drag factor	$b_m$	$3.13\cdot {10}^{-5}$	$\mathrm{kg}m$
Inertia component along $e_x$-axis	$I_x$	$7.5\cdot {10}^{-3}$	$\mathrm{kg}{m}^2$
Inertia component along $e_y$-axis	$I_y$	$7.5\cdot {10}^{-3}$	$\mathrm{kg}{m}^2$
Inertia component along $e_z$-axis	$I_z$	$1.3\cdot {10}^{-3}$	$\mathrm{kg}{m}^2$

Equations

$$\left\{\begin{array}[]{ll}y=r\cos{\beta}\\ x=r\sin{\beta}\sin{\alpha}\\ z=r\sin{\beta}\cos{\alpha}\end{array}\right.,$$

$$m\ddot{\mathbf{\xi }}=-mg{\mathbf{E}}_z+u_T\mathbf{R}(\phi ,\vartheta ,\psi ){\mathbf{E}}_z,$$

$$\mathbf{I}{\dot{\omega }}_B=-{\mathbf{\omega }}_B\times \mathbf{I}{\omega }_B+\mathbf{\tau },$$

$$I_x\ddot{\phi }=$$

$$I_y\ddot{\vartheta }=$$

$$I_z\ddot{\psi }=$$

$$m\ddot{x}=$$

$$m\ddot{y}=$$

$$m\ddot{z}=$$

$$u_T=b_f\left({\Omega }_1^2+{\Omega }_2^2+{\Omega }_3^2+{\Omega }_4^2\right),$$

$$\left(\begin{array}{c}{u}_{\phi }\\ u_{\vartheta }\\ u_{\psi }\end{array}\right)=\frac{b_f}{b_m}\left(\begin{array}{c}{b}_{m}l\left({\Omega }_4^2-{\Omega }_2^2\right)\\ b_{m}l\left({\Omega }_3^2-{\Omega }_1^2\right)\\ -{\Omega }_1^2+{\Omega }_2^2-{\Omega }_3^2+{\Omega }_4^2\end{array}\right),$$

$${\vartheta }_{{\mathrm{ref}}_{\mathrm{IB}}}=$$

$$\displaystyle-c_{1}\lambda_{1}\int_{0}^{t}{e_{x}(\tau)\mathrm{d}\tau}\Biggr{]},$$

$${\phi }_{{\mathrm{ref}}_{\mathrm{IB}}}=$$

$$\displaystyle-c_{3}\lambda_{2}\int_{0}^{t}{e_{z}(\tau)\mathrm{d}\tau}\Biggr{]},$$

$$e_{x_{\mathrm{IB}}}(t)$$

$$e_{z_{\mathrm{IB}}}(t)$$

$$e_x$$

$$e_z$$

Full text

Some simple testbeds are presented to show the validity of the approach and how the platform works. The simulator is released as open-source, making it possible to go through any part of the system, and available for educational purposes.

\titlepgskip

=-15pt

I Introduction

Unmanned Aerial Vehicles (UAVs), although originally designed and developed for defense and military purposes (e.g., aerial attacks or military air covering), in the recent years gained an increasing interest and attention related to civilian use. Nowadays, UAVs are employed for several tasks and services like surveying and mapping [1], for spatial information acquisition and buildings inspection [2], data collection from inaccessible areas [3], agricultural crops and monitoring [4], manipulation and transportation or navigation purposes [5].

Many existing algorithms for the autonomous control [6] and navigation [7] are provided in the literature, but it is particularly difficult to make the UAVs able to work autonomously in constrained and cluttered environments or also indoors. Thus, it follows the need for tools that allow to understand what it happens when some new applications are going to be developed in unknown or critical situations. Simulation is one of such helpful tools, widely used in robotics [8, 9, 10, 11, 12], whose main benefits are costs and time savings, enabling not only to create various scenarios, but also to carry out and to study complex missions that might be time consuming and risky in real world applications. Moreover, bugs and mistakes cost virtually nothing: it is possible to crash a vehicle several times and thereby getting a better understanding of implemented methods under various conditions. Thus, simulation environments are very important for fast prototyping and educational purposes, although they may have some drawbacks and limitations, such as the lack of noisy real data or the fact that simulated models are usually incomplete or inaccurate. Despite the limitations, the advantages that the simulation provides are more, as like as to manage the complexity and heterogeneity of the hardware, to promote the integration of new technologies, to simplify the software design, to hide the complexity of low-level communication [13].

Different solutions, typically based on external robotic simulators such as Gazebo [14], V-REP [15], AirSim [16], MORSE [17], are available. They employ recent advances in computation and computer graphics (e.g., AirSim is a photorealistic environment [7]) in order to simulate physical phenomena (e.g., gravity, magnetism, atmospheric conditions) and perception (e.g., providing sensor models) in such a way that the environment realistically reflects the actual world. In some cases, those solutions do not have enough features that could allow to create large scale complex environments close to reality. On the other hand, when the tools provide such possibilities, they are difficult to use or they require high computational capabilities [16]. Definitely, it comes out that simulating the real world is a nontrivial task, not only due to multiple phenomena that need to be modeled, but also because their complex interactions ask the user a notable effort for the learning and development phase. For all such reasons, having a complete software platform that makes possible to test different algorithms and control strategies for UAVs moving in a simulated 3D environment is increasingly important both for the whole design process and for educational purposes.

In this paper, it is presented a software platform in which detection, tracking and control algorithms can be evaluated and tested all together in a 3D graphical tool. Due to the simple implementation and the limited possibilities of interfacing it with dedicated middlewares (e.g., ROS [18], YARP [19], GenoM [20]), the proposed platform should be meant with an educational purpose. However, that does not imply a loss of generality nor makes the platform less important. Indeed, as highlighted in [21], the use of interactive learning approaches allows students to improve their technical knowledge and communication skills, giving them the experience of what they will encounter in a real world environment. Therefore, the platform can be appreciated for its potentialities thanks to the advantages coming from the use of a  Software-in-the-loop (SIL) approach [6, 22, 23]. In other words, the functionalities provided by the simulator can be easily expanded by students, researchers, and developers modifying or integrating new vehicles dynamics (e.g., hexarotor [24], fully actuated platform [25]), control algorithms (e.g., geometric control laws [26], flatness-based control methods [27]) or detection and tracking techniques (e.g., YOLO [28, 29], Fast R-CNN [30, 29]) for their purposes.

Compared to the commercial and open-source platforms available in the literature [31, 32, 33, 34, 35], the proposed framework runs on a built-in environment (i.e., Matlab and its toolboxes) and has no constraints in terms of hardware (e.g., memory, unit processor, etc.). Moreover, the simulator is self-contained (i.e., everything is in one place) and can also be used by people without programming skills (i.e., algorithms are typically written in the most common programming languages). Matlab and the  Computer Vision System (CVS)111https://www.mathworks.com/products/computer-vision.html and  Virtual Reality (VR)222https://www.mathworks.com/products/3d-animation.html toolboxes are the only tools the user needs to work with.

The specific domain of interest regards the behavior of multi-rotor aircraft acting in accordance with the  Image-Based Visual Servoing (IBVS) approach [36, 37]. The eye-in-hand camera configuration [38] along with the pinhole camera model is considered for the aerial vehicle. Compared to other approaches [39], the camera is rigidly attached to the UAV frame and moves according to the aircraft motion. \Figure!t[width=0.48]pdf/screenTests.pdfThree consecutive frames produces as output by the CAMShift algorithm while tracking the target. The image and the bounding box centroids as well as the distance vector among centroids are depicted (see Sec. IV).

The application that is considered is an extension of the authors’ previous work [40], that has been revised for making the aircraft able to detect and track a specific object (a car) moving along a nontrivial path. This simple scenario is used as a testbed to show: (i) how the platform works, (ii) the elements that make up the software architecture, and (iii) the adaptability of the platform to the different needs of the user. Compared to the previous work, a tracking algorithm has been added into the loop: the classifier is used to detect the target only at the first step or in case of partial occlusions. Apart from such scenarios, a  Continuously Adaptive Mean-Shift (CAMShift) tracking algorithm [41] is employed to follow the car along the path, thus reducing the computational burden and the possibility to lose the target during the tracking. Moreover, in this paper it is proposed a novel procedure based on ad hoc Matlab scripts that automatically select the bounding box area of the target (see, Fig. I) avoiding to use specific Matlab tools, such as Training Image Labeler. These scripts also allow comparing various classifier configurations to help select the most suitable for the case study among different features types (e.g., Haar, HOG, LBP) [42] and number of training stages. Finally, the software platform is published as open-source333https://github.com/gsilano/MAT-Fly with the aim to share results with other researchers, students, and developers that might use the platform for testing their algorithms and understanding how different approaches can improve the performance and affect the system stability.

The paper is organized as follows. Section II explains the simulation scenario and its functionalities. The classifier training phase and the vision-based target detection and tracking algorithms are presented in Sec. III and IV, respectively. Section V briefly describes the quad-rotor model while numerical results and the control algorithm are reported in Sec. VI. Finally, Section VII concludes the paper.

II System Description

This section aims to describe MAT-Fly and how it works together with the Matlab VR and CVS toolboxes. An illustrative application, i.e., the object tracking example, where a drone tracks a car moving along a nontrivial path is considered. An overview of the main elements that make up the system is depicted in Fig. II.

The software platform is mainly divided into four parts: the classifier training phase (see, Sec. III), the vision-based target detection and tracking (see, Sec. IV), the flight control system (see, Sec. VI), and the Matlab VR toolbox. To facilitate the development of various control and computer vision strategies and the reuse of existing software components, the system was set up using a modular approach splitting each functionality into interchangeable modules. In other words, each part of the system (e.g., the vision-based target detection and tracking, the flight control system) was developed by isolating every feature (e.g., the detection algorithm, the reference generator) in such a way they can be easily replaced with others by facilitating the test and evaluation process. \Figure!t[width=0.48]pdf/platformArchitecture.pdfThe proposed software platform architecture. Arrows represent the data exchanged among blocks and how they interact with each other. Colors point out the four parts making up the system: the classifier training phase (in blue), the vision-based target detection and tracking (in green), the flight control system (in yellow), and the Matlab VR toolbox (in red).

The Matlab VR toolbox allows to simulate a scenario as much similar as to the real world accounting for the interaction between complex dynamic systems with the surrounding scenario. Moreover, thanks to animation recording functionalities, frames and videos from the scene can be acquired and used to implement an IBVS problem. Also, the tool makes it easy to add external viewpoints to monitor any moving object in the 3D environment from different positions and orientations. \Figure!t[width=0.4]figure/octavia_scene_lchg_2cars_anim_1.png Initial frame extracted from the object tracking example. The steering angle visualizer allows monitoring the car movements along the path.

One of the available examples444The list of the ready-to-use scenarios is accessible at https://goo.gl/rtEx3S. (specifically the vr_octavia_2cars example) that describes a quite detailed dynamical model of a car moving along a nontrivial path was used as a starting point (see, Fig. II). The example represents a standard double-lane-change maneuver [43] conducted in two-vehicles configuration, where one engages the  Electronic Stability Program (ESP) control while the other switches off such control unit when changing the lane. From this perspective, a simpler scenario was considered by removing one of the two vehicle configurations, i.e., the car without the ESP controller.

Then, an external viewpoint was added to the scheme for simulating the behavior of a quad-rotor that flies by observing the car moving along the path. In Matlab VR a viewpoint has six Degrees of Freedoms: the spatial coordinates $x$, $y$, and $z$, and the angles yaw ($\psi$), pitch ($\vartheta$), and roll ($\varphi$). The whole process is the following: images are updated according to the position and the orientation of the quad-rotor w.r.t. the car; such images are acquired and elaborated for getting the necessary information to detect and track the target, and to run the control strategy designed for the tracking problem. The outputs of the control algorithm consists of the commands $u_{\varphi}$, $u_{\vartheta}$, $u_{\psi}$, and $u_{T}$ that should be given to the drone in order to update its position ($x_{d}$, $y_{d}$, and $z_{d}$) and orientation ($\varphi_{d}$, $\vartheta_{d}$, and $\psi_{d}$ ), see Fig. II.

It is worth noticing that ground truth data are used by the tracking controller (see Sec. VI). Therefore, any analysis can be conducted on the correctness of the data and how this affects the navigation. However, this does not constitute a limitation for the proposed framework thanks to the modular interface exhibited by the platform [44].

In Figure II the Simulink scheme employed for simulating the drone and the car dynamics is reported. The esp_on and the coordinates_transformation blocks compute the steering angle, the linear velocity and the position of the car, and all forces needed to follow a given path. Instead, the observer_position and rotation_matrix blocks represent the aircraft position and orientation (it is expressed by using the direction cosine matrix [45] and the Rodrigues’s formula [46]), respectively. The processed data are sent to the VR Visualization block that takes care of the drone and car movements in the simulated scenario. \Figure!t[width=0.48height=1keepaspectratio]pdf/paperContents.pdfThe control scheme. Subscript d indicates the drone variables, while r represents the references to the controller. Each block is mapped with the section that describes its content to help matching the blocks with the corresponding description within the paper.

Note that Matlab VR adopts a reference system ($O_{\mathrm{FVR}}$) [47] slightly different from the classic fixed reference frame $O_{\mathrm{FI}}$ (see Sec. V), thus simple references transformations have been taken into account in all elaborations.

\Figure

!t[width=0.8]pdf/ambienteVirtuale2.pdfSimulink scheme employed for simulating the drone and car dynamics in the 3D simulation environment.

Finally, the Simulink scheme saves the current car position ($x_{\mathrm{car}}$, $y_{\mathrm{car}}$, and $z_{\mathrm{car}}$), used for comparing the drone and the car trajectories (see, Sec. VI-A), and frames of the virtual scenario observed from the drone point of view. Those frames are used, as described in next sections, for pattern recognition.

III Classifier Training Phase

The classifier training phase is the most important part of the system: the object detection and tracking depend on it. Matlab scripts have been developed to automate the entire procedure, from the frames acquisition to the classifier synthesis and performance evaluation. To this aim, the training process has been divided into four parts, as depicted in Fig. II: the frames acquisition, the bounding box selection, the classifier synthesis and the performance evaluation.

III-A Frames acquisition

When going to train a classifier, a high number of images is needed. The images are divided into two groups: positive (that contain the target) and negative images. Following what described in [46], $2626$ positive and $10504$ negative images were used achieving a 1 : 4 ratio in accordance to the Pareto’s principle (aka the $80/20$ rule).

For the frames acquisition, a simulation was performed with the quad-rotor moving along a spiral trajectory around the car parked in its initial state (see, Fig. III-A). The aircraft attitude and position have been computed for each frame so as described by the sphere surface equations, \Figure!t[width=0.48]pdf/spiralTrajectory.pdfDrone trajectory around the car parked in its initial state during the frames acquisition phase.

[TABLE]

where $r$, the sphere radius, is the distance between the car and the drone (assumed to be fixed and equal to $15$ meters), and together with $\alpha\in[0,2\pi]$ and $\beta\in[0,\nicefrac{{\pi}}{{2}}]$ angles, identifies the drone position in the 3D space, as depicted in Fig. III-A. A video showing the quad-rotor camera point of view while observing the car parked in its initial state while following the spiral trajectory is available in [48].

III-B Bounding box selection

To train the classifier, the  Region of Interest (ROI) of the target needs to be computed. Due to the high number of images, manual labeling tools, such as the MathWorks Training Image Labeler, cannot be used. Thus a Matlab script was developed to automatically select the bounding box area surrounding the target. The image segmentation process was used to simplify and to change the image representation: from RGB to grayscale (Figs. 7(a) and 7(b), respectively). The result is a set of contours that make the image meaningful and easier to analyze: each group of pixels in a region is similar w.r.t. some characteristics or computed properties, intensity, or texture, while adjacent regions are significantly different w.r.t. the same properties. \Figure!t[width=0.48]pdf/framesElaboration.pdfFrames obtained by the images segmentation process. From the RGB file format (a) to the cropped image (e) the steps are shown, sequentially.

To automatically select each group of pixels, the  Balanced Histogram Thresholding (BTH) method [49] was used. Such a method allows to separate the background from the foreground image by dividing the data into two main classes (see, Fig. III-B) and by searching for the optimum threshold level. \Figure!t[width=0.35]pdf/threshold.pdfHistogram of the image data. The red line, i.e., the grayscale threshold, divides the graph into two parts: the background and the foreground. The gray gradient bars indicate the associated color to each $x$-value, from [math] to $255$.

Starting from the foreground grayscale image (see, Fig. 7(b)), the script deals with labeling the individual blobs by using the connected-component labeling algorithm [46] with a fixed heuristic (8-connected, in the considered case). In Figure 7(c) the obtained blobs are depicted with different colors and numbers for visual convenience. Then, the script selects the blob that meets the criteria in terms of size and intensity (chosen to match the target properties) in order to obtain a unique bounding box surrounding the target (see, Figs. 7(d) and 7(e)). Finally, the script provides as output a MAT-file containing, for each positive image, the suitable ROI components, i.e., the bounding box centroid, its width and height. This file is used for the classifier synthesis in the target detection design process (see, Fig. II).

The proposed approach allows to automatically label the target (the car) from the positive images, thus decreasing the time spent for the training phase. In Figure III-B, for a single sample frame, all elaboration steps are reported.

On the considered data set, the script was able to automatically detect the ROIs with an error of $8.18\text{\,}\mathrm{\char 37\relax}$: the target was not recognized only in $215$ frames out of $2626$ positive images, and the first ROI loss appeared at the $1791$th frame.

III-C Classifier synthesis

The Viola & Jones algorithm [50] was chosen as object detection framework to recognize the car along the path. The algorithm was originally designed and developed for face detection problem, but it can be easily trained to detect any object [51] by using different features types (e.g., Haar, HOG, LBP) [42] and training stages555This is common in cascade classifiers where each stage is an ensemble of weak learners, i.e., simple classifiers called decision stumps.. Although even more complicated and performing object detection frameworks (e.g., YOLO [28, 29], Fast R-CNN [30, 29]) are available in the literature, historical reasons motivated this choice: the Viola & Jones classifier was the first object detection framework in real-time. Thus, it is of interest, at least for educational purposes, to have a simulation platform that performs object detection with such a solution.

For the considered testbed, the Haar features were used to design the classifier. These features along with LBP are often used to detect faces due to their fine-scale textures while HOG features are often employed to detect objects. However, the obtained results suggested to choose Haar features which appeared more useful for capturing the overall shape of the target (see, Fig. III-C) even if longer time was needed during the training phase. \Figure!t[width=0.48]pdf/testImages.pdfDetection results obtained by using Haar, HOG and LBP feature types. The false alarm and true positive rates are $0.001$ and $0.995$, respectively, while the number of training stages is $4$. Two different target models are considered: the “corrected” and “uncorrected” version.

III-D Performance comparison

When designing a cascade object detector, the number of training stages, the false alarm and true positive rates, need to be tuned in accordance to the required performance (e.g., accuracy) and constraints (e.g., time response). To facilitate the analysis as well as to find the most suitable set of parameters that fit the problem, a Matlab script was developed to evaluate the performance of the classifier. This script is part of the proposed software platform (see, Fig. II) and allows to compare in a few steps various configurations and models getting a general overview of how the object detector behaves.

In Fig. III-C the results obtained for a single sample frame are reported. Two different models were considered to prove the validity of the proposed approach: the uncorrected and corrected models. The first one uses the ROIs automatically extracted from the algorithm presented in Sec. III-B, while the second one employs those obtained using the Matlab tool Training Image Labeler. In all revelations, the car is only partially detected despite the large number of images employed to train the classifier. Except for some cases, there are no revelation errors: different bounding boxes are detected in the image. This is probably due to the absence of photorealism in the collected frames. As described in [52], the reality gap (i.e., realistic geometry, textures, lighting conditions, camera noise, and distortion) affects the performance of computer vision algorithms. On the other hand, they introduce enough “useful noise” to help the detection (the presence of several image view points).

Many tests have been conducted in order to assess the true performance of the classifier. As shown in Figs. 9(b) and 9(c), the detection results are very similar for both models. Thus, it is a good approximation to consider the “uncorrected” ROIs instead of the “corrected” version in the classifier design process. Such approximation allows to save time during the training phase thus avoiding to use specific tools, such as the Matlab tool Training Image Labeler, when the ROI detection fails. Moreover, it proves the validity and the effectiveness of the automatic tool procedure for bounding box selection. Of course, further tests may be carried out considering more valuable evaluation criteria, such as confusion matrix, accuracy, precision, recall, specificity [29].

IV Vision-Based Target Detection

The vision-based target detection phase sets up the IBVS problem using the classifier and tracking algorithms as feedback from the environment (see, Fig. II). There are four components that constitute this part: the vision target selector, the detection and tracking algorithm, and the distance vector computing. \Figure!t[width=0.48]pdf/boundingBoxes.pdfBounding box selection algorithm. The detection results are obtained by using the Haar cascade features type. The maximum (left) and average (right) bounding boxes are computed by using the result obtained from detection (center).

The vision target selector takes care of switching between the detection and the tracking algorithms based on the recognition results: the detector is used only at the first step or in case of partial occlusion, otherwise a CAMShift tracking algorithm [46] is employed to follow the car along the path. This algorithm performs target tracking by searching for its probability distribution pattern in a local adaptive size window. Although it does not guarantee the best performances, the algorithm supplies reliable and robust results [53].

Due to multiple target revelations (see, Sec. III-D), a Matlab script was used to obtain a unique bounding box surrounding the target (the car). The script computes the maximum (Fig. 10(a)) and the average (Fig. 10(c)) bounding boxes, as shown in Fig. IV. The maximum approach puts more trust in the detection results, while the average approach tries to filter out the revelation errors. The “good” choice depends on the particular employed classifier and on the amount of frames used during the training phase. For the considered testbed, the maximum bounding box was chosen to figure out the IBVS problem.

Once the target has been recognized, the distance vector computing block generates the references for the drone trajectory control (see, Sec. VI and Fig. II) measuring the distance between the image ($u_{\mathrm{img}}$, $v_{\mathrm{img}}$) and bounding box ($u_{bb}$, $v_{bb}$) centroids, as depicted in Fig. IV. The vector aims to provide the reference signals ($e_{u}$ and $e_{v}$) to move the drone so that the center of the bounding box surrounding the car overlaps the centroid of the image. \Figure!t[width=0.48]pdf/imageFrame.pdfThe diagram shows how frames are processed once the target is detected. The distance vector and the bounding box are represented in blue and yellow, respectively. The image ($u_{\mathrm{img}}$, $v_{\mathrm{img}}$) and bounding box ($u_{bb}$, $v_{bb}$) centroids are also reported.

V Drone Dynamical Model

For the specific case study, a quad-rotor in a plus configuration has been considered. The design of a high performance attitude and position controller requires often an accurate model of the system. It is here recalled the commonly used dynamical model of a quad-rotor [54] and, by following usual approaches, two orthonormal frames are introduced: the fixed-frame $O_{\mathrm{FI}}$ (where FI stands for Fixed Inertial), also called inertial (or reference) frame, and the body-frame $O_{\mathrm{ABC}}$ (where ABC stands for Aircraft Body Center) that is fixed in the aircraft center of mass and is oriented according to the aircraft orientation, see Fig. V. \Figure!t[width=0.4]pdf/drone.pdfDrone in the body-frame ($O_{\mathrm{ABC}}$) and the fixed-frame ($O_{\mathrm{FI}}$) reference systems. Forces produced by each rotor, spin directions and propeller velocities, $\Omega_{i}$, are also reported.

The translational dynamic equations of the aircraft can be expressed in the inertial frame as follows:

[TABLE]

where $g$ denotes the gravity acceleration, $m$ the mass, $u_{T}$ the total thrust produced by the rotors, $\boldsymbol{\xi}=(x,y,z)^{\top}\in\mathbb{R}^{3}$ the drone position expressed in the inertial frame, $\mathbf{E}_{z}=(0,0,1)^{\top}$ is the unit vector along the $Z$-axis, while $\mathbf{R}(\varphi,\vartheta,\psi)\in\mathbb{R}^{3\times 3}$ is the rotation matrix from the body to the inertial frame and it depends on the attitude $\boldsymbol{\eta}=(\varphi,\vartheta,\psi)^{\top}\in\mathbb{R}^{3}$ (i.e., Euler angles roll, pitch, and yaw, respectively) that describes the body-frame orientation according to the ZYX convention [55]. Furthermore, the rotational dynamics can be expressed as

[TABLE]

where ‘$\times$’ denotes the vector product, $\boldsymbol{\omega}_{B}=(\omega_{x},\omega_{y},\omega_{z})^{\top}\in\mathbb{R}^{3}$ is the angular velocity vector expressed in the body-frame, $\mathbf{I}=\text{diag}(I_{x},\,I_{y},\,I_{z})\in\mathbb{R}^{3\times 3}$ is the inertia matrix of the vehicle w.r.t. its principal axes, and $\boldsymbol{\tau}=(u_{\varphi},u_{\vartheta},u_{\psi})^{\top}\in\mathbb{R}^{3}$ is the control torque vector obtained by actuating the rotors speeds according to the rotors configuration and the vehicle shape.

At low speeds and around the hovering state, the simplified dynamic model consists of six second order differential equations obtained from balancing forces and momenta acting on the drone, where $c_{\bullet}$ and $s_{\bullet}$ denote the $\cos(\bullet)$ and $\sin(\bullet)$ functions, respectively:

[TABLE]

[TABLE]

with

[TABLE]

and

[TABLE]

where $\Omega_{i}$, $i~{}\in~{}\{1,2,3,4\}$, are the actual rotors angular velocities expressed in $\mathrm{rad}\text{\,}{\mathrm{s}}^{-1}$, $l$ is the distance from the propellers to the center of mass, while $b_{f}$ and $b_{m}$ are the thrust and drag factors, respectively. Further details can be found in [54, 45, 55]. Table I reports the parameters values of the drone for the considered case study (see Sec. VI-C).

VI Flight Control System

Various state-of-the-art solutions investigate the trajectory tracking problem with quad-rotors. However, not all of them are suitable for the specific case of application [56]. Therefore, with the aim of illustrating a control design methodology exploiting the IBVS approach, it has been considered the flight control system described in [45] and [57] that uses a reference generator and an integral backstepping controller to figure out the drone trajectory tracking problem. The reference generator extracts the information from the images to generate the path to follow, while the  Integral Backstepping (IB) controller uses those references to compute the needed drone command signals. Figures VI and 11 describe the overall control scheme. \Figure!t[width=0.475]pdf/attitudePositionController.pdfThe reference generator scheme referred to virtual reference system ($O_{\mathrm{FVR}}$). The obtained heuristic PID gains are: $K_{P_{\psi_{r}}}=1\cdot 10^{-5}$, $K_{I_{\psi_{r}}}=1\cdot 10^{-3}$, $K_{P_{\vartheta_{r}}}=1\cdot 10^{-5}$, $K_{I_{\vartheta_{r}}}=1\cdot 10^{-3}$, $K_{P_{x_{r}}}=1\cdot 10^{-6}$, $K_{I_{x_{r}}}=6\cdot 10^{-6}$, $K_{P_{y_{r}}}=1\cdot 10^{-2}$, $K_{I_{y_{r}}}=1\cdot 10^{-2}$, $K_{P_{z_{r}}}=15$, $K_{I_{z_{r}}}=57.5$ and $K_{D_{z_{r}}}=3.75$. \Figure!t[width=0.47]pdf/trajectoryOutput.pdfThe car (in blue) and the output of the reference generator (in red) while tracking the target.

VI-A Reference Generator

The reference generator is decomposed into two parts: the attitude and the position controller, both illustrated in Fig. VI. The attitude controller tunes the yaw ($\psi_{r}$) and the pitch ($\vartheta_{r}$) angles trying to overlap the image ($u_{\mathrm{img}}$, $v_{\mathrm{img}}$) and the bounding box ($u_{bb}$, $v_{bb}$) centroids (see, Fig. IV), while the roll ($\varphi_{r}$) angle is computed by the IB controller666All elaborations are expressed in the $O_{\mathrm{FVR}}$ reference system.. These values are later used by the position controller to vary the drone reference position $z_{r}$ and $y_{r}$, while $x_{r}$ is computed comparing the detected area $area_{\mathrm{bb}}$ with those obtained when training the classifier $area_{\mathrm{ref}}$777This values is obtained as sample of mean of the collected ROIs while training the classifier (see Sec. III-A).

The proposed control architecture is based on control loops that are nothing but  Proportional-Integral-Derivative (PID) controllers. These are a standard solution in the literature for quad-rotor control design [58]. For the considered case study, the vehicle starts flying $4$ meters over the ground ($Z$-axis) with a distance of $15$ meters from the car along the $X$-axis in the $O_{\mathrm{FVR}}$ reference system.

Figure VI reports the trajectories followed by the car and the drone when running the simulation, while a further video has been made available at [59].

VI-B Integral Backstepping controller

The integral backstepping of [45, 54] has been used as trajectory controller for the path tracking. It performs robustness against external disturbances (offered by backstepping) and sturdiness w.r.t. model uncertainties (given by the integral action). Starting from the outputs of the reference generator, the IB controller computes the orientation ($\varphi_{\mathrm{ref}_{\mathrm{IB}}}$ and $\vartheta_{\mathrm{ref}_{\mathrm{IB}}}$) that the drone should assume to follow the reference path ($x_{r}$ and $z_{r}$). The $\varphi_{\mathrm{ref}_{\mathrm{IB}}}$ and $\vartheta_{\mathrm{ref}_{\mathrm{IB}}}$ reference angles are computed as:

[TABLE]

[TABLE]

with

[TABLE]

and

[TABLE]

For the considered motivating examples, the following values have been chosen: $\lambda_{1}=0.025$, $\lambda_{2}=0.025$, $c_{1}=2$, $c_{2}=0.5$, $c_{3}=2$ and $c_{4}=0.5$. Figure 11 shows the overall control system architecture. \Figure!t[width=0.42]pdf/lowLevelControlArchitecture.pdfThe drone trajectory controller. All variables are expressed in the virtual reference system ($O_{\mathrm{FVR}}$). Here we recall the heuristic control gains employed into the simulation scenario: $K_{P_{y_{att}}}=1000$, $K_{D_{y_{att}}}=200$, $K_{P_{\varphi_{att}}}=8$, $K_{D_{\varphi_{att}}}=4$, $K_{P_{\vartheta_{att}}}=12$, $K_{D_{\vartheta_{att}}}=4$, $K_{P_{\psi_{att}}}=10$, and $K_{D_{\psi_{att}}}=4$.

VI-C Numerical results

To prove the validity and effectiveness of the proposed framework, numerical simulations have been carried out by using the 2015b release of Matlab equipped with CVS and VR toolboxes888The simulator is fully compatible with each further release of Matlab.. The video available at [60] illustrates in a direct way how the system works, i.e., the ability of the quad-rotor to follow the car that moves along the nontrivial path. In addition, the video shows the behavior of the detection and tracking algorithms that never lose the target while tracking the target. Moreover, the video shows the capabilities of the control system in reacting to changes in the car’s dynamics: during the double lane change maneuver the vehicle suddenly increases its speed and the aircraft tilts around the $X$-axis (the car seems to climb a hill999The drone flies in an eye-in-hand configuration, i.e., tilts around the axis direct affects the camera orientation.) to capture the shift in the dynamics.

A further scenario (the video is available at [61]) was considered to show how the simulation can be easily customized without the need to redesign the entire system. The numerical example aims to show how the performance of the detection and tracking algorithms can be easily evaluated while running alongside the drone tracking controller. Two cars are considered for the case of interest. One (red car) engages the ESP control while the other (yellow) switches off such control unit when changing the lane. As it can be seen from the video, the search window adapts its sizes in response to partial occlusions of the target.

Finally, the video at [62] shows the advantages of using a modular architecture for the platform. The video shows how the whole system architecture can be tested under various conditions simply changing the scenario101010The vr_octavia scenario was considered.. As shown in the video, halfway through the simulation ($26\text{\,}\mathrm{s}$) increasing the speed of the car causes the drone to tilt excessively moving to instability.

The proposed scenarios demonstrate as the software platform allows to test the complex system while interacting with the surrounding environment and computer vision and control algorithms are in the loop.

VII Conclusions

In this paper, a numerical simulation platform for multi-rotor aircraft based on Matlab and the MathWorks Virtual Reality and Computer Vision System toolboxes has been described. The platform makes easy to implement and to simulate complex scenarios where computer vision algorithms can be run and tested together with drone tracking controllers. The simulator provides a ready-to-use environment allowing students, researchers, and developers to easily test and evaluate their own algorithms. The platform also constitutes the first step towards the development of a more structured software tool where exploiting the advantages of software-in-the-loop simulations. The software has been released as open-source3 making it possible to go through any part of the system. Future work includes the integration of the platform with more advanced robotics middleware and the creation of the interface with the hardware moving toward hardware-in-the-loop tests.