Design Specification UAV with stabilized camera

Transcription

1 Design Specification UAV with stabilized camera Version 1.0 Author: Erik Linden, Hamdi Bawaqneh, Olof Backman, Per Johansson Date: December 5, 2010 Status Reviewed Approved

2 Project Identity Group Homepage: Orderer: Customer: Course Responsible: Project Manager: Advisors: Per Skoglar, Linköping University Phone: , David Törnqvist, Linköping University Phone: , David Törnqvist, Linköping University Phone: , Erik Lindén Sina Khoshfetrat Pakazad, Linköping University Phone: , Group Members Name Responsibility Hamdi Bawaqneh Aircraft hamba208 Olof Bäckman Tests oloba221 Magnus Degerfalk magde580 Fredrik Eskilsson Gimbal frees868 Per Johansson perjo871 Erik Jonsson Holm Design erijo975 Therese Kjelldal Documents thekj512 Erik Lindén Project Manager erili277 Gustav Öst Information gusos234

3 Document History Version Date Changes made Sign Reviewer First draft Minor changes Updates to section 2.7

4 Contents 1 Introduction Who is involved Goals Usage Background information Definition of terms Overview of the system Description of the system Product components Dependency on other system Included subsystems What is not included Design philosophy Definition of coordinate systems Relationships between coordinate systems Obtaining and transforming the target vector to the gimbal coordinate system Subsystem 1 - Aircraft Hardware Overview and connection ArduPilot ArduIMU Actuators Electronic speed control Motor GPS Xbee Radio receiver Software ArduPilot ArduIMU Subsystem 2 - Gimbal Hardware Overview and connection Camera mount Servos ArduIMU Video camera Video link Software ArdIMU Control strategy Subsystem 3 - Simulation and software 17

5 5.1 Aircraft model Gimbal model Path generation Path visualization

6 UAV 1 1 Introduction The purpose of the project is to modify an existing control system for an autonomous unmanned aerial vehicle (UAV) and to steer and stabilize a camera placed on a gimbal on the UAV. The camera shall be able to look at specific points on the ground. The camera image is sent to a computer via a wireless video link. The platform that is used in the project is the airplane Multiplex Easystar and the control system Ardupilot. The positioning system of the UAV will be based on a GPS and an IMU. The gimbal will be build by the group members and equipped with an IMU to make it possible to compensate for the movements of the UAV. 1.1 Who is involved The customer is David Tornqvist and the orderer is Per Skoglar, both at the Department of Electrical Engineering (ISY). The project group consists of 10 people studying the project course TSRT10. Four of these study M (Mechanical Engineering), five study Y (Engineering Physics and Electronics) and one studies I (Industrial Engineering and Management). 1.2 Goals Surveillance utilizing small, unmanned aircraft will become increasingly common in the future, as police, rescue services, security companies etc starts to use the technology. The goal of this project is to develop a system where a user can specify a flight path for a UAV. A camera which will be able to lock on to points of interest on the ground will be mounted. 1.3 Usage The system can be used in a number of different ways. For example: surveying damage to power lines or forests after a storm, or to look for missing persons. Another possible use is recording orienteering competitions for television broadcast. 1.4 Background information In this project a platform consisting of the model aircraft Multiplex EasyStar and the control system ArduPilot will be used. The control system is developed as an Open Source project with extensive documentation, and can therefore be modified if needed. A gimbal, constructed from a gimbal kit, will used to mount the camera while the control system to stabilize it will be developed by the group. 1.5 Definition of terms ArduPilot - Open source control system for model airplanes ArduIMU - A complete board consisting of an IMU unit and a micro controller to correct for the drift in the IMU unit itself, with the aid of data from the GPS. Xbee - Wireless modem from airplane to ground IMU - Inertial Measurement Unit RC - Radio Communication GPS - Global Positioning System

