APPENDIX 1 READING AND PROCESSING MOVIES IN MATLAB

Transcription

1 185 APPENDIX 1 READING AND PROCESSING MOVIES IN MATLAB The discussion in the Chapter 4 on the position and attitude estimation of a UAV from the images acquired by an on-board camera required the frames (images) extraction from the video movie file captured. Video movie files can be represented in many file formats, such as avi (which stands for Audio Video Interleave ). Matlab can read avi files using the command: mydata = aviread ( myfile.avi ); This will decompress each frame of the video and load the entire sequence into a very large array. You can play the movie using the following steps: movie (mydata); mydata =aviread('myfile.avi'); movie(mydata); numframes =size(mydata,2); for i =numframes:-1:1 grayimages(:,:,i) = rgb2gray(mydata(i).c); end movie2avi(mynewdata, 'mynewfile.avi');

2 186 The variable mydata is an array of structures, one for each frame of the video. Each frame structure consists of two fields, cdata and colormap field is a table of colors that is used only for indexed color videos. Most videos that you will encounter use true color, meaning that a full 3-component color value is stored at each pixel. This information is stored in the cdata structure. To extract all images of the video and convert them to grayscale, for example, you can use: numframes = size (mydata, 2); for i = numframes:-1:1 grayimages (;,;,i) = rgb2gray (mydata(i).cdata); end This will create a three dimensional array of images, with the first two dimensions being the rows and columns of the images, and the third dimension being the frame number. Running the loop backwards, from numframes down to 1, is a common Matlab programming trick to ensure that grayimages is initialized to its final size the first time through the loop. After modifying a video, we sometimes want to save a copy. You can export the new video as follows: movie2avi (mynewdata, mynewfile.avi );

3 187 APPENDIX 2 MATLAB/SIMULINK INTERFACING WITH FLIGHT GEAR All of the commercial simulators have a serious drawback: they are made by a small group of developers defining their properties according to what is important to them and providing limited interfaces to end users. Anyone who has ever tried to contact a commercial developer would agree that getting your voice heard in that environment is a major challenge. In contrast, Flight Gear (FG) is designed by the people and for the people with everything out in the open. Flight Gear is a free flight simulator developed cooperatively over the Internet by a group of flight simulation and programming enthusiasts. The simulation results presented in Chapter 4 are obtained using the interface methodology discussed here. Most commercial developers want to be able to serve a broad segment of the population, including serious pilots, beginners, and even casual gamers. In reality the result is always a compromise due to deadlines and funding. Flight Gear is a volunteer driven open-source project. As FG is free and open, there is no need for such a compromise. In comparison to other recent flight simulators, the system requirements for Flight Gear are not extravagant. A decent PIII/800, or something in that range, should be sufficient to have a proper 3-D graphics card. Additionally, any modern UNIX-type workstation with a 3-D graphics card will handle Flight Gear as well. One important prerequisite for running Flight Gear is a graphics card whose driver supports OpenGL.

4 188 A2.1 FLIGHT GEAR UDP COMMUNICATION The advanced option in Flight Gear wizard helps the user to type in the socket name, transmission in/out type, the IP address of the system where the Flight Gear is to be interfaced, the port no. and the protocol type whether TCP/UDP etc. Figure A2.1 Flight Gear wizard The simulink block in Figure A2.2 shows the flight gear interface block and the triggered subsystem (algorithm) which calculates the relative height and lateral deviation which is then being displayed. Figure A2.2 SIMULINK model for interfacing with Flight Gear

