During the HMI’s design process, the HMI was ported to Android to provide flexibility out in the field by running on a tablet. Since the Android platform is based on Java, the HMI had to be ported using a Qt plug-in. Unfortunately, when the communication threads were implemented using DUNE sockets, the HMI could not be ported to Android. The reason for this was the DUNE package uses libraries which are not supported by the Android platform. Making the HMI run on an Android device is not crucial for making the object tracking system airborne, but would be a feature which is nice to have out in the field. If the HMI implementation should be used after a NEPTUS implementation is supporting the necessary functionality, it would be up to the new users to decide if an Android deployment should be realized. Figure 7.22 shows the HMI deployed to an Asus Transformer tablet.
Chapter 8
Simulation of the control system
In this chapter we will showcase the performance of the MPC discussed in chapter 5. We present several test cases, each with different object configurations. Before we introduce the test cases we will take a look at some general comments as well as the most important findings from the simulations. The test cases have been simulated by running the ACADO’s OCP functionality in a loop where all initial values are updated from previous iterations. The test cases could be examples of scenarios where the UAV object tracking system is used to monitor installations in an open terrain such as marine structures. It could also serve to monitor environmental effects such as erosion, snow and ice build-ups, or help in human rescue operations.
There is no simulator in this implementation1. Even though the UAV’s kinetics are included these results are not realistic. The test cases are however meant to give an idea of the MPC’s performance controlling the gimbal together with providing the Piccolo with way-points to achieve the control objective. In the following test cases we used a simple sinusoidal mapping between yaw rate and roll angle,
φ = 5 sin(−r), (8.1)
which gives a roll angle bounded by φ ∈ [−28.6◦, 28.6◦] as the yaw rate is kept within
r∈h−5.73degsec, 5.73degseci. This is a simplification of equation (3.36), and should be sufficient for the test cases described in this chapter. The roll angle is indicated above each North-East plot. The tests are performed with zero pitch angle, meaning a level flight. This is a simplification based on the fact that most of the operations will be at a constant altitude, and therefore variations in the pitch angle should be minimal. The system is however designed to compensate for variations in the pitch angle, as with variations in the roll angle.
Throughout the test cases we use two kinds of plots to describe the UAV’s time varying attitude and position. To show the UAV’s position we have used a two-dimensional North-East plot. Using figure 8.1 as an example, one can see the outline of the GFV marked by the blue lines. In this chapter the gimbal’s maximum tilt angle is set to 80◦2, thus the GFV is stretched
far in front of the UAV. This needs to be considered when studying the plots as the camera might not be able to detect everything within the GFV, especially in the far end due to a decrease in resolution per ground surface area. We work under the assumption that the camera is able to detect the object when the distance between the object and the UAV is less than 300 meters. This assumption is dependent on the MPC’s ability to keep the GFV center pointed straight towards the object. This gives an open loop with no means of validating the GFV’s center position in real-time. The results indicate that this is a valid assumption. The blue cross xin the North-East plot depicts the position of the GFV center. The UAV’s position is
1
State feedback is used to close the control loop.
2
The gimbal’s specifications depicts a maximum tilt angle of 80◦. However, as will be discussed in later
chapters, the real maximum limit would be approximately 64◦.
104
marked by a black circle with a red dot inside. The past movements of the UAV are shown by a black path behind the UAV. The objects change color from red circles o to blue circles o as the objects are entering the current objects list. When an object is visited it is marked by a green circle o, and stays green until all the objects in the object list have been visited and the visited object list is emptied.
The second type of plot is a grouping of six smaller plots, which shows ψ, α, β, r, ˙α and ˙β. These plots show the values of the variables during the current iteration of the simulation loop. Note the green line in the tilt angle plot which represents the maximum tilt angle available from the BTC-88 gimbal’s specifications.
−20000 −1500 −1000 −500 0 500 1000 1500 2000 500 1000 1500 2000 2500 3000 3500 4000
step =108#, roll =0.13913 state =underways, timer:0
EAST NORTH 108 110 112 114 0 0.5 1 alpha 108 110 112 114 −2 0 2 beta 108 110 112 114 −2 0 2 alpha dot Time [s] 108 110 112 114 −2 0 2 beta dot 108 110 112 114 −2 0 2 psi Angle [rad] 108 110 112 114 −0.2 −0.1 0 0.1 0.2 r
Angle rate [rad/s]
Figure 8.1: Example of a North-East plot with attitude plots.
The current state is shown on top of every North-East plot, see figure 8.1. The holding state is initiated when the UAV is closer than 300 meters from the object to be tracked. An accepted distance of this magnitude is necessary because of the wide turning radius. This means that the UAV is not able to maintain a circular pattern much tighter than a 300 meter radius. At this radius the GFV center is about 175 meters from the objective due to the roll angle and limited tilt angle. The distance between the GFV center and the object is not much of a concern as the object remains well within the boundaries of the GFV, but the closer they are to the GFV’s center the more reliably the system will perform during changes in the UAV’s attitude. Once the holding state is initiated the UAV locks on to its targeted objective for an additional 30 iterations, or 30 seconds, before choosing a new object to track and the state is changed to Underways.
During the course of these simulations we have for the most part used the set of ACADO parameters given in table 8.1.
Chapter 8. Simulation of the control system 105
Time horizon T 20 sec.
Max iterations 20
Max iteration length 1 sec.
Table 8.1: Default ACADO OCP parameters.
The parameters in table 8.1 were found by a trial and error approach. If the max iterations limit increases beyond the limit of 20 iterations it would be of the cost of the simulation’s time consumption, without any noticeable increase in accuracy. By using a horizon of 20 seconds together with a step length of one second, an acceptable compromise between performance and time consumption is achieved.
Originally, we wanted to use the position of the GFV’s center to increase accuracy by minimizing the distance between the GFV’s center and the object to be tracked. However, because of the limited availability of temporary calculations, such as the GFV’s center coordinates throughout a MPC horizon, we are not able to use real time comparisons in the MPC’s objective function. This is because the GFV’s center is not defined as a differential state in the MPC formulation, and the lack of availability to temporary calculations is directly tied to the ACADO namespace. Therefore we have decided to use the UAV’s position and thereby rely on the system’s ability to direct the camera towards the object without feedback.
In test cases we have timed each loop which gives us the means to compare time consumptions from different cases, and see how the number of objects and the ACADO parameters affect the time consumptions. For the first numbers of test cases, except for the long horizon case, a simple pattern of three moving objects arranged in a triangle were used. The objects start out a ways apart, but slowly move towards each other.
8.1 Important results
It is important to note that although we have left a margin on the demands for time consumption, it is not certain this is enough to compensate for the difference in performance between the desktop used for these tests and the PandaBoard intended for the final implementation. One should also note how the number of objects in the object list affect the time consumption. Depending on how many of the control inputs from each loop are to be used, the time consumption needs to be within certain boundaries.
Using high speed objects we experimented with using much larger time horizons hoping this would further improve the tracking efficiency. This was not the case and any slight improvement in the path led to a severe deterioration of the gimbal control.
Due to limitations in horizon length and gimbal performance, we are not able to tune ACADO parameters to get a significant improvement from knowing the objects’ velocity vectors. A longer horizon could be useful when the objects are located far away from the UAV. Since the gimbal’s role is limited at great distances, the gimbal’s movements could be restricted to damping, as described in chapter 5.9.1. It might be beneficial to use the gimbal for other purposes, such as searching for new objects, while the UAV is traversing long distances and