7 UAV 2 UAV - Unmanned Aerial Vehicle HIL - Hardware In the Loop. The system is connected to the simulation environment. I2C - Inter-Integrated Circuit ESC - Electronic Speed Control. A unit controlling the speed of the GCS - Ground Control Station aircraft motor. A.S.L - Above Sea Level 2 Overview of the system 2.1 Description of the system A model aircraft, capable of autonomous flight, should with the aid of a camera be able to view specified points on the ground. 2.2 Product components Figure 1: Basic overview of the system The product consists of the model aircraft Multiplex EasyStar controlled by the opensource control system ArduPilot, which makes use of a GPS and an IMU to navigate. The aircraft is equipped with a video camera mounted on a two-axis gimbal, and is also equipped with an IMU. The video camera transmits the image via a separate video link to a receiver on the ground. Wireless communication between the aircraft and a computer is done via the Xbee modem interface. Figure 1 shows a schematic diagram of how the different components interact. There is also an object oriented environment for simulating the aircraft and the gimbal. A more detailed connection scheme is described in figure??.

8 UAV 3 Figure 2: Connection scheme 2.3 Dependency on other system The aircraft is dependent on a computer where the user generates the desired flight path. To determine its position it uses the GPS satellite navigation system. 2.4 Included subsystems The system can be devided into the following subsystems: - Aircraft ï 1 2 Hardware ï 1 2 Software - Camera unit ï 1 2 Hardware ï 1 2 Software - Simulation environment and software 2.5 What is not included Because of the analog nature of the video data, no image processing will be performed. This means that the camera won t be able to track arbitrary targets. The flying will be performed primarily in good weather conditions, and with simple paths.

9 UAV Design philosophy In order for the group to work in an efficient way, it is important that the different components of the product can be developed and evaluated individually. Any computer code used will be written as generally and easy to survey as possible. 2.7 Definition of coordinate systems The system will effectively use 3 different orthogonal, right oriented coordinate systems to describe positions, velocities and vectors. Also the universal World Geodesic System is used by the GPS equipment. The fixed earthbound system is defined using the aviation convention NED, with the x-axis pointed North, y pointing East and z pointing Down. The 2 non-fixes coordinate systems will be defined as FRD, with F in the forward direction, R to the right and D down. See figure 3 for a description of the orientation for the different coordinate systems. They are fixed in the following positions: - World Geodetic System. Abrevated (W). GPS coordinates are defined using this system. Origin is at the centre of the earth, with the z-axis pointing at the geographic north pole and the x axis pointing through the Greenwitch zero meridian. Will be used by the operator when generating paths and target coordinates. - Earth system. Abrevated (e). N is pointing at geographic north pole, D is pointing down. Origin will be defined somewhere in the vicinity of where we are flying, preferably the take off position. - Aircraft system. Abrevated (a). F is pointing through the nose of the aircraft and D down through the fuselage. Will primarely be used by the ArduPilot to succesfully navigate and stabilize the aircraft. The IMU-1 unit generates R (a2e) fully describing the orientation of this coordinate system. Origin in the IMU-1 unit. - Gimbal system. Abrevated (g). F is pointing forward through the camera lens. Will be used by the software for controlling the gimbal in the desired direction. The IMU-2 unit generates R (g2e) fully describing the orientation of this coordinate system. Origin in the IMU-2 unit. Figure 3: Orientation of the coordinate systems Relationships between coordinate systems Since all GPS coordinates are given in the geodetic (W) system lat/long/height format, a system to convert these to the cartesian (e) system is first needed. Assuming that we will primarily be flying short distances in the vicinity of LIU, we will approximate the