5 189 APPENDIX 3 MATLAB/SIMULINK INTERFACING WITH X-PLANE Although there exist several simulators like Microsoft s Flight Simulator, and Flight Gear, X-Plane provides extremely accurate flight models and allows for external communication as well as airfoil design. It is accurate enough to be used to train pilots. Unlike other Flight Simulators, X- Plane also allows for input and output from external sources. X-Plane provides future capabilities that unmanned aerial vehicles will need, including navigation markers, changing weather conditions, and air traffic control communication. The main reason for the selection of X-plane in this part of work is because of its property to easily interface with external sources. A3.1 X-PLANE UDP COMMUNICATION X-Plane uses UDP communication to send and receive data packets; this allows for changes to be made to various values within X-Plane. The UDP protocol has advantages and disadvantages. UDP may be unreliable over a distant network connection because no error detection exists in the packets; on the other hand, UDP is extremely fast. X-Plane is able to dump up to 50 frames per second across a local network; this has an important impact on controller functionality (and simulation) because they require sufficient update speed to operate correctly. For interfacing the algorithm with X-Plane as discussed in Chapter 6, the program in MATLAB was run and the required data i.e.

6 190 ROLL, ALT, YAW of the UAV with respect to airport runway was saved in a workspace file. For this one variable was declared having 4 rows and columns equal to the number of locations available. The first row contains the time values starting from zero. The three rows then contain the ROLL, ALT, YAW locations respectively. In SIMULINK the workspace file was used in the From File block. For transferring the data to X-Plane it has to be in the specified format and sequence. The first 5 bytes contain the ASCII codes for V, E, H, 0, 1.the constants for these values should be in int8 format. Next 4 bytes contain the number for the air plane to be controlled using the SIMULINK model. For controlling 1 airplane it is equal 0. The format for this constant is int32. The user data e.g. latitude, longitude and altitude data has to be in double format which takes 8 bytes for each variable (X-plane user manual). The next 6 data variables are Euler angles (,, ) and control variables (landing gear, flap, thrust vector) which should be in single format which takes 4 bytes for each variable. All the bytes have to be reversed before giving them to Pack block. The data types for all the data has to be specified in the Pack block. The output of Pack block is then given to the UDP Send Block. In this block the IP Address of the Target Computer has to given along with the port number. By default X-Plane uses port number The blocks required for the UDP communication are available in the PC Target group in UDP group in SIMULINK Library Browser.

7 191 A3.2 OUTPUT WHILE INTERFACING WITH X-PLANE Figure A3.1 X-Plane output-viewed from back Figure A3.2 X-Plane output-cockpit view Figure A3.3 X-Plane data output

8 192 Figure A3.4 SIMULINK model for interfacing with X-Plane The settings to be done in X-Plane are described below in Figure C.2 and C.3 to enable the interfacing with the external file where the estimated data to be visualized in 3D space are stored. In the X-Plane, from the main window go to settings menu and select Data Input and Output option. In the Data Set tab, tick the data to be displayed on the screen in the Cockpit during flight column. Figure A3.5 Data Set Tab

9 193 In the Inet 2 tab select the IP address of data sender and enter the IP Address of the data sending computer and the port number to it (Daniel Ernst et al 2006). Figure A3.6 Inet 2 Tab

10 194 APPENDIX 4 TRANSFER FUNCTIONS The stability and control derivatives that are useful in the derivation of transfer functions are obtained using Flight Dynamics and Control Tool Box. Using this, the longitudinal transfer functions presented in Chapter 6 and the lateral transfer functions are derived and given below using the formulae given the references (Blakelock(1990, Roskam (1979), Stevens (1992)). Transfer Function Alpha_delE s^ e004 s 330 s^ e005 s^ e003 s Transfer Function Alphadot_delE s^ e004 s 330 s^ e005 s^ e003 s Transfer Function Theta_delE 1.13e004 s e s^ e005 s^ e003 s Transfer Function Thetadot_delE 1.13e007 s e s^ e005 s^ e003 s

11 195 Transfer Function Beta_delR 2352 s^ e004 s 330 s^ e004 s^ e005 s Transfer Function Betadot_delR 2352 s^ e004 s 330 s^ e004 s e005 Transfer Function Psi_delR s e s^ e004 s^ e005 s Transfer Function Psidot_delR s e s^ e004 s e005