Remote controlled quadcopter

11/13/2014 Electrical Design Project – Final Report Quadcopter Supervisor: Dr Ghayoor Kriban Govender 210512795 Final Report Contents List of symbols........................................................................................................................................ 4 List of figures and tables ......................................................................................................................... 5 1. Introduction .................................................................................................................................... 7 2. Objectives........................................................................................................................................ 7 3. Specifications .................................................................................................................................. 7 4. Theory ............................................................................................................................................. 7 4.1. Coordinate systems................................................................................................................. 7 4.2. Roll and Pitch .......................................................................................................................... 8 4.3. Yaw .......................................................................................................................................... 8 4.4. Hovering/Altitude Control ...................................................................................................... 8 4.5. Quadcopter movement........................................................................................................... 9 4.6. Quadcopter Dynamics............................................................................................................. 9 4.6.1. Rotation Matrix ............................................................................................................. 10 4.6.2. Body fixed angular velocity to Euler rate matrix........................................................... 10 4.6.3. Forces ............................................................................................................................ 10 4.6.4. Force equation .............................................................................................................. 11 4.6.5. Acceleration .................................................................................................................. 12 4.6.6. Moments ....................................................................................................................... 12 4.6.6.1. 4.6.7. Thrust Moment ......................................................................................................... 13 Moment Equations ....................................................................................................... 13 5. Commands .................................................................................................................................... 14 6. Rotor modelling ............................................................................................................................ 14 6.1. Rotor transfer function ......................................................................................................... 15 6.1.1. Building test rig ............................................................................................................. 15 6.1.2. Speed results ................................................................................................................. 15 6.2. Thrust constant (K)................................................................................................................ 16 6.3. Thrust to moment coefficient (d) estimation ....................................................................... 17 7. Moment of inertia ......................................................................................................................... 17 8. Simulink model.............................................................................................................................. 18 9. Linearization.................................................................................................................................. 22 10. Controller design ....................................................................................................................... 22 10.1. Height rate controller........................................................................................................ 22 10.2. Height controller ............................................................................................................... 23 10.3. Roll/pitch rate controller .................................................................................................. 24 10.4. Roll/pitch controller .......................................................................................................... 25 1 Kriban Govender 210512795 Final Report 10.5. Yaw rate controller ........................................................................................................... 26 10.6. Yaw controller ................................................................................................................... 26 11. Non Linear model verification .................................................................................................. 27 11.1. Simulink model with the control system .......................................................................... 27 11.2. Simulation results ............................................................................................................. 28 11.2.1. Roll and pitch output .................................................................................................... 28 11.2.2. Yaw output .................................................................................................................... 30 11.2.3. Height output ................................................................................................................ 31 12. Quadcopter block diagram ....................................................................................................... 32 13. Ground station block diagram .................................................................................................. 32 14. Hardware selection ................................................................................................................... 32 7.1 Frame .......................................................................................................................................... 32 7.2 Motors ......................................................................................................................................... 32 7.3 Propellers .................................................................................................................................... 32 7.4 ESC’s .......................................................................................................................................... 33 7.5 Battery ......................................................................................................................................... 33 7.6 Microcontroller ........................................................................................................................... 33 7.7 Sensors ........................................................................................................................................ 33 7.8 Transmitter and receiver ............................................................................................................. 33 7.11 Ground station........................................................................................................................... 34 15. Component List ......................................................................................................................... 34 16. Implementation ........................................................................................................................ 34 16.1. Construction of frame ....................................................................................................... 34 16.2. Place e t of 16.3. Placement of circuits ......................................................................................................... 35 16.4. Final Build .......................................................................................................................... 36 otors, propellers a d ESC’s ...................................................................... 35 17. Graphical User Interface ........................................................................................................... 36 18. Quadcopter Testing................................................................................................................... 37 18.1. Transceiver ........................................................................................................................ 37 18.2. Controller implementation ............................................................................................... 38 18.3. Roll and pitch testing ........................................................................................................ 38 18.4. Yaw rate testing ................................................................................................................ 38 19. Performance evaluation............................................................................................................ 39 20. Conclusion ................................................................................................................................. 40 20.1. Phase 1 .............................................................................................................................. 40 20.2. Phase 2 .............................................................................................................................. 40 2 Kriban Govender 210512795 Final Report 20.3. Final Phase ........................................................................................................................ 41 21. References ................................................................................................................................ 42 22. Appendix ................................................................................................................................... 43 22.1. Appendix A ........................................................................................................................ 43 22.2. Appendix B ........................................................................................................................ 43 22.3. Appendix C ........................................................................................................................ 44 22.4. Appendix D ........................................................................................................................ 44 22.5. Appendix E ........................................................................................................................ 45 22.6. Appendix F ........................................................................................................................ 46 22.7. Appendix G ........................................................................................................................ 48 22.8. Appendix H ........................................................................................................................ 51 22.9. Appendix I ......................................................................................................................... 52 22.10. Appendix J ......................................................................................................................... 58 22.11. Appendix K ........................................................................................................................ 60 22.12. Appendix L (ECSA Report) ................................................................................................. 61 3 Kriban Govender 210512795 Final Report List of symbols - Body frame – Navigation frame – Rotation matrix, navigational frame to the body frame � - Rotation matrix, body frame to the navigational frame – The Body fixed angular velocity to Euler rate matrix - Position vector [X Y Z] T – Position, x coordinate – Position, y coordinate – Position, z coordinate � - Angular rate of change vector [p q r] T p – Angular rate of change about Xb q - Angular rate of change about Yb r - Angular rate of change about Zb � – Psi, roll angle � – Theta, pitch angle – Phi, yaw angle 4 Kriban Govender 210512795 Final Report List of figures and tables Figure 1: Navigational and body coordinate system [3] ......................................................................... 8 Figure 2: Quadcopter movement [7] ...................................................................................................... 9 Figure 3: Building rotor test rig ............................................................................................................ 15 Figure 4: Graph showing the rotor speed2 ((rad/s) 2) vs time(s) response to maximum throttle input16 Figure 5: Simulink model of rotor ......................................................................................................... 16 Figure 6: Speed output of rotor model when 100% throttle is applied ............................................... 16 Figure 7: Quadcopter Simulink model .................................................................................................. 19 Figure 8: Quadcopter subsystem .......................................................................................................... 19 Figure 9: Quadcopter\commands subsystem ....................................................................................... 20 Figure 10: Quadcopter\Rotors subsystem ............................................................................................ 20 Figure 11: Quadcopter\sum of forces and sum of moments subsystem ............................................. 21 Figure 12: Quadcopter\Quadcopter dynamics subsystem ................................................................... 21 Figure 13: Root Locus Design, Left, (a) and Step Response, Right, (b) ................................................. 23 Figure 14: Root Locus Design, Left, (a) and Step Response, Right, (b) ................................................. 24 Figure 15: Root Locus Design, Left, (a) and Step Response, Right, (b) ................................................. 25 Figure 16: Root Locus Design, Left, (a) and Step Response, Right, (b) ................................................. 25 Figure 17: Root Locus Design, Left, (a) and Step Response, Right, (b) ................................................. 26 Figure 18: Root Locus Design, Left, (a) and Step Response, Right, (b) ................................................. 27 Figure 19: Simulation model with the control system .......................................................................... 27 Figure 20: Graph showing roll output response (rad) to an input step of 0.1 (rad) ............................. 28 Figure 21: Graph showing pitch output response (rad) to an input step of 0.1 (rad) .......................... 28 Figure 22: Graph showing roll disturbance rejection to a 0.1 (rad) step .............................................. 29 Figure 23: Graph showing pitch disturbance rejection to a 0.1 (rad) step ........................................... 29 Figure 24: Graph showing yaw output response (rad) to an input step of 0.1 (rad) ............................ 30 Figure 25: Graph showing yaw disturbance rejection to a 0.1 (rad) step............................................. 30 Figure 26: Graph showing height output response (m) to an input step of -1 (m) .............................. 31 Figure 27: Graph showing height disturbance rejection to a -1 (m) step ............................................. 31 Figure 28: block diagram of quadcopter system ................................................................................... 32 Figure 29: Block diagram of ground station ......................................................................................... 32 Figure 30: Quadcopter frame top view................................................................................................. 34 Figure 31: Quadcopter frame side view................................................................................................ 35 Figure 32: mounting rotors and ESC ..................................................................................................... 35 Figure 33: Centre Hub ........................................................................................................................... 35 Figure 34: Final Quadcopter Build ........................................................................................................ 36 Figure 35: GUI ....................................................................................................................................... 36 Figure 36: Transmitted test values ....................................................................................................... 37 Figure 37: Received test values............................................................................................................. 37 Figure 38: roll/pitch tracking (degrees vs time) .................................................................................... 38 Figure 39: Arduino Pin Out.................................................................................................................... 58 Figure 40: mpu6050 imu ....................................................................................................................... 58 Figure 41: 20A Skywalker ESC ............................................................................................................... 59 Figure 42: 1000Kv brushless motor ...................................................................................................... 59 5 Kriban Govender 210512795 Final Report Table 1: Table showing the different sample results ............................................................................ 17 Table 2: Table showing moment of inertia of the different components. ........................................... 18 Table 3: Table showing the component list .......................................................................................... 34 Table 1: Deadlines for reports and presentations ................................................................................ 60 Table 2: Timeline of specific tasks......................................................................................................... 60 6 Kriban Govender 210512795 Final Report 1. Introduction Quadcopters or multicopters are helicopters with four or more rotors that are capable of flight with two pairs of rotor blades rotating in opposite directions, but unlike a helicopter, all four blades are used to produce an upward thrust, and the weight of the quadcopter is divided amongst the four rotors. The quadcopter is advantageous over the conventional helicopter since the mechanical design is simpler [1]. By varying the thrust of each individual rotor, the movement of the quadcopter can be controlled [2]. The above mentioned design brings about a more stable platform than conventional helicopters, which makes it well suited for various commercial and military applications, such as, aerial photography, surveillance as well as search and rescue and search and destroy. Quadcopters also bring about a challenge in implementation, since minute adjustments must be made to each rotor in order for it to stay balanced and keep the entire craft level. It would prove to be very difficult for a person to manually make these adjustments; therefore the quadcopter needs to make these adjustments to the rotors autonomously. Therefore, a control system is needed to make the adjustments to the four rotors continuously [3], [4]. 2. Objectives The objectives for phase 2 are:         To understand the theory and functional aspects of a quadcopter To conduct a feasibility study To develop the quadcopter model using the set of differential equations describing the quadcopter dynamics To linearize the non-linear quadcopter model To design the rate controllers as well as the roll, pitch, yaw and height controllers for the quadcopter To implement and test the controllers on the non-linear quadcopter Simulink model To identify the components required for the project To implement the design 3. Specifications The project specifications include the design and building of a quadcopter. The quadcopter should be controlled with a remote controller. The design phase includes, obtaining the theory behind the kinematics and dynamics of a quadcopter, understanding what components are required for the quadcopter as well as understanding how to use the various sensors. The most important aspect of the design phase includes constructing the Simulink model of the quadcopter system as well as designing the controllers for the system. Thereafter the quadcopter needs to be built. 4. Theory 4.1. Coordinate systems The quadcopter has two frames of reference, one being the body frame, and the other being the navigation frame. It will be required to convert between these two frames of reference in order to create a model of the system. The body frame of reference is fixed to the quadcopter 7 Kriban Govender 210512795 Final Report frame, whereas the navigation frame coordinate system is fixed to the earth at the position where the quadcopter starts moving [5]. Figure 1: Navigational and body coordinate system [3] 4.2. Roll and Pitch In order for the quadcopter to roll or pitch, two adjacent motors need to spin faster than the two motors on the opposite side. If the two motors on the right or left of the quadcopter spin faster, it will cause the quadcopter to roll. If the two motors on the rear or front of the quadcopter spin faster it will cause the quadcopter to pitch. [6] 4.3. Yaw The yaw axis is a vertical axis through the aircraft, and it is more complex than controlling the pitch or roll. The quadcopter motor configuration is such that the adjacent motors spin in the opposite direction. This is to neutralize or eliminate the rotors influence to make the quadcopter rotate. Therefore, in order to rotate the quadcopter about the yaw axis, the opposite pair of rotors needs to be slower relative to the other pair to cause the quadcopter to rotate. [6] 4.4. Hovering/Altitude Control In order for the quadcopter to hover, the force of lift produced by the sum of the lift of the four motors must equal the force of gravity acting on the quadcopter. For the quadcopter to ascend or descend, the force balance needs to be disrupted, either making the force generated by the four motors greater than that of the gravitational force in order to make the quadcopter ascend, or making the force generated by the motor less than that of the gravitational force in order to make the quadcopter descend.[3] 8 Kriban Govender 210512795 Final Report 4.5. Quadcopter movement Figure 2: Quadcopter movement [7] 4.6. Quadcopter Dynamics There are two different methods to achieve dynamics of a quadcopter, either using Lagrangian equations or Newton’s law, but it is much easier to understand using Newton’s law. Since the Quadcopter is controlled by varying the rotational speed of the four rotors attached to it, the altitude, change in position and velocity is caused by the increase or decrease of the speed of the four propellers together. By varying the speed of the first and third of propeller, the aircraft will tilt about the ‘y’ axis, which represents the pitch angle theta “θ”. By varying the speed of the second and fourth propellers, the aircraft will tilt about the ‘x’ axis, which represents the roll angle phi “ϕ”. The vector summation of the reaction moment produced by the rotation of the first and third of propeller and the reaction moment produced by the rotation of the second and fourth propellers will cause the quadcopter to spin about the ‘z’ axis, which represents the yaw angle epsi “ψ” These are the six degrees of freedom of the system consisting of the position (x, y, z) and the orientation ϕ, θ, ψ. [3],[4] 9 Kriban Govender 210512795 Final Report 4.6.1. Rotation Matrix The rotational matrix is [8], [9]: CθCψ =[ − � + � � � + � � Where, � − � � + � � + � � − � � �] � � (1) C = cos and S = sin. The rotational matrix, , is used to make a total conversion from the body frame to the navigational frame and the transpose of the rotational matrix, conversion from the navigational frame to the body frame � , is used to make a total 4.6.2. Body fixed angular velocity to Euler rate matrix The Body fixed angular velocity to Euler rate matrix is [9]: � � � �/ � = [ Where, � � − � ] �/ � (2) C = cos, S = sin and T=tan The matrix is used to convert the body fixed angular rates of the quadcopter to the Euler rates of the quadcopter. 4.6.3. Forces In order to obtain the dynamic model of the quadcopter, the forces acting on the system need to be identified. The forces acting on the system include the motor thrust, gravity, drag, airflow and disturbance forces. Using Newton’s first law [9], [10]: � � 4.6.3.1. _ _ = . = −� ℎ + Thrust Force _ +� . � � = _ + � .[ � ]+ _ + � . [ ] � [ +� � ] (3) (4) The force of the propellers on the body frame will be perpendicular to the x and y axis of the body frame, therefore the thrust generated by the four rotors will form part of the z component only [10]. 10 Kriban Govender 210512795 Final Report �ℎ 4.6.3.2. _ =[ Gravity Force � +� +� ] +� (5) The force of gravity is acting in the positive z direction of the navigation frame. In order to calculate the force of gravitation in the body frame, the gravitational force vector of the navigational frame needs to be multiplied by the rotational matrix in equation (1) [10]. � 4.6.3.3. � = _ Drag Force � .� � _ = � . .[ The drag force is determined by the following equation [10]: = . �. � . � Where: ] . (6) . (7) � = Air density � = Velocity = Area = Drag coefficient When the quadcopter moves through air it will experience drag forces, the drag force acts opposite to the direction of motion of the quadcopter. The drag force is not included in the current model for simplicity. 4.6.3.4. Disturbance Forces such as Coriolis force from the earth and wind are considered as a disturbance, summarized as Fdisturbance. These forces will not be included in the model for simplicity [10]. 4.6.3.5. Airflow The airflow force is the resultant of the forces exerted by the airflow over the airframe and can be calculated using the following equation [8]: � Where: = � . � (8) � = Angular rate of change = velocity vector 4.6.4. Force equation Using Newton’s first law, the sum of the forces acting on the quadcopter was equated to the product of the mass of the system [8], [10]. . = −� ℎ Kriban Govender 210512795 � +� � � + � � 11 � + � � +� � (9) Final Report . .[ = −[ ] = −[ � � +� +� +� . � +� . [ ] +� +� [ ]+ � ]+ � . .[ . .[ ] . . ]+� � ]+� � _ + (10) _ + (11) 4.6.5. Acceleration 4.6.5.1. Body Frame By rearranging equation (11) and making the acceleration vector the subject of the formula, the acceleration of the quadcopter in the body frame can be determined and by the use of integration, the velocity in body frame can be determined [8], [10]. [ � 4.6.5.2. {− [ � +� +� ]+ +� [ ] � [ . .[ ] . ]+� � ]= }+ (12) Navigation Frame In order to obtain the acceleration of the quadcopter in the navigation or earth frame, the rotational matrix needs to be applied to the acceleration vector in body frame, which can be seen in equation (13) [8], [10]. [ ] = .[ ] (13) 4.6.6. Moments The forces acting on the system determine the moments about the various axis. The moments of the system can be described by the following equations [8], [10]: � � = �. �+�x �. ν = �ℎ 12 Kriban Govender 210512795 + � _� (14) � (15) Final Report Where: � = sum of the thrust moment and motor inertia moment. � = Quadcopter inertia � = angular velocity �= angular acceleration 4.6.6.1. Thrust Moment The thrust moments about the x, y and z axis is influenced by the thrust generated by the four rotors. The moment about the x and y axis is found by subtracting the forces generated by the rotors on the same axis and multiplying the result by the distance , which is the distance from the centre of the propeller to the centre of the quadcopter. The z moment is found by subtracting the total force generated by the counter clockwise spinning rotors from the force generated by the clockwise spinning rotors and multiplying the result by the constant d [8], [10]. �ℎ � = � � = � Where, � = � +� � � =[ ] � (16) . −� −� −� . −� (17) (18) . (19) = distance from the centre of the frame to the centre of the propeller. = constant which converts the thrust into moment. 4.6.6.2. Motor Inertia Moment The equation to calculate the motor inertia moment is [8]: � Where: _� � = x ν. � (20) = Angular speed of rotor ν = Angular speed � = Motor inertia This term can be ignored in the simulation, since the angular rate is small enough that it can be neglected. 4.6.7. Moment Equations 4.6.7.1. Body frame The total moment of the system can be calculate and equated as [8], [10]: 13 Kriban Govender 210512795 Final Report �ℎ +� _� = � .� + � x � .� � (21) By making the angular acceleration the subject, we get [8], [10]: � .� = � ℎ � = � − . [� ℎ Therefore, 4.6.7.2. [ ] = � − . [� ℎ Navigation frame +� _� +� +� � _� _� � − � x � .� (22) − � x � .� ] � (23) − � x � .� ] (24) To obtain the Euler rates of the quadcopter, the angular velocity of the quadcopter in the body frame is multiplied by the body fixed angular velocity to Euler rate matrix which is shown below [9]: � [� ] = .[ ] (25) The Euler angles can thereafter be obtained by integration. 5. Commands There are four inputs to the quadcopter system, which are the inputs to the four rotors. In order to cause the quadcopter to roll, pitch and yaw the current system inputs need to be mapped to a roll, pitch and yaw as well a height input. To obtain the desired input to the four rotors, the following set of equations were created: ℎ ℎ [ ℎ ℎ _ _ _ _ � � � � ]=[ − ℎ ��ℎ _� _� − ][ − � ℎ_� − _� ] (26) The four inputs of the system will now become roll, pitch, yaw and height. These four inputs will control the desired throttle for rotor 1 to 4. 6. Rotor modelling In order to obtain the rotor model, the system identification toolbox was used on Matlab. This option was chosen because it could accurately determine the transfer function for the motor and propeller combination. Two Arduino mini pro microcontrollers where used to obtain the speed output of the system. One microcontroller was used to provide the pwm pulse that was needed to by the brushless electronic speed controller to drive the motor, and the second microcontroller was used to capture the speed of the rotor by counting the interrupts caused by the infrared gap sensor. 14 Kriban Govender 210512795 Final Report The number of interrupts where sampled every 0.15s, and was sent to Matlab via serial communication. The Arduino code as well as the Matlab code that was used to obtain the test results can be seen in appendix A to C 6.1. Rotor transfer function 6.1.1. Building test rig A test rig was built in order to accurately capture the motor and propeller speed. The motor and propeller was mounted onto an aluminium beam with the gap sensor attached to the beam as well. A circular piece of cardboard with four piecs of its edge cut off was used to create the interrupt mechanism that would trigger the gap sensor. Therefore, four interrupts would infer that one revolution has completed. Figure 3: Building rotor test rig Equation (27) was used to convert the data obtained from the Arduino microcontroller to speed in rad/s by using the following information:   Sample time = 0.15s Number of interrupts per revolution: 4 / = � . ∗ ∗ ∗ � (27) Therafter, the speed needed to be converted to speed squared since the transfer function required in the simulation is from throttle percentage to speed squared. =( � . ∗ ∗ ∗ � ) (28) 6.1.2. Speed results The maximum throttle command was sent to the Arduino microcontroller and the following results were obtained. 15 Kriban Govender 210512795 Final Report 2 2 Figure 4: Graph showing the rotor speed ((rad/s) ) vs time(s) response to maximum throttle input Using the above data in the System Identification Toolbox of Matlab, the following transfer function was obtained. = . . ∗ + 5 = ℎ 2 % (29) The transfer function that was obtained was then modelled on Simulink to test its response. The model of the rotors can be seen in figure 5. Figure 5: Simulink model of rotor Figure 6 shows the response of the rotor system when 100% throttle is applied to the input. When compared to the actual data obtained in Matlab, it is seen that the output of the transfer function does reach the maximum output after 1 second. Therefore, the transfer function obtained will be sufficient to model the rotors. Figure 6: Speed output of rotor model when 100% throttle is applied 6.2. Thrust constant (K) The thrust constant, K, is used to convert the speed the rotors into thrust. The relationship between speed and thrust is seen in equation (30) [11]. Kriban Govender 210512795 ℎ = �. 16 (30) Final Report �= �ℎ � �2 (31) / In order to obtain the force generated by the rotors, the propellers where reversed and placed on a scale. Three different samples of thrust generated and rotor speed were then recorded and tabulated below. Table 1: Table showing the different sample results Sample 1 Sample 2 Sample 3 2.119 3.483 6.112 Thrust(N) 523.6 674.2 880.7 Speed(rad/s) 7.73*10-6 7.66*10-6 7.88*10-6 K Table 1 shows the thrust, speed and thrust constant K that was calculated for the three samples. The values obtained for each sample are similar and proves equation (30) to be correct. The average of the 3 values was taken as the thrust constant, 6.3. �= . ∗ − + . − ∗ + . ∗ − Thrust to moment coefficient (d) estimation = . ∗ − Due to the lack of measurement devices, an accurate drag coefficient is difficult to obtain. From various sources, it is seen that the drag coefficient can vary from ∗ − to ∗ − , therefore a test value of ∗ − was chosen to be used in the simulation. The drag coefficient will only effect the yaw moment of the simulation and the gain of the yaw rate controller can be adjusted accordingly during implementation and testing [8], [12], [13]. The value of b is then obtained by dividing the drag coefficient by the thrust coefficient K. = ∗ 7. Moment of inertia � − = . ∗ ∗ − − = . Assuming quadcopter is symmetrical, the quadcopter inertia matrix will only contain the x, y and z components [8]. �=[ � � � ] (32) The standard formulae were used to calculate the moment of inertia according to the shape of the component. Rod and Cylinder rotating about centre [14]: � , , = + Where m is the mass, is the length, and r is the radius Plate rotating about the centre and shifted axis [14]: 17 Kriban Govender 210512795 (33) Final Report � , , = + ℎ (34) Where m is the mass, a is the perpendicular length and h is the distance away from the required axis. Cylinder (shifted axis) [14]: � / = � , , + + ℎ (35) Where, m is the mass, is the height of the rod and h is the distance away from the required axis. Cuboid shifted axis [14]: = + + ℎ (36) Where m is the mass, a and c are the dimensions perpendicular to the axis and h is the distance away from the required axis. Table 2: Table showing moment of inertia of the different components. Component Shape on axis x,y,z Rotors =cylinder x,y=Rod+cy Arms linder z=rod Centre hub Square plate plate ESC Battery cuboid Dimensions mass 4 * 52g Ix (Kg.m2) 0.004608 Iy (Kg.m2) 0.004608 Iz (Kg.m2) 0.009104 = 22mm r = 14mm =462mm r =4mm 4 * 22g 0.000812 0.000812 0.001628 a =90mm a = 24mm h =126.5mm Length = 105mm Breadth=32mm Height=21mm 42g 22 * 4g 0.000028 0.000794 0.000028 0.000794 0.000057 0.000354 172g 0.000183 0.000040 0.000192 The total moment of inertia of the system is [8]: �=� +� +� ℎ +� � +� =[ 8. Simulink model . . . ] ��. The following model seen in figure 7 shows the quadcopter Simulink model of the non-linear system. There are four inputs which are ‘delta_phi’, ‘delta_theta’, ‘delta_psi’ and ‘delta_h’. The model also has four outputs which are ‘X’, which is a position vector that contains the current x, y and z coordinates of the quadcopter, ‘X dot’, which is a velocity vector that contains the current x, y and z velocity of the quadcopter, ‘phi theta psi’, which contain the roll pitch and yaw angles and ‘phi theta psi dot’ which contain the roll pitch and yaw rates. 18 Kriban Govender 210512795 Final Report Figure 7: Quadcopter Simulink model The quadcopter subsystem seen in figure 8 contains four other subsystem, the ‘commands’, ‘Rotors’, ‘sum of force and sum of moments’ and quadcopter dynamics subsystem. The system was split up to better understand the different aspects of the quadcopter system. The total mass of the system is needed in the simulation, the mass was estimated to be a total of 750g after adding the weights of the different components that will make up the system. Figure 8: Quadcopter subsystem The commands system seen in figure 9 is used to control the height, roll, pitch and yaw of the quadcopter. The height, roll, pitch and yaw inputs are converted into the system throttle input by using summers to implement equation (26) . 19 Kriban Govender 210512795 Final Report Figure 9: Quadcopter\commands subsystem Figure 10 shows the implementation of the quadcopter rotors, where saturation and gain are implemented in the rotor subsystem. Saturation is introduced in order to limit the rotor input to a minimum value of 0 and a maximum value of 100. The input value is then multiplied by a gain of 0.01 to convert the input to a percentage. Figure 10: Quadcopter\Rotors subsystem The ‘sum of forces and sum of moments’ subsystem, which is seen in figure 11, is used to convert the angular velocity of the rotor outputs into a force and moment vector. The angular velocity is firstly converted into thrust by multiplying the angular velocity by the thrust constant K, and thereafter it is converted to a force and moment vector, as seen in the subsystem. 20 Kriban Govender 210512795 Final Report Figure 11: Quadcopter\sum of forces and sum of moments subsystem The ‘quadcopter dynamics’ subsystem, seen in figure 12, converts the quadcopters forces and moments into the Euler angles and rates as well as the position vector and velocity vector of the quadcopter. Figure 12: Quadcopter\Quadcopter dynamics subsystem 21 Kriban Govender 210512795 Final Report 9. Linearization To control the various outputs of the system, a linear model, about the operating state, had to be obtained of the quadcopter system. The quadcopter system will be linearized using the state space approach. Equation (37) and (38) form the state space equations [15]. = + = + (37) (38) Where A is the state matrix, B is the input matrix, C is the output matrix and D is the direct transmission matrix. In order to obtain the matrices A, B, C and D, The ‘linmod ()’ function was used on the quadcopters Simulink model with four inputs and four outputs. Thereafter, the multipleinput-multiple-output system was converted to four single-input-single-output systems to be able to design the controllers. The Matlab code, as well as the state space model, can be seen in appendix D to F. 10. Controller design The chosen type of controller to be used is a proportional controller. A proportional controller was chosen instead of a PI or PID since it will allow for a smaller sampling time since there are eight controllers to implement on a single microcontroller. The choice of controller may change later on in the design during the testing phase of the quadcopter. This will depend on the flight stability of the quadcopter. Sisotool was used in order to design the controllers for the linear system. The rate controllers were designed and applied to the non-linear model, thereafter, the system was linearized again in order to design the controllers for height, roll, pitch and yaw. 10.1. Height rate controller The height controller forms the inner loop of the control system. Design specifications: Settling time: < 4s Damping ratio: 0.7 22 Kriban Govender 210512795 Final Report Figure 13: Root Locus Design, Left, (a) and Step Response, Right, (b) The Sisotool root locus design interface was used to design the controller. The design specifications was placed onto the root locus plot of the system which can be seen in figure 13(a) and the poles of the system was adjusted to meet the design requirements for the damping ratio of 0.7 and settling time. The step response of the system can be seen in figure 13(b). From the step response it can be seen that the settling time is less than 4 seconds which complies with the design requirements. The following controller was obtained: 10.2. Height controller =− . The height controller forms the outer loop of the control system. Design specifications: Settling time: < 6s Damping ratio: 0.6 23 Kriban Govender 210512795 Final Report Figure 14: Root Locus Design, Left, (a) and Step Response, Right, (b) The design specifications of the height controller vary from the height rate controller because the inner loop needs to be faster than the outer loop. In figure 14(a), the design specifications for damping and settling time can be seen on root locus plot, the poles of the system where shifted accordingly to meet the specifications, as before. The step response, seen in figure 14(b), shows that the system height output has a settling time of less than 6 seconds which meets the design specifications. The following controller was obtained: 10.3. Roll/pitch rate controller = . The quadcopter is symmetrical about its x and y axis therefore the same rate controller will be used to control the roll and pitch rate of the quadcopter. The roll/pitch rate controller forms the inner loop of the control system. Design specifications: Settling time: < 4s Damping ratio: 0.7 24 Kriban Govender 210512795 Final Report Figure 15: Root Locus Design, Left, (a) and Step Response, Right, (b) The same process as before was followed and Figure 15(a) shows the root locus plot of the systems roll and pitch with the design specifications for the rate controller. The step response of the system is seen in Figure 15(b) showing that the system has a settling time of less than 4 seconds. The following controller was obtained: 10.4. Roll/pitch controller = . The roll/pitch rate controller forms the outer loop of the control system. Design specifications: Settling time: < 6s Damping ratio: 0.6 Figure 16: Root Locus Design, Left, (a) and Step Response, Right, (b) 25 Kriban Govender 210512795 Final Report Figure 16(a) shows the root locus plot for the roll and pitch which meets the design specifications, and as before, and the settling time of the step response seen in figure 16(b) is less than 6 seconds. The following controller was obtained: 10.5. Yaw rate controller = . The roll/pitch rate controller forms the inner loop of the control system. Design specifications: Settling time: < 4s Damping ratio: 0.7 Figure 17: Root Locus Design, Left, (a) and Step Response, Right, (b) Figure 17(a) shows the root locus plot for the yaw rate which meets the design specifications, and the settling time of the step response seen in figure 17(b) is less than 4 seconds. The following controller was obtained: 10.6. Yaw controller = . The roll/pitch rate controller forms the outer loop of the control system. Design specifications: Settling time: < 6s Damping ratio: 0.5 26 Kriban Govender 210512795 Final Report Figure 18: Root Locus Design, Left, (a) and Step Response, Right, (b) Figure 18(a) shows the root locus plot for the yaw which meets the design specifications, and the settling time of the step response seen in figure 18(b) is less than 6 seconds. The following controller was obtained: 11. = . Non Linear model verification 11.1. Simulink model with the control system The Simulink model shown below consists of the quadcopter model with the controllers that were previously designed, added to the system. A total of eight controllers where designed since four are required to control the system rates and four are required to control the roll, pitch, yaw and height of the quadcopter. Figure 19: Simulation model with the control system 27 Kriban Govender 210512795 Final Report 11.2. Simulation results The quadcopter Simulink model in figure 19 was simulated and an input step was applied to the roll, pitch, yaw and height inputs of the system. The results of the simulation can be seen below. 11.2.1. Roll and pitch output A step of 0.1 radians was applied to the roll and pitch input of the Simulink model separately and the following outputs was obtained. The same controller was applied to control the roll and pitch of the system. Figure 20: Graph showing roll output response (rad) to an input step of 0.1 (rad) Figure 21: Graph showing pitch output response (rad) to an input step of 0.1 (rad) From figure 20 and 21, it can be seen that the output is able to track the input, and the output settles in approximately 6 seconds. 28 Kriban Govender 210512795 Final Report A disturbance was thereafter introduced into the system. Figure 22: Graph showing roll disturbance rejection to a 0.1 (rad) step Figure 23: Graph showing pitch disturbance rejection to a 0.1 (rad) step From figure 22 and 23, the control system for roll and pitch is able to completely reject the disturbance in under 5 seconds. 29 Kriban Govender 210512795 Final Report 11.2.2. Yaw output A step of 0.1 radians was applied to the yaw input of the Simulink model and the following output was obtained. Figure 24: Graph showing yaw output response (rad) to an input step of 0.1 (rad) From figure 24, it is seen that the output is able to track the input as before. And the output settles in approximately 6 seconds. Figure 25: Graph showing yaw disturbance rejection to a 0.1 (rad) step Similarly to the roll and pitch disturbance rejection results, the yaw control system is able to completely reject the disturbance from the output in under 5 seconds, which is seen in figure 25. 30 Kriban Govender 210512795 Final Report 11.2.3. Height output A step of 1 metre was applied to the height input of the Simulink model and the following output was obtained. Figure 26: Graph showing height output response (m) to an input step of -1 (m) Figure 26 shows the system height response to a negative 1 meter step input. There is an initial spike in the height output , this is due to the rotors transfer function, since the rotors need to speed up to provide enough thrust to counteract the force of gravity which is pulling the quadcopter down. The rotors are able to produce enough force to counteract the force of gravity in under 5 seconds, and the quadcopter is now in hover mode. The height output is able to track the height input of the system and settles in approximately 6 seconds. Figure 27: Graph showing height disturbance rejection to a -1 (m) step Figure 27 shows the disturbance rejection of the results of the system. The controller successfully removes the disturbance seen in the output of the system. The initial spike is due to the effects of gravity and the rotor transfer function was explained earlier. 31 Kriban Govender 210512795 Final Report 12. Quadcopter block diagram The quadcopter implementation block diagram is shown below: Figure 28: block diagram of quadcopter system 13. Ground station block diagram The quadcopter ground station block diagram is shown below: Figure 29: Block diagram of ground station 14. Hardware selection 7.1 Frame The frame is one of the most important parts of the quadcopter since it supports all the electronics such as the sensors and control board as well as the motors. The frame needs to be rigid and strong but also light weight. The frame is commonly made of wood, aluminium, and carbon fibre or glass fibre. Aluminium was chosen to construct the frame since it is rigid and light weight. 7.2 Motors Four motors are required for the quadcopter; brushless DC motors will be used since it is lighter in weight and has a higher efficiency than brushed DC motors. 1000kv motors were chosen for the quadcopter, a lower a kv rating implies that the motor is able to produce a higher torque and therefore larger propellers can be used to produce the lift force. 7.3 Propellers Four propellers are required, one for each motor. Two of the four propellers need to clockwise propellers (CW) and the other two counter-clockwise propellers. The propeller length and pitch need to be taken into consideration since these effects the quad copters movement as well as its response time. A good balance between pitch and length needs to be found, a propeller with a higher pitch moves a larger volume of air and the quadcopter could experience turbulence. It is also noted that an increase in propeller length will increase 32 Kriban Govender 210512795 Final Report propeller efficiency. Also a smaller propeller is easier to speed up when compared to larger propellers. For large quadcopters, large propellers are recommended with a low kv rated motor. 8x4.5 propellers where chosen for the quadcopter. During the tests conducted it seen that these propellers produced sufficient thrust to lift up the quadcopter. [3] 7.4 ESC’s The electronic speed controller (ESC) is a device that controls the speed of the brushless motors with a pwm (pulse width modulation) input signal. Four ESC’s are required for the quadcopter, one for each motor. ESC’s with a high bit resolution will help improve flight stabilization since it will be more accurately respond to the minute changes. 20A ESC’s where chosen since to meet the specifications of the motor since the motors can draw up to 17A at full load. 7.5 Battery A Lithium Polymer battery will be used to power the quadcopter since it has a high power to weight ratio. The size and capacity of the battery will be chosen depending on the weight of the quadcopter and the rating of the motors. A 2200mah 25C lipo batter was chosen which contributes a total of 170g to the quadcopter mass. 7.6 Microcontroller The microcontroller chosen for the project needs to have a minimum of four pwm pins to connect to the ESC’s, it also needs to be able to interface with the various sensors and wireless module that will be used to control the quadcopter. The processing power of the microcontroller is also very important since complex equations and algorithms will need to be processed and adjustments made to the speed of the motors. A second microcontroller was also used to connect the transceiver to the master controller in order to free up the master microcontroller to perform other tasks 7.7 Sensors Two sensors will be used to control and stabilize the quadcopter, an accelerometer and a gyro. A 3 axis accelerometer is used to measure acceleration and can be used to deduce the orientation of a stationary object. A gyro is used to measure the rotation of an object around a particular axis. A combination of the two alone is sufficient to control the orientation of the quadcopter. The MPU6050 imu was chosen, the chosen sensor contains both an accelerometer and gyro as well as a digital motion processor which converts the accelerometer and gyro readings into an orientation. [4] [5] 7.8 Transmitter and receiver Two wireless transceivers will be required for wireless transmission and controlling the quadcopter. One transceiver module will be interfaced with the on board microcontroller on the quadcopter as and another will be linked to the laptop to transmit and receive commands. The transceiver modules need to have a high bitrate in order to control various aspects of the quadcopter. A transceiver range of less than 200m will suffice for testing purposes. 2.4GHz NRF24L01 transceiver modules where used for communication, the chosen transceiver uses the SPI bus of the microcontroller. 33 Kriban Govender 210512795 Final Report 7.11 Ground station The ground station consists of a laptop which will be connected to a wireless transceiver. A graphical user interface will be developed to obtain the input from the remote controller and transmit the appropriate commands to the quadcopter wirelessly. 15. Component List The total cost for the project was estimated to be R4000 during the feasibility study. After conducting further research and the purchasing of components, the total cost is now R3 621. The cost of the project is more than the allocated amount of R800 and is self-funded. Table 3: Table showing the component list Components Arduino mini pro (Atmega328) 3 axis accelerometer + 3 axis gyroscope mpu6050 1000Kv brushless motor + 20A skywalker brushless ESC 8 x 45 propellers Aluminium beam 2m 2.4GHz NRF24L01 transceiver module 2200mAh Lipo battery 3.3V voltage regulators Ultrasonic distance sensor Quantity 3 2 4 4 1 2 1 2 1 Total 16. Unit Price R80 R95 R275 R16 R65 R195 R320 R7 R35 R2418 Implementation 16.1. Construction of frame The quadcopter frame was constructed from aluminium beams as well as aluminium plates. The design of the frame can be seen in figure 30 and 31. The frame consists of four arms as well as a centre hub and battery holder. The length of the arms is 229mm each to allow enough space for the propellers and motors to fit. Figure 30: Quadcopter frame top view 34 Kriban Govender 210512795 Final Report Figure 31: Quadcopter frame side view The quadcopter frame contributes approximately 180g to the total mass. 16.2. Place e t of otors, propellers a d ESC’s The motors where attached to the ends of the arms on the quadcopter and secured with bolts. The ESC’s where then mounted below the propellers for efficient cooling. Figure 32: mounting rotors and ESC 16.3. Placement of circuits The arduino microcontrollers, sensor, as well as the transmitters where mounted to the centre hub of the quadcopter. The Centre hub of the quadcopter containing the sensors, microcontrollers as well as transmitters can be seen in Figure 33. Figure 33: Centre Hub 35 Kriban Govender 210512795 Final Report 16.4. Final Build Figure 34 shows a picture of the quadcopter after mounting and wiring the various components. Details about the sensors and components used can be seen in the appendix. Figure 34: Final Quadcopter Build 17. Graphical User Interface A graphical user interface is required to control the quadcopter as well as to tune the PID controller that is used to stabilize the quadcopter. Visual basic was used to create the quadcopter GUI, seen in figure 35, the GUI allows the user to select the serial com ports necessary to communicate with the microcontroller and allow for debugging. The proportional and integral constants for the quadcopters PID controllers can be adjusted by entering the desired values in the appropriate fields and thereafter clicking update. The commands from the joystick can be seen on the top right corner of the GUI. Figure 35: GUI 36 Kriban Govender 210512795 Final Report 18. Quadcopter Testing 18.1. Transceiver The 2.4GHz NRF24L01 transceiver module was connected to two separate microcontrollers, one at the ground station and the other on the quadcopter. Commands are sent from the GUI to the microcontroller at the ground station, and are thereafter transmitted to the quadcopters transceiver. The commands received by the transceivers microcontroller are then sent via the I2C bus to the master microcontroller. The arduino code for the transceivers can be seen in Appendix G and H. Figure 36: Transmitted test values Figure 37: Received test values Figure 36 shows the values being transmitted on COM5 and displays the word “sent” when data is successfully transmitted. Figure 37 show that the receiver on COM17 is working properly since all the data is received. 37 Kriban Govender 210512795 Final Report 18.2. Controller implementation From the eight controllers that were designed, only 5 where implemented which are the roll, roll rate, pitch, pitch rate and yaw rate controllers. These 5 controllers where implemented since these are the most important in order for the quadcopter to take flight. The yaw controller isn’t necessary because the yaw rate controller is sufficient to rotate the quadcopter about the z axis. The height and height rate controller is replaced by finding the hover throttle value. 18.3. Roll and pitch testing When testing the quadcopter roll, the pitch axis was fixed. The controller was then set using the GUI. Figure 38: roll/pitch tracking (degrees vs time) From figure 38, it can be seen that the output is able to track the input, but the output contains noise that varies from 3 to 5 degrees. 18.4. Yaw rate testing The yaw rate controller was implemented and needed to be tuned, it was seen that the yaw controller was able to counter the resultant torque generated by the propellers and stabilize the quadcopter about the z axis 38 Kriban Govender 210512795 Final Report 19.      Performance evaluation The GUI was successfully programmed and is able to connect to a USB joystick and capture the users input, the GUI is also able to connect to an arduino microcontroller to relay commands as well as PID controller values for tuning The transceivers used for communication prove to be functioning properly, a commands array containing 20 values is sent to the quadcopter master controller every 20ms. There are two arduino microcontrollers on the quadcopter, one being the master and the other being the slave. The slave microcontroller receives the commands from the transceiver and thereafter sends these commands to the master via the I2C bus. Currently the roll and pitch axis of the quadcopter is able to stabilise individually, also, the yaw rate controller performed as expected when the motors where running at a low rpm. When both the roll and pitch controllers are activated, the system is able to hold altitude effectively. 39 Kriban Govender 210512795 Final Report 20. Conclusion 20.1. Phase 1 For the project, the theory behind the flight of the quadcopter was researched and a better understanding of the quadcopter dynamics was obtained. Various aspects of the project was identified and grouped into different systems to work on. The components required to build the quadcopter was identified and well researched. A high level block diagram was drawn to show how the on-board quadcopter system would function, as well as how it would communicate with the ground station. A high level block diagram of the ground station was drawn to show how the remote controller and head tracking unit will interface with the laptop as well as communicate with the quadcopter. The head tracking unit is an extra feature and will be implemented if there is sufficient time. 20.2. Phase 2 The differential equations for the quadcopter system was obtained, and with these equations the quadcopter dynamics system was modelled. In order to complete the model, various other calculations and tests needed to be carried out. Firstly, the rotor model was needed, it was difficult to model the rotors using the dc motor equations since inductance and resistance as well as other constants where not known, therefore a test rig was built to obtain the response of the rotors, the data obtained was then entered into the system identification toolbox in Matlab and the rotor transfer function was obtained. The inertia of the quadcopter was also required for the simulation, the estimated inertia of the system was then calculated using the mass and position of the components that made up the bulk of the quadcopter. After the complete Simulink model was obtained, the system was then linearized so that the controllers could be designed. Eight controllers were then successfully designed to control the desired outputs of the system. These controllers were then implemented in the non-linear Simulink model. The complete Simulink model with the control system was then simulated, the results obtained from the simulation outputs of the system where stable and showed that the designed controllers operated as designed and met all specifications. The sensor noise (accelerometer and gyro) and filters such as the complementary and kalman filter was not included in the simulation since the chosen sensor has an on-board digital motion processor (dmp) which is capable of performing the task of sensor output fusion as well as noise rejection. 40 Kriban Govender 210512795 Final Report 20.3. Final Phase The required components were obtained and the quadcopter design was implemented. The roll, roll rate, pitch and pitch rate controllers where firstly implemented on an arduino microcontroller and tested. The results obtained showed that the controller had to be tuned, and was done so accordingly, after tuning the results obtained showed that the output was able to track the reference with some noise in the system. After enabling both the roll and pitch controllers simultaneously, the system tends to become slightly unstable but is able to hold altitude effectively. 41 Kriban Govender 210512795 Final Report 21. References 1. Gao, Y. (2013, December 23). What Makes The Quadcopter Design So Great For Small Drones? Retrieved from www.forbes.com/: http://www.forbes.com/sites/quora/2013/12/23/what-makes-the-quadcopter-design-sogreat-for-small-drones/ 2. HIP Program. (n.d.). Autonomously-Stabilized Quadcopter. Retrieved www.thomasteisberg.com: http://www.thomasteisberg.com/quadcopter/ from 3. Hossein Bolandi, M. R. (2013). Attitude Control of a Quadrotor with Optimized PID Controller. Intelligent Control and Automation, 335-342. 4. A. Y. Elruby, M. M.-k.-A. (n.d.). DYNAMIC MODELING AND CONTROL OF QUADROTOR VEHICLE. Egypt: Arab Academy for Science and Technology. 5. Ch elař, P. . BUILDING AND CONTROLLING THE QUADROCOPTER. Pardubice, Czech Republic: University of Pardubice. 6. Hatfield, S. (2014, April 29). The Physics of Quadcopter Flight. Retrieved July 2014, from http://blacktieaerial.com/: http://blacktieaerial.com/2014/04/29/the-physics-ofquadcopter-flight/ 7. S.SANTHOSH, G. (2014, February 14). MULTI-PURPOSE UNMANNED AREIAL VECHICLE WITH TEMPERATURE SENSING ALGORITHM AND AERIAL VIDEO FEEDING. Retrieved July 2014, from http://www.vidhyodaya.com/: http://www.vidhyodaya.com/papers/aerial-vehiclessanthosh-gsundeep-prince-sri-venkateshwara-college-of-engineering 8. Jiinec, T. (2011). Stabilization and Control of Unmanned Quadcopter. Prague: Czech Technical University. 9. Domingues, J. M. (2009). Quadrotor prototype. Lisbon, Portugal: Technical University of Lisbon. 10. Øyvind Magnussen, K. E. (2011). Modeling, Design and Experimental Study for a Quadcopter System Construction. Kristiansand and Grimstad, Norway: University of Agder. 11. Berry, D. C. (2011). INVESTIGATIONS IN THE CONTROL OF A FOUR-ROTOR AERIAL ROBOT. Indiana: Rose-Hulman Institute of Technology. 12. Luukkonen, T. (2011). Modelling and control of quadcopter. Espoo: Aalto University. 13. Jean-Baptiste Devaud, S. N. (2012). Full design of a low-cost quadrotor UAV by student team. Paris, France: ICSET. 14. W. Fowler, A. Bedford, Engineering mechanics: Statics, Edinburgh Gate: Pearson, 2012. 15. Ogata, K. (1997). Modern Control Engineering, Third Edition. New Jersey: Prentice Hall. 16. Cheng, Y. (2014, May 30). Arduino Serial Data Acquisition. Retrieved from www.mathworks.com: http://www.mathworks.com/matlabcentral/fileexchange/46775arduino-serial-data-acquisition 42 Kriban Govender 210512795 Final Report 22. Appendix 22.1. Appendix A void sendCount() { Serial.write(counter); counter=0; } void count() { counter++; } #include <TimerOne.h> int counter=0; void setup() { attachInterrupt(0, count, FALLING); Serial.begin(115200); Timer1.initialize(150000); Timer1.attachInterrupt(sendCount); } void loop() { } 22.2. Appendix B case '2': analogWrite(pin, 120); p=20; break; case '3': analogWrite(pin, 130); p=30; break; case '4': analogWrite(pin, 140); p=40; break; case '5': analogWrite(pin, 150); p=50; break; case '6': analogWrite(pin, 160); p=60; break; case '7': analogWrite(pin, 170); p=70; break; case '8': analogWrite(pin, 180); p=80; break; case '9': analogWrite(pin, 190); p=90; break; case 'a': analogWrite(pin, 200); p=100; break; int armingTime; int pin = 9; int p = 0; int pulseTime = 1100; //microseconds boolean highSpeed = true; void setup(){ //Start serial communication Serial.begin(9600); //Set pin 9 to output pinMode(pin, OUTPUT); analogWrite(pin, 90); delay(500); Serial.println("Enter 0-9 to adjust motor speed."); } void loop(){ while(Serial.available() > 0){ readSerialVal(); //Lets user know current throttle percentage if(Serial.available() == 0){ Serial.print("Throttle percentage: "); Serial.print(p); Serial.println("%"); } } } //read serial and set pwm void readSerialVal(){ switch (Serial.read()) { case '0': analogWrite(pin, 100); p=0; break; case '1': analogWrite(pin, 110); p=10; break; } } 43 Kriban Govender 210512795 Final Report 22.3. Appendix C [16] tic % Start timer while toc <= Tmax i = i + 1; %% Read buffer data data(i) = fread(s); %% Read time stamp % If reading faster than sampling rate, force sampling time. % If reading slower than sampling rate, nothing can be done. Consider % decreasing the set sampling time Ts t(i) = toc; if i > 1 T = toc - t(i-1); while T < Ts T = toc - t(i-1); end end t(i) = toc; %% Plot live data if i > 1 line([t(i-1) t(i)],[data(i-1) data(i)]) drawnow end end fclose(s); % Copyright 2014 The MathWorks, Inc. clc clear %% Create serial object for Arduino s = serial('COM5', 'BaudRate', 115200); % change the COM Port number as needed %% Connect the serial port to Arduino s.InputBufferSize = 1; % read only one byte every time try fopen(s); catch err fclose(instrfind); error('Make sure you select the correct COM Port where the Arduino is connected.'); end %% Create a figure window to monitor the live data Tmax = 15; % Total time for data collection (s) figure, grid on, xlabel ('Time (s)'), ylabel('Data (8bit)'), axis([0 Tmax+1 -10 300]), %% Read and plot the data from Arduino Ts = 0.02; % Sampling time (s) i = 0; data = 0; t = 0; 22.4. Appendix D %rate controller [A,B,C,D]=linmod('quad_model') sys=ss(A,B,C,D) gensys=genss(sys) %hdot sisotool(gensys(8,4)) %phi_dot sisotool(gensys(4,1)) %theta_dot sisotool(gensys(5,2)) %psi_dot sisotool(gensys(6,3)) %roll,pitch,yaw,height controller [A,B,C,D]=linmod('quad_model2') sys=ss(A,B,C,D) gensys=genss(sys) %h sisotool(gensys(7,4)) %phi sisotool(gensys(1,1)) %theta sisotool(gensys(2,2)) %psi sisotool(gensys(3,3)) 44 Kriban Govender 210512795 Final Report 22.5. Appendix E Linearized model to design rate controllers: A= 0 0 0 0 0 0 0 0 0 0 -9.81 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9.81 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 591.88 77.25 0 0 0 0 0 -27.73 -3.43 0 0 0 0 0 0 0 -591.88 77.25 0 0 0 0 0 -27.73 0 -3.43 0 0 B= 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.01 -0.01 0 0 0 0 0 0 0 0 0 0 0 0 0.01 -0.01 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.01 0.01 -0.01 -0.01 45 Kriban Govender 210512795 0 0 0 0 0 0 0 0 0 0 0 0 0.01 0.01 0.01 0.01 0 0 0 591.88 0 -77.25 0 0 0 0 0 -27.73 0 0 -3.43 0 0 0 0 -591.88 0 -77.25 0 0 0 0 0 -27.73 0 0 0 -3.43 Final Report C= 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 D= 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22.6. Appendix F Linearized model after the rate controllers were applied to the system. This was used to design the actual role, pitch, yaw and height controller. A= 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9.8 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 46 Kriban Govender 210512795 0 0 0 0 0 0 0 0 0 59 591 1.8 .88 8 0 0 0 1 0 591 591 .88 .88 0 77. 77. 77. 25 25 25 0 0 0 0 0 0 0 0 0 0 77. 25 0 0 0 0 0 0 0 0 0 0 0 0 0 Final Report 9.8 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.0 033 857 0 0 0.0 128 56 0 0.0 0.0 033 128 857 56 0 0 0.0 033 857 0 0.0 033 857 0 0 0 0 0.0 128 56 0 0.0 128 56 0 0 0 0 0 0 0 27. 73 27. 73 27. 73 27. 73 0 0 0 0.0 356 3.4 55 3 0 0 0 0 0.0 356 55 0 3.4 3 0 0 0 3.4 3 0 0 0 3.4 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.0 356 55 0 0.0 356 55 0 B= 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.0033857 -0.0033857 0 0 0 0 0 0 0 0 0 0 0 0 0.0033857 -0.0033857 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.012856 0.012856 -0.012856 -0.012856 0 0 0 0 0 0 0 0 0 0 0 0 -0.035655 -0.035655 -0.035655 -0.035655 C= 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 47 Kriban Govender 210512795 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Final Report 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 D= 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22.7. Appendix G Transmitter and head tracking unit code #include "I2Cdev.h" #include "MPU6050_6Axis_MotionApps20.h" #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE #include "Wire.h" #endif MPU6050 mpu; uint8_t mpuIntStatus; // holds actual interrupt status byte from MPU uint8_t devStatus; // return status after each device operation (0 = success, !0 = error) uint16_t packetSize; // expected DMP packet size (default is 42 bytes) uint16_t fifoCount; // count of all bytes currently in FIFO uint8_t fifoBuffer[64]; // FIFO storage buffer /*-----( Import needed libraries )-----*/ #include <SPI.h> #include <nRF24L01.h> #include <RF24.h> /*-----( Declare Constants and Pin Numbers )-----*/ Quaternion q; // [w, x, y, z] quaternion container VectorInt16 aa; // [x, y, z] accel sensor measurements VectorInt16 aaReal; // [x, y, z] gravity-free accel sensor measurements VectorInt16 aaWorld; // [x, y, z] world-frame accel sensor measurements VectorFloat gravity; // [x, y, z] gravity vector float euler[3]; // [psi, theta, phi] Euler angle container float ypr[3]; // [yaw, pitch, roll] yaw/pitch/roll container and gravity vector const uint64_t pipe = 0xE8E8F0F0E1LL; int attempt_t=1; int attempt_r=1; RF24 radio(9, 10); // Create a Radio int pc_data[20]; uint8_t commands[20]={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,1 9,20}; int recieved_data[5]; int test[2]={3,5}; int conect_counter=0; char b; bool c; int yaw=0; int pitch=1; int roll=2; double gyro[3]; // packet structure for InvenSense teapot demo uint8_t teapotPacket[14] = { '$', 0x02, 0,0, 0,0, 0,0, 0,0, 0x00, 0x00, '\r', '\n' }; volatile bool mpuInterrupt = false; interrupt pin has gone high void dmpDataReady() { mpuInterrupt = true; } bool dmpReady = false; // set true if DMP init was successful 48 Kriban Govender 210512795 // indicates whether MPU Final Report void setup() { if(attempt_t==1) { radio.openWritingPipe(pipe); radio.stopListening(); // Serial.println("attempting to transmit"); attempt_t++; } Serial.begin(115200); radio.begin(); setup_imu(); } bool sent=false; while(!sent) { getAngle(); scaleFactor=2; commands[17]=((euler[0] * 180/M_PI)+180)/scaleFactor; commands[18]=((euler[1] * 180/M_PI)+180)/scaleFactor; sent= radio.write( commands, sizeof(commands) ); // Serial.println("not sent"); void loop() { transmit(); if(Serial.available()>0) { conect_counter=0; for(int i=0;i<20;i++) { pc_data[i]=Serial.read(); } } // // // // // for(int i=0;i<20;i++) { Serial.println(pc_data[i]); } if (pc_data[19]==1) { for(int i=0;i<20;i++) { commands[i]=pc_data[i]; } } for(int i=0;i<20;i++) { Serial.print(commands[i]); Serial.print("\t"); } Serial.print("euler\t"); Serial.print(euler[0] * 180/M_PI); Serial.print("\t"); Serial.print(euler[1] * 180/M_PI); Serial.print("\t"); Serial.print(euler[2] * 180/M_PI); Serial.print("gyro:" ); Serial.print("\t"); for(int i=0;i<3;i++) { Serial.print(gyro[i]); Serial.print("\t"); switch (pc_data[5]) { case 'r': commands[4]=1; transmit(); c=false; while(!c) { delay(50); c=recieve(); } commands[4]=0; break; } Serial.print("\t"); Serial.println("sent"); } bool recieve() { attempt_t=1; case 't': if(attempt_r==1) { radio.openReadingPipe(1,pipe); radio.startListening(); Serial.println("attempting to recieve"); attempt_r++; } break; } } else { conect_counter++; if(conect_counter>20){ commands[19]=0; conect_counter=0; } } } if ( radio.available() ) { // Read the data payload until we've received everything bool done = false; while (!done) { // Fetch the data payload done = radio.read( recieved_data, sizeof(recieved_data) ); } void transmit() { attempt_r=1; 49 Kriban Govender 210512795 Final Report Serial.print("data recieved: "); for(int i=0;i<5;i++) { Serial.print(recieved_data[i]); Serial.print("\t"); } Serial.println(""); return true; // enable Arduino interrupt detection Serial.println(F("Enabling interrupt detection (Arduino external interrupt 0)...")); attachInterrupt(0, dmpDataReady, RISING); mpuIntStatus = mpu.getIntStatus(); // set our DMP Ready flag so the main loop() function knows it's okay to use it Serial.println(F("DMP ready! Waiting for first interrupt...")); dmpReady = true; } else { Serial.println("No radio available"); return false; } // delay(10); // get expected DMP packet size for later comparison packetSize = mpu.dmpGetFIFOPacketSize(); } else { // ERROR! // 1 = initial memory load failed // 2 = DMP configuration updates failed // (if it's going to break, usually the code will be 1) Serial.print(F("DMP Initialization failed (code ")); Serial.print(devStatus); Serial.println(F(")")); } } void setup_imu() { // join I2C bus (I2Cdev library doesn't do this automatically) #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE Wire.begin(); TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz) #elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE Fastwire::setup(400, true); #endif } void getAngle() { // if programming failed, don't try to do anything if (!dmpReady) return; Serial.begin(115200); while (!Serial); // initialize device Serial.println(F("Initializing I2C devices...")); mpu.initialize(); // wait for MPU interrupt or extra packet(s) available while (!mpuInterrupt && fifoCount < packetSize) { } // verify connection Serial.println(F("Testing device connections...")); Serial.println(mpu.testConnection() ? F("MPU6050 connection successful") : F("MPU6050 connection failed")); // reset interrupt flag and get INT_STATUS byte mpuInterrupt = false; mpuIntStatus = mpu.getIntStatus(); // wait for ready Serial.println(F("\nSend any character to begin DMP programming and demo: ")); while (Serial.available() && Serial.read()); // empty buffer while (!Serial.available()); // wait for data while (Serial.available() && Serial.read()); // empty buffer again // get current FIFO count fifoCount = mpu.getFIFOCount(); // check for overflow (this should never happen unless our code is too inefficient) if ((mpuIntStatus & 0x10) || fifoCount == 1024) { // reset so we can continue cleanly mpu.resetFIFO(); Serial.println(F("FIFO overflow!")); // load and configure the DMP Serial.println(F("Initializing DMP...")); devStatus = mpu.dmpInitialize(); // otherwise, check for DMP data ready interrupt (this should happen frequently) } else if (mpuIntStatus & 0x02) { // wait for correct available data length, should be a VERY short wait while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount(); // supply your own gyro offsets here, scaled for min sensitivity mpu.setXGyroOffset(85); mpu.setYGyroOffset(-14); mpu.setZGyroOffset(-9); mpu.setXAccelOffset(-133); // 1688 factory default for my test chip mpu.setYAccelOffset(-4928); mpu.setZAccelOffset(593); // make sure it worked (returns 0 if so) if (devStatus == 0) { // turn on the DMP, now that it's ready Serial.println(F("Enabling DMP...")); mpu.setDMPEnabled(true); // read a packet from FIFO mpu.getFIFOBytes(fifoBuffer, packetSize); // track FIFO count here in case there is > 1 packet available // (this lets us immediately read more without waiting for an interrupt) fifoCount -= packetSize; 50 Kriban Govender 210512795 Final Report // display Euler angles in degrees mpu.dmpGetQuaternion(&q, fifoBuffer); mpu.dmpGetEuler(euler, &q); gyro[yaw] = ((fifoBuffer[24] << 8) + fifoBuffer[25]); gyro[pitch] = ((fifoBuffer[20] << 8) + fifoBuffer[21]); gyro[roll] = ((fifoBuffer[16] << 8) + fifoBuffer[17]); } } 22.8. Appendix H Receiver and I2C slave code Serial.begin(115200); radio.begin(); /*-----( Import needed libraries )-----*/ #include <NewPing.h> #include <SPI.h> #include <nRF24L01.h> #include <RF24.h> } void loop() { uS = (sonar.ping())/ US_ROUNDTRIP_CM; if(recieved_commands[5]==2) { // transmit(); // recieved_commands[5]=0; } delay(30); bool r=recieve(); // sonar test // Send ping, get ping time in microseconds (uS). // Serial.print("Ping: "); // Convert ping time to distance in cm and print result (0 = outside set distance range) //' Serial.println("cm"); /*-----( Declare Constants and Pin Numbers )-----*/ #define TRIGGER_PIN A0 // Arduino pin tied to trigger pin on the ultrasonic sensor. #define ECHO_PIN A1 // Arduino pin tied to echo pin on the ultrasonic sensor. #define MAX_DISTANCE 400 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm. #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE #include "Wire.h" #endif const uint64_t pipe = 0xE8E8F0F0E1LL; int attempt_t=1; int attempt_r=1; int counter=0; RF24 radio(9, 10); // Create a Radio NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance. } void transmit() { attempt_r=1; if(attempt_t==1) { radio.openWritingPipe(pipe); radio.stopListening(); // Serial.println("attempting to transmit"); attempt_t++; } int transmit_data[5]={5,5,5,5,5}; uint8_t recieved_commands[20]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0}; byte q[10]={9,8,7,6,5,4,3,2,1,7}; unsigned int uS=0; void setup() { #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE Wire.begin(2); TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz) #elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE Fastwire::setup(400, true); #endif // join i2c bus with address #2 Wire.onRequest(requestEvent); // register event bool sent=false; while(!sent) { sent= radio.write( transmit_data, sizeof(transmit_data) ); } // Serial.println("sent"); } bool recieve() { 51 Kriban Govender 210512795 Final Report attempt_t=1; // Serial.write("Cm"); Serial.println(" "); // Serial.write(" done"); return true; } if(attempt_r==1) { radio.openReadingPipe(1,pipe); radio.startListening(); // Serial.println("attempting to recieve"); attempt_r++; } else { Serial.println("No radio available"); counter++; if ( radio.available() ) { // Read the data payload until we've received everything bool done = false; while (!done) { // Fetch the data payload done = radio.read( recieved_commands, sizeof(recieved_commands) ); } // Serial.write("data recieved: "); for(int i=0;i<20;i++) { Serial.print(recieved_commands[i]); Serial.print("\t"); } //recieved_commands[5]= uS; // Serial.write(uS); //Serial.write(5); // if (counter>10) // { //radio.close() // radio.begin(); // attempt_t=1; // attempt_r=1; // counter=0; // } return false; } // delay(10); } void requestEvent() { Wire.write(recieved_commands,20); // } 22.9. Appendix I Quadcopter master microcontroller #include <Servo.h> #include "I2Cdev.h" #include <PID_v1.h> #include "MPU6050_6Axis_MotionApps20.h" #define YAW_PID_OUTPUT 100 #define YAW_MAX_MOTOR_BALANCE_SPEED 100 // max amount of thrust that will be applied to balance this axis #define YAW_ERROR_CORRECTION 0 #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE #include "Wire.h" #endif float velocity; // global velocity double bal_ac = 0, bal_bd, bal_axes = 0; // motor balances can vary between -100 & 100, motor balance between axes -100:ac , +100:bd float deltaTime = 0; MPU6050 mpu; #define OUTPUT_READABLE_YAWPITCHROLL #define LED_PIN 13 // (Arduino is 13, Teensy is 11, Teensy++ is 6) #define ESC_MIN 1000 #define ESC_MAX 2000 double va, vb, vc, vd, v_ac, v_bd = 0; #define PITCH_MAX_MOTOR_BALANCE_SPEED 100 // max amount of thrust that will be applied to balance this axis #define PITCH_PID_OUTPUT 40 #define PITCH_ERROR_CORRECTION 0 bool blinkState = false; // MPU control/status vars bool dmpReady = false; // set true if DMP init was successful uint8_t mpuIntStatus; // holds actual interrupt status byte from MPU uint8_t devStatus; // return status after each device operation (0 = success, !0 = error) #define ROLL_MAX_MOTOR_BALANCE_SPEED 100 // max amount of thrust that will be applied to balance this axis #define ROLL_PID_OUTPUT 40 #define ROLL_ERROR_CORRECTION 0 52 Kriban Govender 210512795 // velocities Final Report uint16_t packetSize; // expected DMP packet size (default is 42 bytes) uint16_t fifoCount; // count of all bytes currently in FIFO uint8_t fifoBuffer[64]; // FIFO storage buffer // orientation/motion vars Quaternion q; // [w, x, y, z] VectorFloat gravity; // [x, y, z] Servo ESC1; Servo ESC2; Servo ESC3; Servo ESC4; quaternion container gravity vector int RollOffset=0;//-5; int PitchOffset=0; int YawOffset=0; float ypr[3]; // [yaw, pitch, roll] yaw/pitch/roll container and gravity vector float ypr2[3]={0,0,0}; unsigned long t1; unsigned long t2=0; int MaxThrottle=1900; //double outMin, outMax; //PID PIDRoll(&yprh[2], &yprh_vel_reference[2], &yprh_reference[2], ki_yprh[2],ki_yprh[2], 0, DIRECT); //PID PIDRollRate(&gyro[2], &c[2], &yprh_vel_reference[2], k_yprh_rate[2], ki_yprh_rate[2], 0, DIRECT); double yprh_reference[4]={0,0,0,0}; double yprh[4]={0,0,0,0}; double rollError; double pitchError; double yawError; unsigned int h=0; volatile bool mpuInterrupt = false; interrupt pin has gone high void dmpDataReady() { mpuInterrupt = true; } double k_yprh[4] = { 0, 1.5 ,1.5 ,0}; double ki_yprh[4] = { 0, 0 ,0 ,0}; double kd_yprh[4] = { 0, 0 ,0 ,0}; double k_yprh_rate[4] = {0, 0, 0, 0}; double ki_yprh_rate[4] = {0, 0, 0, 0}; void setup() { double c[4]; double throttle[4]={1000, 1000, 1000, 1000}; rollReg.SetMode(AUTOMATIC); rollReg.SetOutputLimits(-ROLL_PID_OUTPUT, ROLL_PID_OUTPUT); rollReg.SetSampleTime(12); int yaw=0; int pitch=1; int roll=2; int height=3; pitchReg.SetMode(AUTOMATIC); pitchReg.SetOutputLimits(-PITCH_PID_OUTPUT, PITCH_PID_OUTPUT); pitchReg.SetSampleTime(12); int counter=0; uint8_t state=0; uint8_t commands[20]; int hover=0; uint8_t hover_counter=0; double throttle_change=0; yawReg.SetMode(AUTOMATIC); yawReg.SetOutputLimits(-YAW_PID_OUTPUT, YAW_PID_OUTPUT); yawReg.SetSampleTime(12); double gyro[3]; unsigned long time; unsigned long lastTime=0; double ITerm, lastInput; double error; unsigned long SampleTime; pRate.SetMode(AUTOMATIC); pRate.SetOutputLimits(-70, 70); pRate.SetSampleTime(12); rRate.SetMode(AUTOMATIC); rRate.SetOutputLimits(-70, 70); rRate.SetSampleTime(12); //PIDRollRate.SetOutputLimits(-100,100); //PIDRollRate.SetOutputLimits(100,200); //PIDRoll.SetMode(AUTOMATIC); //PIDRollRate.SetMode(AUTOMATIC); double PRateOutput; double RRateOutput; PID yawReg(&gyro[0], &c[0], &yprh_reference[0], 2, 0, 0, DIRECT); PID pitchReg(&yprh[1], &bal_bd, &yprh_reference[1], k_yprh[1], ki_yprh[1], kd_yprh[1], DIRECT); PID rollReg(&yprh[2], &bal_ac, &yprh_reference[2], k_yprh[2], ki_yprh[2], kd_yprh[2], DIRECT); #if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE Wire.begin(); TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz) #elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE Fastwire::setup(400, true); #endif PID pRate(&gyro[1], &PRateOutput, &yprh_reference[1], 0.01, 0, 0, DIRECT); PID rRate(&gyro[2], &RRateOutput, &yprh_reference[2], 0.01, 0, 0, DIRECT); 53 Kriban Govender 210512795 // indicates whether MPU Final Report ESC3.attach(7); ESC4.attach(8); Serial.begin(115200); while (!Serial); //arming ESCs ESC1.writeMicroseconds(1000); ESC2.writeMicroseconds(1000); ESC3.writeMicroseconds(1000); ESC4.writeMicroseconds(1000); // initialize device Serial.println(F("Initializing I2C devices...")); mpu.initialize(); delay(1000); } void loop() { // verify connection Serial.println(F("Testing device connections...")); Serial.println(mpu.testConnection() ? F("MPU6050 connection successful") : F("MPU6050 connection failed")); counter++; if (counter==2) { update_commands(); counter=0; } // wait for ready Serial.println(F("\nSend any character to begin DMP programming and demo: ")); // while (Serial.available() && Serial.read()); // empty buffer // while (!Serial.available()); // wait for data // while (Serial.available() && Serial.read()); // empty buffer again getYPR(); // load and configure the DMP Serial.println(F("Initializing DMP...")); devStatus = mpu.dmpInitialize(); yprh[yaw]=ypr[yaw]* 180/M_PI; yprh[pitch]=ypr[pitch]* 180/M_PI; yprh[roll]=ypr[roll]* 180/M_PI; // supply your own gyro offsets here, scaled for min sensitivity mpu.setXAccelOffset(-1460); // 1688 factory default for my test chip mpu.setYAccelOffset(-950); mpu.setZAccelOffset(347); mpu.setXGyroOffset(19); mpu.setYGyroOffset(-34); mpu.setZGyroOffset(-15); // computeVelocities(); rollError=(-yprh[2]+yprh_reference[2]); pitchError=(-yprh[1]+yprh_reference[1]); yawError =(-yprh[0]+yprh_reference[0]); if (hover>90) { // make sure it worked (returns 0 if so) if (devStatus == 0) { // turn on the DMP, now that it's ready Serial.println(F("Enabling DMP...")); mpu.setDMPEnabled(true); if (state==0) { rollReg.SetMode(AUTOMATIC); pitchReg.SetMode(AUTOMATIC); yawReg.SetMode(AUTOMATIC); // enable Arduino interrupt detection Serial.println(F("Enabling interrupt detection (Arduino external interrupt 0)...")); attachInterrupt(0, dmpDataReady, RISING); mpuIntStatus = mpu.getIntStatus(); pRate.SetMode(AUTOMATIC); rRate.SetMode(AUTOMATIC); state++; } // selectController(); // set our DMP Ready flag so the main loop() function knows it's okay to use it Serial.println(F("DMP ready! Waiting for first interrupt...")); dmpReady = true; computeVelocities(); // get expected DMP packet size for later comparison packetSize = mpu.dmpGetFIFOPacketSize(); } else { Serial.print(F("DMP Initialization failed (code ")); Serial.print(devStatus); Serial.println(F(")")); } } else { // rollReg.SetMode(Automatic); rollReg.SetMode(MANUAL); pitchReg.SetMode(MANUAL); yawReg.SetMode(MANUAL); // configure LED for output pinMode(LED_PIN, OUTPUT); pRate.SetMode(MANUAL); rRate.SetMode(MANUAL); state=0; ESC1.attach(6); ESC2.attach(9); 54 Kriban Govender 210512795 Final Report c[0]=0; c[1]=0; c[2]=0; c[3]=0; bal_bd=0; bal_ac=0; // ITerm=0; } while (Wire.available()) // slave may send less than requested { for(int i=0;i<20;i++){ commands[i] = Wire.read(); // receive a byte as character } if(commands[5]==1) { k_yprh[0]=commands[6]*0.05; ki_yprh[0]=commands[7]*0.05; k_yprh[1]=commands[8]*0.05; ki_yprh[1]=commands[9]*0.05; k_yprh[2]=commands[10]*0.1; ki_yprh[2]=commands[11]*0.05; throttle[0]= c[height] + c[yaw] + c[pitch] + 1000 + hover + throttle_change + PitchOffset; throttle[1]= c[height] + c[yaw] - c[pitch] + 1000 + hover + throttle_change - PitchOffset; throttle[2]= c[height] - c[yaw] + c[roll] + 1000 + hover + throttle_change + RollOffset; throttle[3]= c[height] - c[yaw] - c[roll] + 1000 + hover + throttle_change - RollOffset; } else if(commands[5]==2) { updateMotors(); } k_yprh_rate[0]=commands[6]*0.05; ki_yprh_rate[0]=commands[7]*0.05; k_yprh_rate[1]=commands[8]; ki_yprh_rate[1]=commands[9]*0.05; k_yprh_rate[2]=commands[10]; ki_yprh_rate[2]=commands[11]*0.1; RollOffset=k_yprh_rate[2]; RollOffset=RollOffset-100; PitchOffset=k_yprh_rate[1]; PitchOffset=PitchOffset-100; rollReg.SetTunings(k_yprh[2],ki_yprh[2], ki_yprh_rate[2]); rollReg.SetMode(AUTOMATIC); void computeVelocities() { if(pitchReg.Compute()){ /// bal_bd /= PITCH_PID_OUTPUT; // bal_bd *=50; // c[1]=(bal_bd*PITCH_MAX_MOTOR_BALANCE_SPEED); //bal_bd=-bal_bd; gyro[1]=-gyro[1]; if(pRate.Compute()){ c[1]=PRateOutput; } } pitchReg.SetTunings(k_yprh[2],ki_yprh[2], ki_yprh_rate[2]); pitchReg.SetMode(AUTOMATIC); if(rollReg.Compute()){ // bal_ac /= ROLL_PID_OUTPUT; //bal_ac *=50; //c[2] = (bal_ac*ROLL_MAX_MOTOR_BALANCE_SPEED); //Serial.println(bal_ac); bal_ac=-bal_ac; gyro[2]=-gyro[2]; if(rRate.Compute()){ yawReg.SetTunings( k_yprh_rate[0], ki_yprh_rate[0], 0); yawReg.SetMode(AUTOMATIC); // pitchReg.SetTunings(k_yprh[1],ki_yprh[1], ki_yprh_rate[1]); pRate.SetTunings(k_yprh[0],ki_yprh[0],0); pRate.SetMode(AUTOMATIC); c[2]=RRateOutput; rRate.SetTunings(k_yprh[0],ki_yprh[0], 0); rRate.SetMode(AUTOMATIC); } } } gyro[0]=-gyro[0]; if(yawReg.Compute()){ { if(commands[19]==1) yprh_reference[0]=(commands[2]-100); yprh_reference[1]=(commands[1]-100); yprh_reference[2]=(commands[0]-100); yprh_reference[3]=0; throttle_change=((commands[3]-100)); throttle_change=(throttle_change/100)*(MaxThrottle1000); hover=(commands[4]*10); digitalWrite(LED_PIN, HIGH); } else if(commands[19]==0) // c[0] = bal_axes; } } void update_commands() { Wire.requestFrom(2, 20); // request 6 bytes from slave device #2 55 Kriban Govender 210512795 Final Report { } digitalWrite(LED_PIN, LOW); hover_counter++; // hover=0; if(hover_counter==200) { hover_counter=0; descend(); } //roll if(throttle[2]<(MaxThrottle)) { if(throttle[2]>1000) { ESC1.writeMicroseconds(throttle[2]); } else { ESC1.writeMicroseconds(1000); } } else { ESC1.writeMicroseconds(MaxThrottle); } } printVal(); } } void descend() { yprh_reference[0]=0; yprh_reference[1]=0; yprh_reference[2]=0; yprh_reference[3]=0; throttle_change=0; hover=0; } if(throttle[3]<(MaxThrottle)) { if(throttle[3]>1000) { ESC2.writeMicroseconds(throttle[3]); } else { ESC2.writeMicroseconds(1000); } void updateMotors() { } //pitch if(throttle[0]<(MaxThrottle)) { if(throttle[0]>1000) { ESC3.writeMicroseconds(throttle[0]); } else { ESC3.writeMicroseconds(1000); } } else { ESC3.writeMicroseconds(MaxThrottle); } else { ESC2.writeMicroseconds(MaxThrottle) ; } } void getYPR() { { // if programming failed, don't try to do anything if (!dmpReady) return; // wait for MPU interrupt or extra packet(s) available while (!mpuInterrupt && fifoCount < packetSize) { // while() loop to immediately process the MPU data } if(throttle[1]<(MaxThrottle)) { if(throttle[1]>1000) { ESC4.writeMicroseconds(throttle[1]); } else { ESC4.writeMicroseconds(1000); } // reset interrupt flag and get INT_STATUS byte mpuInterrupt = false; mpuIntStatus = mpu.getIntStatus(); // get current FIFO count fifoCount = mpu.getFIFOCount(); } // check for overflow (this should never happen unless our code is too inefficient) if ((mpuIntStatus & 0x10) || fifoCount == 1024) { // reset so we can continue cleanly mpu.resetFIFO(); else { ESC4.writeMicroseconds(MaxThrottle) ; 56 Kriban Govender 210512795 Final Report Serial.println(F("FIFO overflow!")); } Serial.print("gyro:" ); Serial.print("\t"); for(int i=0;i<3;i++) { Serial.print(gyro[i]); Serial.print("\t"); } else if (mpuIntStatus & 0x02) { // wait for correct available data length, should be a VERY short wait while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount(); // read a packet from FIFO mpu.getFIFOBytes(fifoBuffer, packetSize); } Serial.print(" throttle_change: "); Serial.print( throttle_change); Serial.print("\t"); Serial.print(" c1: "); Serial.print( c[0]); Serial.print("\t"); Serial.print(" error: "); Serial.print(yawError); Serial.print("\t"); Serial.print(" k: "); Serial.print(k_yprh[2]); Serial.print("\t"); Serial.print(ki_yprh[2]); Serial.print("\t"); Serial.print( ki_yprh_rate[2]); Serial.print("\t"); t1=millis(); Serial.print("time: "); Serial.println(t1-t2); t2=t1; fifoCount -= packetSize; // #ifdef OUTPUT_READABLE_YAWPITCHROLL // display Euler angles in degrees mpu.dmpGetQuaternion(&q, fifoBuffer); mpu.dmpGetGravity(&gravity, &q); mpu.dmpGetYawPitchRoll(ypr, &q, &gravity); gyro[yaw] = ((fifoBuffer[24] << 8) + fifoBuffer[25]); gyro[pitch] = ((fifoBuffer[20] << 8) + fifoBuffer[21]); gyro[roll] = ((fifoBuffer[16] << 8) + fifoBuffer[17]); } } } void printVal() { Serial.print(" " ); Serial.print("ypr:" ); Serial.print("\t"); for(int i=0;i<4;i++) { } Serial.print(yprh[i]); Serial.print("\t"); } Serial.print("throttle:" ); Serial.print("\t"); for(int i=0;i<4;i++) { Serial.print(throttle[i]); Serial.print("\t"); 57 Kriban Govender 210512795 Final Report 22.10. Appendix J Circuits 3 Arduino microcontrollers were used to implement the design, 2 were used for interfacing the transceiver modules via the SPI bus, and the third was used to stabilise the quadcopter using the mpu6050 imu. Figure 39: Arduino Pin Out Figure 40 shows a picture of the mpu6050 imu containing the accelerometer as well as the gyro. The on board dmp performs the sensor fusion and transmits the quadcopters orientation via the I2C bus . Figure 40: mpu6050 imu 58 Kriban Govender 210512795 Final Report Figure 41 shows the Electronic speed controller (ESC) used to control the brushless DC motors, the Lipo battery is connected directly to the ESC. The ESC has a battery eliminating circuit which provides a regulated 5V output which is used to power up the arduino microcontroller as well as the sensors. Figure 41: 20A Skywalker ESC Figure 42 shows the 1000Kv rated brushless DC motor that was used, the output of the ESC is connected directly to the motor. Figure 42: 1000Kv brushless motor 59 Kriban Govender 210512795 Final Report 22.11. Appendix K The deadlines for the submission of reports and the dates for the presentations are shown below and must be adhered to. Table 4: Deadlines for reports and presentations Date 31 July 14 October 17 October 13 November 17 November Description Phase 1 Report due Phase 2 Report Due Phase 2 Presentation Final Report Due Final Presentation The time plan that is shown below gives a detailed description of what needs to be done and a relative time frame that is needs to be completed in. To ensure that the project is completed in the 13 weeks, these dates need to be followed accordingly. Table 5: Timeline of specific tasks Date 1 August – 6 August 7 August – 15 August 7 August – 22 August 7 August – 22 August 18 August 23 August – 26 August 27 August – 6 September 7 September - 13 September 18 September - 25 September 26 September - 3 October 4 October - 11 October 18 October - 25 October 26 October - 2 November 3 November - 10 November Description Obtain the required components and estimate the total weight of the quadcopter Design and simulate the flight controller Develop circuits for the quadcopter Develop circuits for the head-tracking system Finalize the specifications of the project Assemble the quadcopter Configure and test the flight sensors Configure and test the head-tracking sensors Develop GUI Interface head-tracking system to the GUI Interface remote controller to the GUI Establish wireless connection between the quadcopter and the ground system Perform the fight tests Interface the servo motors with the quadcopter for the FPV equipment 60 Kriban Govender 210512795 Final Report 22.12. Appendix L (ECSA Report) University of KwaZulu-Natal School of Engineering, Howard College Campus Stude t’s Repo t o ECSA Out o es Programme Electrical Engineering Student Name Kriban Govender Student Number 210512795 Date of Submission 13 November 2014 Instructions for students 1. All sections must be completed 2. For each assessment criteria, evidence of competence must be summarized in the clear blocks, or reference to available evidence must be provided. 3. Where detailed evidence is provided in appendices, these must be both clearly marked and cross-referenced. 4. The same evidence may be used to show competency with more than one outcome. Instructions for examiners 1. Examiners must assess if competence is demonstrated as stated by the student. 2. If requested, the examiners may interview the student. 3. Comments may be added for each outcome. 4. Remedial action 5. s/s must be specified by the examiners in cases where outcomes are not adequately demonstrated. 1 Exit Level Outcome 1: Problem Solving Learning outcome: Competence Demonstrated Demonstrate competence to identify, assess, formulate and solve No convergent and divergent engineering problems creatively and Yes innovatively Assessment Criteria: Application of systematic approach to problem solving including: 1.1. Problem analysis as well as problem solving skills Evidence of competence: The student needed to research the working principle and Dynamics of a quadcopter to fully understand the operation. The problem analysis is indicated by the objectives set at the beginning of the report (section 2). Problem solving skills are displayed through the modelling of the system as well as the simulation (section 6, section 8). Exit level assessment: Project specification and analysis as well as problem solving skills. 1.2 Identification of necessary information and application of engineering and other knowledge and skills Evidence of competence: Throughout the report the knowledge obtained from Systems and Simulation, Control Systems 1 and Control Systems 2 is used, the knowledge and skills obtained from these courses was used to obtain the quadcopter system model as well as simulate the system and design the control system required for the quadcopter (section 6, section 8, section 9, section 10, and section 11). Knowledge 61 Kriban Govender 210512795 Final Report obtained from Computer Methods 2 was used to design the GUI (Section 17). Knowledge and skills obtained from Digital Systems and Embedded System were used to program the various microcontrollers needed to implement the quadcopter control system as well as integrate the various components of the project. Exit level assessment: Problems are needed to be solved using principles and skills acquired in engineering courses such as mathematics, control systems and power electronics. The detail and depth of the design report and simulation models showed the ability to identify necessary information which needed to be included. 1.3 Generation and formulation of possible approaches to solution to problem Evidence of competence: Evidence of competence is noted in section 18.2, that there are various methods to implement the quadcopter control system, initially 8 controllers were designed, showing the different controllable aspects of the quadcopter, but after a further analysis it was seen that it was more feasible to control 5 of the 8 aspects. Evidence of competence is also noted in in the modelling of the Rotor(section 6) and the conclusion, various methods where available to determine the rotor model such as creating a mathematical model, but it was more feasible to use system identification methods that was obtained from Control Systems 2, since the motor constants were unknown. Exit level assessment: The ability to determine many different solutions and approaches to a proposed design topic and then determining and implementing the most feasible one. 1.4 Modelling and analysis of possible solution(s) Evidence of competence: The modelling and analyses of the quadcopter system is noted in section 8, which was done on Matlab. Evidence to analyse a problem is also seen in section 9, since the most feasible method to li ea ize the uad opte syste was usi g atla ’s li ea izi g fu tio o the o -linear model. It is also noted in the controller design section (section 10). Exit level assessment: The ability to analyse a problem and then determine the most feasible option which to implement. 1.5 Evaluation of possible solutions and selection of best solution Evidence of competence: This is noted in the Hardware selection section (section 14). The most feasible design of the quadcopter was implemented which can be seen by the choice of components used (section 15). Various methods where available to obtain the orientation of the quadcopter from the gyro and accelerometer sensors, such as implementing a kalman or complementary filter, but the most feasible solution was to use the on board Digital motion processor, which was the chosen method(section 7 and conclusion). Exit level assessment: The design topic was analysed, several solutions determined and the best option was justified and then implemented. 1.6 Formulation and presentation of selected solution in an appropriate form Evidence of competence: The formulation of the chosen solution is thoroughly explained in the report in report and can be seen by the approach taken to design the control system (section 10), The selected solution to the problem was modelled in Matlab and simulated (section 11). The above solution was presented to an audience during phase 2 of the project during the interim presentation. 62 Kriban Govender 210512795 Final Report Exit level assessment: The design solution was presented orally to an audience and questions were then asked. Range Statement: Problems require identification and analysis. Some cases occur in unfamiliar contexts. Problems are both concrete and abstract and may involve uncertainty. Solutions are based on theory and evidence, together with judgement where necessary. Examiners comments and recommended remedial actions if any competence not demonstrated for outcome 1 2 Exit Level Outcome 2: Application of Scientific and Engineering Knowledge Learning outcome: Competence Demonstrated Demonstrate competence to apply knowledge of mathematics, No basic science and engineering sciences from first principles to solve Yes engineering problems. Assessment Criteria: Demonstrate competence to: 2.1 Identification and application of appropriate mathematical sciences for a given design problem Evidence of competence: This is seen in obtaining the model of the quadcopter system (section 6), as well as calculating the various moments of inertia of the system which was required for the simulation (section 7). Exit level assessment: There were applications of knowledge of mathematics from the first principles to solve a given problem, design a system, design components of a system and achieve optimum and feasible solutions and implementation. 2.2 Identification and application of appropriate basic sciences for a given design problem Evidence of competence: Obtaining the mathematical model of the Rotor was difficult to obtain since the motor constants were not known, but knowledge obtained from Control system 2 made possible to obtain a model of the rotors using system identification methods (section 6 and the conclusion). Exit level assessment: There were applications of knowledge of basic sciences from the first principles to solve a given problem, design a system, design components of a system and achieve optimum and feasible solutions and implementation. 2.3 Identification and application of appropriate engineering sciences for a given design problem Evidence of competence: Knowledge obtained from Systems and Simulation, Control Systems 1 and Control Systems 2 is used, the knowledge and skills obtained from these courses was used to obtain the quadcopter system model as well as simulate the system and design the control system required for the 63 Kriban Govender 210512795 Final Report quadcopter (section 6, section 8, section 9, section 10, and section 11). Knowledge obtained from Computer Methods 2 was used to design the GUI (Section 17). Knowledge and skills obtained from Digital Systems and Embedded System were used to program the various microcontrollers needed to implement the quadcopter control system as well as integrate the various components of the project. Exit level assessment: There were applications of knowledge of engineering sciences from the first principles to solve a given problem, design a system, design components of a system and achieve optimum and feasible solutions and implementation. Range Statement: Problems require applications of mathematics, basic sciences and engineering sciences for solving them. There should be appropriate applications of the relevant mathematics, basic sciences and engineering sciences with proper judgement. Examiners comments and recommended remedial actions if any competence not demonstrated for outcome 2 3 Exit Level Outcome 3: Engineering Design Learning outcome: Competence Demonstrated Demonstrate competence to perform creative, procedural and nonYes No procedural design and synthesis of components, systems, engineering works, products or processes Assessment Criteria: Demonstrate competence to: 3.1 Identification and formulation if the design problem to satisfy user needs, applicable standards, codes of practice and legislation Evidence of competence: The roll, roll rate, pitch, pitch rate controllers where designed and implemented, the results show that the design specifications where adhered to and the output of the system was able to track the reference (section 18.3). Exit level assessment: The design problem was identified and a solution formulated which compiled to the given specifications and is able to satisfy the needs of its user. As well as conform to the applicable standards, legislation and codes of practice. 3.2 Planning and effectively managing a design process focusses on important issues, recognises and deals with constraints Evidence of competence: In the progress report a Timeline was constructed to effectively manage the time constraints. The previous reports and presentation was completed successfully within the time frame given. The construction was completed in time for the final report. Exit level assessment: Planning, time management skills as well as completion of simulation models and reports within a 64 Kriban Govender 210512795 Final Report time constraint were adhered to. 3.3 Acquiring and evaluation of appropriate knowledge, information and resources: application of correct principles and uses appropriate design tools Evidence of competence: This can be seen in the references section, these represent the main sources of information that the student consulted during the design process. It is noted that books, journals, previous designs as well as the internet was used as sources of information. The main design tool used was Matlab carry out the simulation study (section 11). Engineering skills developed by the student helped during the construction of the design Exit level assessment: Ability to resource information using various sources, engineering skills as well as the correct application of information gathered is assessed. The correct design tools also need to be used. 3.4 Performs design tasks (including analysis, quantitative modelling and optimization) Evidence of competence: Analysis was done is the theory section (section 4), this knowledge gave the understanding to simulate the design on the Matlab software. In terms of optimisation, the quadcopters controllers needed to be tuned during implementation in order to improve the quadcopters response. It was also noted that the speed controllers heat up due to the large current it supplies, therefore the speed controllers where mounted below the propellers to allow for efficient cooling. Exit level assessment: The analysis, modelling and optimisation of the design solution are assessed. The performance evaluation and presentation of the design is also assessed. 3.5 Evaluation of alternatives and perfect solution (exercises judgement, tests implementation ability and performs techno-economic analysis) Evidence of competence: After analysing various aspects of the project, the most feasible solution was implemented, this can be seen in the hardware selection section (section 14). Testing of the components was conducted during the rotor modelling (section 6) as well as testing of the controllers (section 18.3). Exit level assessment: The analysis of various solutions and implementing the most suitable of them. 3.6 Assessment of the impacts and benefits of the design (e.g. social, legal, health, safety and environmental) Evidence of competence: The design is well suited for various commercial and military applications, such as, aerial photography, surveillance as well as search and rescue and search and destroy as mentioned in the introduction. Exit level assessment: The environmental and social impacts of the design are assessed. 3.6 Communication of the design and information Evidence of competence: Communication between the supervisor was necessary in conducting the feasibility study as well as simulation and implementation of the quadcopter. Other resources that are stated in the references also provide relevant information for the design. Exit level assessment: Oral presentation skills as well as formal report writing skills were assessed. 65 Kriban Govender 210512795 Final Report Range statement: A major design problem should be used to provide evidence. The problem would be typical of that which the graduate would participate in a typical employment situation shortly after graduation. The selection of components, systems, engineering works, products or processes to be designed is dependent on the discipline. Examiners comments and recommended remedial action if competence not demonstrated for outcome 3 4 Exit Level Outcome 4: Investigations, experiments and data analysis Learning outcome: Competence Demonstrated Demonstrate competence to design and conduct investigation and Yes No experiments Assessment Criteria: The outcome is assessed in a large number of professional courses and passing the practical sessions in these courses is considered to indicate a successful achievement of the outcome. 5 Exit Level Outcome 5: Engineering methods, skills and tools including information technology Learning outcome: Competence Demonstrated Demonstrate competence to use appropriate engineering methods, Yes No skills and tools, including those based on information technology. Assessment Criteria: Demonstrate competence to: The outcome is assessed in some professional courses and passing the examinations and practical sessions in these courses is considered to indicate a successful achievement of the outcome. 6 Exit Level Outcome 6: Professional and Technical Communication Learning outcome: Competence Demonstrated Demonstrate competence to communicate effectively, both orally Yes No and in writing with engineering audiences and community at large. Assessment Criteria: Effective written and oral communication appropriate to target audience as evidenced by: 6.1 Use of appropriate structure, style and language Evidence of competence: This is noted in the entire report, as well as past presentations rendered on this topic. This was also achieved in past design modules, such as design 5 as well as technical communications. Exit level assessment: Report writing skills such as content, language, diagrams, output results and correct referencing were 66 Kriban Govender 210512795 Final Report assessed. While for the oral presentation grammar, language, fluency, organisation of material and time constraint skills are assessed. 6.2 Use of appropriate visual materials Evidence of competence: Figures of the relevant models and simulations are presented in the report (section 8, section 10, and section 11). Pictures showing various aspects of the implementation is also seen under implementation (section 16). The appropriate visual aids are present on the poster to be used for the final presentation Exit level assessment: The various visual figures used in the report and their function of aiding the understanding of the material as well as whether they are subject specific will be assessed. In the PowerPoint presentation, the visual appeal, appropriateness of material included as well as the neatness and logical though sequence will be assessed. 6.3 Delivers fluently Evidence of competence: This is again achieved throughout the report, as well as in all previous reports and presentations in the future. Exit level assessment: The language in both the report and oral presentation needed to be correct, formal, fluent and display a logical flow of thought. 6.4 Meets the requirements of the intended audience Evidence of competence: The main objectives of the project were met. The report is also written so that any individual, regardless of background is able to grasp the outcome of the project. The oral presentation is essentially based on the report, and will hence contain these realisations. Exit level assessment: The oral and formal report presentation of the design must meet the requirements of the project supervisor and external examiner and must conform to ECSA standards. The design must also be presented in details in order to ensure the audience leaves with an in-depth understanding and further knowledge of the topic. Range Statement: Material to be communicated is in an academic or simulated professional context. Audiences range from engineers, peers, management and lay persons, using appropriate academic or professional discourse. Written reports range short (300-1000 words plus table, diagrams) to long (10000 to 15000 words plus tables, diagrams and appendices), covering material at exit level. Methods providing information include the conventional methods of the discipline, for example engineering drawings, as well as subject-specific methods. Examiners comments and recommended remedial action if competence not demonstrated for outcome 6 7 Exit Level Outcome 7: Impact of Engineering Activity Competence Demonstrated Learning outcome: 67 Kriban Govender 210512795 Final Report Demonstrate critical awareness of the impact of engineering activity Yes on the social, industrial and physical environment. Assessment Criteria: A pass mark in the examinations of various complementary study courses. No 8 Exit Level Outcome 8: Individual, Team and Multidisciplinary Working Learning outcome: Competence Demonstrated Demonstrate competence to work effectively as an individual, in Yes No teams and in multidisciplinary environments. Assessment Criteria: 8.1 Demonstrates effective individual work by (i) the identification and focusses on objectives (ii) working strategically (iii) executing tasks effectively and (iv) delivery of completed work on time Evidence of competence: (i) The objectives set by the student initially, have all been met sufficiently in terms of the standard the student has set for himself. (ii) Working strategically and following the Timeline chart allowed the work to be completed in the time indicated by the supervisor in all the phases of the design module. (iii) All the previous reports and presentations were completed effectively. Consistent work on this module was done throughout the semester and tasks was executed effectively. (iv) All reports have been submitted on time. Exit level assessment: Working effectively, consistently, strategically and individually was all assessed. Assessment Criteria: 8.2 Demonstration of effective team work by (i) making individual contribution to team activity (ii) performing critical functions (iii) enhancing work of fellow team members (iv) benefitting from the support of team members (v) communicating effectively with team members and (vi) delivery of completed work on time Evidence of competence: Not applicable. The student undertook all the work individually. Exit level assessment: The ability to work in a team as well as the contribution of work or the team was assessed. Assessment Criteria: 8.3 Demonstration of multidisciplinary work by (i) acquiring a working knowledge of co-workers’ discipli e (ii) using a systems approach and (iii) communication across discipline boundaries Evidence of competence: A working knowledge of not only electrical but also electronic, computer and mechanical engineering was required to complete this design module effectively. Using a systems approach, the structure provide by the Timeline was used to complete the design. The theory was done first, 68 Kriban Govender 210512795 Final Report then the simulation and controller design and lastly the implementation. Exit level assessment: The effective communication and interaction with co-workers from other disciplines as well as attainment of know from other fields. Range Statement: Tasks require co-operation across at least one disciplinary boundary. Disciplines may be other engineering, disciplines or be outside engineering. Examiners comments and recommended remedial action if competence not demonstrated for outcome 8 9 Exit Level Outcome 9: Independent Learning Ability Learning outcome: Competence Demonstrated Demonstrate competence to engage in independent learning ability Yes No through well-developed learning skills. Assessment Criteria: This outcome is assessed in several design courses and at least one specific self-study course that must be passed. 10 Exit Level Outcome 10: Engineering Professionalism Learning outcome: Competence Demonstrated Demonstrate critical awareness of the need to act professionally and Yes No ethically and to exercise judgement and take responsibility within own limits of competence. Assessment Criteria: This outcome is assessed in specific professional business related course that must be passed. 69 Kriban Govender 210512795