10 UAV 5 transformation of a point expressed in the (W) to the (e) system as the differences in the GPS latitudes and longitudes, in radians, between the origo and the point of interest, multiplied by the radius of the earth. The height difference will simply translate as the (negative) D coordinate. The relationship between each non-fixed coordinate system and the earth-bound (which is approximates as fixed and cartesian) can be described by a directional cosine matrix, or DCM, R. This rotational matrix is computed and continously updated by the corresponding ArduIMU unit, and consists of a 3x3 orthogonal matrix (with 4 independent elements). The matrix transforms the vector v (a), expressed in the coordinate system (a), to the vector v (e), expressed in the earthbound system, in the following way: v (e) = R (a2e) v (a) (1) v (a) = or, since R (a2e) is always orhogonal, equivanlently R 1 (a2e)v (e) (2) v (a) = R T (a2e)v (e) (3) To calculate in what direction to point the camera, which operates in its own (g) system, to observe a given target coordinate the R T (g2e) matrix can be used to conveniently transform the vector describing the camera direction in the (e) system (which is obtained by a simple vector subtraction) to the corresponding vector in the (g) system. Having this vector, since all vectors and matrices are normalized, the pan and tilt angles for the camera can be obtained as the trigonometric functions of the corresponding elements in the directional vector. See section for a more explicit example Obtaining and transforming the target vector to the gimbal coordinate system The controller in the gimbal has 2 signals with which to influence the direction of the camera, the pan (ϕ) and tilt (θ) angles. The pan is the (approximatley, depending on orientation) horizontal angle, rotating the camera around the D axis, with 0 is at the F direction and positive direction towards the R axis. Tilt is the (again, approximate) up and down angle. It rotates the camera around the R axis, with 0 at the F axis and positive direction is towards the D axis. See figure 5 for futher referece. To calculate these angles, the controller need only to know the directional vector from itself to the target in its own coordinate system, (g).

11 UAV 6 Figure 4: Relationships between vectors in different coordinate systems Definitions: O is an arbitrary point of origin, G is the position of the gimbal and X is the positon of the target on the ground. Note: AB denotes the general vector from point A to point B, without implying that a special coordinate system is beeing used. AB (z) is the vector from point A to point B, described using coordinate system z. The same is true for points, A is simply a point in space, while A (z) is the set of coordinates describing this point in the z coordinate system. To start off with, the GPS and the user provides the ArduIMU (after the appropriate transformation from (W) to (e)) with the coordinates of its current position G (e) and the target X (e), respectively (figure 4). To obtain the vector GX (g), an arbitrary point of origin O (e) is introduced. Now GX (e) can be expressed as: GX (e) = OX (e) OG (e) (4) GX (e) = (X (e) O (e) ) (G (e) O (e) ) = X (e) G (e) (5) Now the required vector GX (g) can be obtained by multiplying GX (e) by the correct form of the DCM: GX (g) = R T (g2e)gx (e) (6) The ϕ and θ angles can be obtained using the components ( f, r, d ) T of the vector GX(g) in the following forumlas (similar to those used for standard spherical coordinate systems): ϕ = arctan 2(r, f) (7) θ = π 2 arccos ( d GX (g) ) (8) Figure 5 shows the orientation of pan and tilt angles in the gimbal coordinate system.

12 UAV 7 Figure 5: Obtaining the pan and tilt angles

13 UAV 8 3 Subsystem 1 - Aircraft 3.1 Hardware Overview and connection The aircraft itself is a Multiplex EasyStar model aircraft. It is made out of durable ELAPOR foam, and has in its basic configuration a backwards mounted electric motor, two actuators for controlling yaw and pitch rudders and a radio receiver for operation. There is also a battery pack and a speed control for the motor. In this project the system is expanded with a ready-made autopilot, ArduPilot, developed as an open source project. Using the out-of-the-box features of this autopilot, the aircraft will be able to fly autonomously using user defined GPS coordinates, perform FBW, stabilize the aircraft when controlled by operator, loiter around a specified point, and return to launch if connection is lost. To be able to estimate its position and orientation, the aircraft will use an ArduIMU and a GPS unit. For the aircraft to communicate with a laptop on the ground during flight a wireless serial modem, Xbee, is connected to the ArduPilot ArduPilot The ArduPilot is an open source autopilot system, capable of controlling and stabilizing a model aircraft in autonomous flight. When equipped with a GPS receiver and/or an IMU unit, it can navigate a simple flight path consisting of GPS coordinate waypoints. It acts as the centre of the aircraft system, collecting signals from most of the components and controlling the actuators according to its internal control strategy. If the autopilot is not in use, the signals from the operator on the ground is passed straight through the ArduPilot. However it will still log any data, if desired. The ArduPilot will be connected to the RC receiver and to the following actuators: rudder servo, elevator servo and the speed controller. Once the ArduPilot is connected to the RC receiver and actuators we move on and connect the ArduIMU-1 (with the GPS). Then we go on connecting ArduPilot to the Xbee module and the last step is to connect the voltage and ground for all included units. Voltage received from: ESC (5V) Voltage distributed to: - Rudder/elevator servo - ArduIMU-1 - ArduIMU-2 - Xbee - RC receiver Signals received from: - ArduIMU-1 Aircraft orientation information; roll, pitch and yaw in degrees GPS coordinates; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s

14 UAV 9 - ArduIMU-2 Camera orientation information (level 3 requirement) - Xbee modem Updated route/target coordinates; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s - RC Receiver Signals sent to: Rudder/elevator servo and ESC control signals Autopilot engage/disengage flag - ESC (Speed control signal) - Rudder/Elevator servo - ArduIMU-2 Target location; longitude and latitude in degrees Xbee modem Updated UAV flight data; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s ArduIMU-1 The ArduIMU-1 will be used to estimate the orientation and velocity of the aircraft. It consists of a board with three accelerometers, three gyros and a micro controller (Atmega MHz from Atmel). The micro controller is used to compute the DCM and to correct for gyro drift and numerical errors in the output, using input from the GPS and accelerometers as reference. This is already implemented in open source code and will be used as-is in the project. The unit obtains measurements from its on-board sensors and the connected GPS, processes this information and forwards the orientation and position information to the ArduPilot. Voltage received from: - ArduPilot (5V) Signals received from: - GPS unit Signals sent to: GPS coordinates; longitude and latitude in degrees 10 7, altitude in decimetres a.s.l. and speed in cm/s - ArduPilot Aircraft orientation information; roll, pitch and yaw in degrees GPS coordinates; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s

15 UAV Actuators The aircraft has two actuators to control its flight, the yaw and pitch rudders. These are controlled by two servo motors connected to the ArduPilot. When in manual mode, the signals received from the rc-receiver are passed straight through the ArduPilot, i.e. the operator is in direct control of the rudders. In autopilot mode the ArduPilot controls the rudders. Voltage/signal received from: ArduPilot Electronic speed control The electronic speed control (ESC) is the device controlling the speed of the propeller s electric motor, therefore controlling the speed of the aircraft. It also acts as a voltage regulation unit for the entire system, re-distributing the battery voltage to the ArduPilot. As with the actuators, the reference signal to the ESC can be either under direct manual control, or be handled by the ArduPilot, depending on if the autopilot mode is engaged or not. Voltage received from: Battery (11,1V) Voltage sent to: ArduPilot (5V) Signals received from: ArduPilot (Motor ref. speed) Motor The propulsion of the aircraft is controlled by a backwards mounted electric motor with an attached propeller. The motors revolution speed is controlled by the ESC. Voltage/signal received from: ESC GPS The GPS will be connected to both ArduIMUs and mounted on the aircraft vertically, with the antenna pointing to the sky. Voltage received from: ArduIMU-1 (5V) Signals sent to: - ArduIMU-1&2 GPS coordinates; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s Xbee Xbee is a wireless serial modem, and enables wireless communication between the UAV system and a laptop. It will be used for uploading/updating code, flight paths and camera targets, as well as to log flight data. Can communicate during missions while airborne. Voltage received from: ArduPilot Signals received from: - ArduPilot

16 UAV 11 - Laptop Signals sent to: Updated UAV flight data; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s Updated route/target coordinates; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s - ArduPilot - Laptop Updated route/target coordinates; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s Updated UAV flight data; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s Radio receiver In this project we will use 3 channels on the RC receiver for our rudder servo, elevator servo and for the speed controller. A fourth channel on the RC receiver will be used to enable or disable the autopilot. Voltage recieved from: ArduPilot Signals recieved from: Ground operator (Actuator/motor ref signals) Signals sent to: ArduPilot

17 UAV Software ArduPilot The code used is already implemented as open-source. We ll have to choose a GPS protocol (ArduIMU) in the code. There are some built in flight modes in ArduPilot and those are specified below: ArduPilot can act as a simple flight stabilization system or a sophisticated autopilot. Flight modes are controlled through the radio or through logic, using the events.pde file. Those modes are: - Manual - Regular RC control with no stabilization. - Stabilize - RC control with stabilization; The pilot controls the air plane manually, but ArduPilot stabilizes the aircraft when the sticks are left unadjusted. - Fly by wire - Beginner mode. The operator points the sticks in the direction he wants the aircraft to go, and the ArduPilots controls the aircraft to get there. Can be used with manual or automatic speed control. - Auto - The aircraft follows a path made up of GPS waypoints set by the user. - Return to launch - If ArduPilot discovers that connection with the rc transmitter on the ground is lost, it will return to launch point and loiter there until manual control can be regained. - Loiter - The aircraft will circle around its current position. Since we only have one serial port we will implement an i2c bus to communicate with ArduIMU-1 and ArduIMU-2. The ArduPilot will be the master. The ArduPilot will communicate with the Xbee through the serial port ArduIMU-1 We ll have to choose a GPS protocol (EM406) and maybe also change some user-modifiable options. We ll also have to write code so that the i2c bus works probably and the ArduIMU-1 will be slave-1.

18 UAV 13 4 Subsystem 2 - Gimbal 4.1 Hardware Overview and connection The gimbal subsystem consists of a ready made camera mount with a video camera, rotatable in 2 directions by servo motors (pan and tilt). It has an ArduIMU unit to estimate its orientation and position of the gimbal, and therefore also what the camera is looking at. The IMU will control the direction of the camera to look at points of interest on the ground, and to stabilize it according to some suitable control law Camera mount The camera mount is a commercial unit made out of lightweight fibreglass plates and some bearings. It can be rotated by two servo motors, and has a mount for a video camera. It will be positioned on top of the aircraft to start off with. Because this is not optimal for observing points on the ground, moving it to a better position on the aircraft is included as priority 3 requirement Servos The gimbal has two servo motors directing the camera in pan and tilt direction to achieve the desired orientation. They are controlled by the ArduIMU-2, and are connected to its two servo outputs. Voltage/signal recieved from: ArduIMU ArduIMU-2 The ArduIMU-2, physically positioned in the immediate presence of the video camera, can be used to estimate the orientation and velocity of the gimbal. It consists of a board with three accelerometers, three gyros and a micro controller (Atmega MHz from Atmel). The micro controller is used to compute the Euler angles and to correct for gyro drift and numerical errors in the output, using input from the GPS and accelerometers as reference. This is already implemented in open source code and will be used as-is in the project. What is new in this project is that the control signal to the gimbals two servos is calculated by excess capacity in the micro processor, and executed using the boards two servo outputs. It receives the target GPS coordinates from the ArduPilot, calculates the desired orientation of the camera and adjusts the pan and tilt servos accordingly. Also, as a priority 2 requirement, any disturbances (i.e. shaking, vibration etc) of the gimbal is stabilized, producing a smooth video output. Voltage received from: - ArduPilot (5V) Signals received from: - ArduPilot GPS coordinates of camera target; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s.

19 UAV 14 - GPS unit GPS coordinates of the aircraft; longitude and latitude in degrees 10 7, altitude in decimeters a.s.l. and speed in cm/s. Shared with ArduIMU-1. Signals sent to: Pan and tilt servos Video camera The video camera is mounted on the gimbal and produces a constant video stream, fed to the video link. Voltage received from: Battery (11,1V) Signals sent to: Video link (analogue video) Video link The video link is an wireless analogue link used to transmit the video stream from the camera to a pair of VR glasses on the ground. Voltage received from: Battery (11,1V) Signals sent to: Video receiver on ground

20 UAV Software ArdIMU-2 The software in the micro controller on the ArduIMU-2 will have 2 basic tasks. The first one is the task it is originally built for, and that is to estimate the orientation of the board (=the camera), correcting for gyro drift and other errors. This is already implemented when bought and will be used as-is in the project. For more details refer to the paper by Premmerlani and Bizard (2009)[1]. The second task for the controller is to implement a suitable control law to direct the camera to what ever point(s) on the ground the operator wishes to observe. It will receive the GPS coordinates of the target, in long/lat format from the ArduPilot, compare this with where it is currently looking, and adjust the pan and tilt servos accordingly. The process is schematically depicted in figure 6: Figure 6: Overview of the gimbal software Since the GPS cable will be split and led to both ArduIMU-1 and ArduIMU-2 we ll choose GPS protocol (EM406) in ArduIMU-2 too. The ArduIMU-2 also needs code to be able to communicate with the ArduPilot and ArduIMU-1 through the i2c bus. ArduIMU-2 is also a slave and we ll call it slave Control strategy The controller will be implemented in the micro controller on the ArduIMU-2 and receive target coordinates in the earth reference system from the ArduPilot. The GPS provides updated coordinates of the plane s current position in the earth reference system. By calculations described in section a vector pointing at the target in the gimbal reference system is obtained, continuously updated with information about current position and gimbal orientation through the DCM. The pan- and tilt angles are calculated from the obtained vector. The feedback from the IMU makes it possible to calculate the control error, fed to the controller. See figure 7

21 UAV 16 Figure 7: Control loops Another possible reference signal is the desired pan-and tilt angles generated for example by an operator on the ground (via the joysticks on the RC-radio). In that case the controller will work merely as a gyro stabilizer taking care of disturbances. See figure 8 for a diagram. Figure 8: Control loops, operator controlled gimbal The pan- and tilt angles will be viewed as decoupled, making it possible to use decentralized control, i.e. apply a one dimensional controller for each of them. The possible coupling will be viewed as disturbance. A PID-controller will be implemented for the pan- and tilt angles respectively. Focus will be on a stable controller that follows the reference signal without oscillations. It may be that the coupling effects between panand tilt angles have to be handled more explicit. In that case, an attempt to decouple the signals will be made. If the results aren t satisfactory, a linear-quadratic regulator will be implemented. The LQ regulator makes it possible to handle more complex dynamics of the gimbal and take care of coupling effects better.

22 UAV 17 5 Subsystem 3 - Simulation and software 5.1 Aircraft model Figure 9: The Aircraft The aircraft model will be a 3D simulation with 7 basic inputs; starting position, the two rudders, speed, wind strength, wind direction and a flag to indicate lost connection with the ground unit. We will continuously change the internal control parameters that controls how the aircraft model behaves during flight to match our real aircraft. From the model we will be able to receive pitch, yaw and roll which will be the base of our simulated ArduIMU-1. Based on initial conditions, rudder settings and speed we are also able to create a simulated GPS which we ll need for navigation purposes. A basic overview of the aircraft and its closest dependencies are shown in figure 9. The autopilot receives orders as input, together with IMU and GPS data. Based on this it calculates how to point the rudders and the speed and sends this to the aircraft model. The aircraft model also takes wind into consideration, and calculates its new position and orientation. These new values are then sent back to the autopilot, via dummy GPS- and IMU-models that just saves the values for use in other systems. We will also be able to add disturbances in these two dummy models to get more realistic results when testing requirements. With regards to software it doesn t matter if we use ArduPilot with HIL or our simulated autopilot, since they will use the same interface. When using ArduPilot we will receive simulated IMU- and GPS data via a serial cable. Based on this data it will make its decisions as usual, behaving as if it was in the air. When ArduPilot has decided how to react, it will send its data for the rudders and speed control back into the model in Matlab. The model for the autopilot, which will use a PID-controller, calculates the difference between its heading and where it should head to reach the target and transforms this into angles for the rudders.

23 UAV Gimbal model Figure 10: The Gimbal The gimbal model will have to simulate it s own orientation vector based on the UAV s orientation and previous movements. If the gimbal hasn t moved we can calculate it s current angle based on the UAV s IMU. As soon as we start moving the gimbal around we will update the gimbal s IMU values which will be used in the control loop. As depicted in figure 10, the model for the gimbal will receive GPS coordinates of the target and GPS coordinates from the simulated UAV. Based on the aircrafts orientation it will also create and use its own simulated orientation. These are the same inputs that the real ArduIMU-2 will be using when controlling the camera. With the help of these inputs we re able to use the same code as in ArduIMU-2 for the control of the gimbal, as specified in the Requirement Specification. To be able to tell if we re able to get out target centred in the video, we ll calculate the width of what the camera sees and apply it to the model. 5.3 Path generation After specifying coordinates for the camera to look at, the algorithm will generate waypoints. The model will take into consideration After specifying coordinates for the camera to look at, the algorithm will generate waypoints. The model will take into consideration limitations on turning radius for the air plane, maximum angles for the gimbal etc. The path generating algorithm will be implemented in different ways depending on the placement of the camera and desired ways to film. Different types of path generation will be taken into consideration: - Non-moving target If the target is on a fixed point on the ground, the UAV will fly in a circle around the point at a certain height and with a predefined radius, with the camera pointing at the target. The already implemented mode Loiter will be used in this case, with the target as a waypoint to be circled around. If the target is moved to another fixed position on the ground, the waypoint will simply be changed to the new target position and the UAV will circle around the new target the same way as defined for the first target. - Moving target (The follow car problem ) When a moving target is to be followed the UAV will circle around the target. The radius of the circle will depend on the speed of the moving target. If the target on the ground is moving fast the airplane will almost follow it from straight behind and if the target is moving slow the UAV will circle around it. It can either be implemented as generation of a waypoint on a

24 UAV 19 predefined distance and altitude from the coordinate. Or as a number of waypoints on a circle or part of a circle with a predefined radius and altitude. Generation of the flight path will be done in the simulation software and loaded to the ArduPilot. This will be the same for both the simulation and the real UAV. When adding new waypoint while in the air, these will replace all the previously saved waypoints including the current one. This is done as a safety measure if a waypoint to far away gets uploaded to the UAV. A list of old waypoints will be saved to make it easier to add a waypoint to the beginning of the list without having to retype all previously saved waypoints. The follow car problem will be solved by feeding the software GPS coordinates for the target and based on them calculate new waypoints to be loaded to the ArduPilot via XBee. In both of the previously mentioned cases the software will be the same, since we will be able to send updated waypoints and target locations while in the air. For requirement seven (priority 2), we will have to add a parameter to take time into consideration when planning the flight route. 5.4 Path visualization For the real UAV we will use ArduPilot Ground Control Station (GCS). ArduPilot GCS will both display the flight data and a graphical view of the UAV on a map in live-time, and log all flight data in a.kml file. This file can later be opened and replayed in any.kml reader e.g. Google Earth. In the simulation environment we will use Matlab to plot the information we re interested in since we want as much pure information as possible when testing in the simulator. There is a Google Earth toolbox for matlab which can also be used for a more graphically pleasing visualization. Figure 11 shows an example of how it might look in Google earth.

25 UAV 20 Figure 11: Logged flight in Google Earth

26 UAV 21 References [1] William Premerlani and Paul Bizard. Direction cosine matrix imu: Theory. http: //gentlenav.googlecode.com/files/dcmdraft2.pdf, 2009.