Home

Autonomous UAV Final Report - Senior Design

1. AUTONOMOUS UAV FINAL REPORT Client opace Systems amp Controls Laboratory SSCL Faculty Advisor Matthew Nelson Team Members Anders Nelson EE Kshira Nadarajan CprE Mathew Wymore CprE Mazdee Masud EE Table of Contents List of Figures List of Tables List of Symbols List of Definitions 1 Introductory Material 1 1 Executive Summary 1 2 Acknowledgement 1 3 Problem Statement 1 3 1 General Problem Statement 1 3 2 General Solution Approach 1 4 Operating Environment 1 5 Intended Users and Uses 1 5 1 Intended Users 1 5 2 Intended Uses 1 6 Assumptions and Limitations 1 6 1 Updated Assumptions List 1 6 2 Updated Limitations List 1 7 Expected End Product and Other Deliverables 2 Approach and Product Design Results 2 1 Approach Used 2 1 1 Design Objectives 2 1 2 Functional Requirements 2 1 3 Design Constraints 2 1 4 Technical Approach Considerations and Results 2 1 5 Testing Approach Considerations 2 2 Detailed Design 2 2 1 Software System 2 2 2 Control System Controllers 2 2 3 Sensor System 2 2 4 Power System 3 Resources and Schedules 3 1 Resources Requirements 3 1 1 Personnel Effort Requirements 3 1 2 Other Resource Requirements 3 1 3 Financial Requirements 3 2 Schedules 3 2 1 Project Schedule 4 Implementation 4 1 Hardware Implementation 4 1 1 Gumstix Implementation 4 1 2 PIC Implementation 4 1 3 PCB Implemention 4 2 Software Implementation 4 2 1 Obstacle Detection Module 4 3 Power System
2. Psa smoothed value of prediction of obstacle at angle t Psa 1 smoothed value in the previous angle instant Pa new raw observation obtained at angle instant m number of angles range pair readings used to compute the running average k the parameter used to vary the effect of Pa new has on the smoothed value Return the probabilityOfObstacle 2 The above step is repeated for ranges of angles for the Left Right and Front side The ranges for these sections can be modified For example if the robot needs to move left without moving forward the angle range can be adjusted to 60 to 120 For the front it can be between 45 to 45 etc One of the objectives while implementing this algorithm was to allow these flexibilities based on the needs of the platform and the mapping algorithm s requirements 3 This For each of these sides if the probability returned was gt 0 6 it is considered as an obstacle This threshold can be adjusted based on the sensitivity of the motors 4 This process is repeated over a time period that can be adjusted again based on the sensitivity of the motor and the needs of the control mechanism Refer to figures Fig 4 2 b and Fig 4 2 c for a visual sense of how the calculation is done 32 Page Angel Strike Software Design Modules Independent Module for mapping Radio Beapon Infommation ision Object Recognition Module Rem
3. Shaded components are outside the scope of this design Digital out IMU is assumed Analog IMU may be used with minor alterations Optional Main processor is still under discussion Camera system is shown for context Figure 2 2 2 e Draft System Design with Gumstix As proof of concept the team s research has showed that previous IARC competitors have used similar systems The team has arrived at the proposed design independently so the similarity with other competitors systems is encouraging Also the project advisor who has previous experience in this type of design has approved the choices made Finally the selected components were thoroughly researched in order to ensure they met the requirements and were compatible A more detailed design followed and is shown below This may be considered the proposed control system design Note the inclusion of the Gumstix Summit board and expansion board for the Gumstix Overo Fire computer on module that features USB connections and an unpopulated 40 pin header that can be used for other sensor expansions The Summit also includes a DVI D connection that can be used in conjunction with the Fire s Bluetooth module for system programming and testing 19 Page UAV Electronics 4 3 2011 Power Monitor Custom PCB Figure 2 2 2 f Controller Design 2 2 3 Sensor System The sensor system is composed of two types of sensors internal sensors that measure the characteristic
4. investment for achieving the desired flight time with room for error 41 Page 6 Future Work 6 1 Current Status Here at the end of the semester there is still much work to be done on this project We have managed to set the foundation for future teams to pick up where we left off and continue towards the overall end goal Currently the parts implemented are e Parts selected and overall design setup e Custom PCB has been designed e Gumstix o Ad Hoc Network automatically sets up o Connections wired for PIC and RS 232 to Laser o Communication protocol with PIC created o Receives sonar data in o PWM output established with simple functions created e Laser Range Finder o Data communication established o Call functions created for ease of use o Obstacle detection algorithms created o Viewer for data available for user e Power System o Voltage regulation circuit designed o Batteries to be ordered selected 6 2 Future Implementations e Determine final layout of PCB o Order PCB e Gumstix Setup frame grabber for cameras Setup communication protocol with base station Implement software for control of all system O O O O Send data to base station through software e PIC Make connection with IMU Implement control algorithms Test stability of control and find drift o Test interchange between RC and PIC to Gaui O O e Implement the navigation and vision algorithms e Test and debug entire system 42
5. A custom PCB 1s expected to eventually replace the Explorer 16 and daughter board The connection to and parsing of data from the MaxBotix LV MaxSonar EZA sonar module used to determine altitude has been successfully implemented This includes a data connection to the receive input for one of the PIC s UART modules as well as a connection from the sonar to ground and power The sonar module sends serial data in the form of an ASCII R character three ASCII numerical digits forming an integer representing the range in inches up to 255 and a carriage return The UART module is programmed to trigger an interrupt when its receive buffer 1s half full The PIC s UART receive buffer has 8 entries so this means the interrupt will fire when the UART has received at least 4 entries If the data can be parsed according to the above described format a global altitude variable is updated with the new data This variable will eventually be used in the altitude control loop For testing this variable has been outputted in binary to the eight LEDs of the Explorer 16 board Pulse Width Modulation PWM outputs have also been successfully programmed These signals will eventually be used to execute flight commands with the Gaui flight controller The outputs of the PIC have been set up to be programmable with a duty cycle ranging from lms to 2ms which is 0 to 100 of the recognized range of the Gaui Adjustments in duty cycle can be made in steps as
6. PIC connections for sonar input RC controller motor control out Gumstix to Laser conversion among others The schematic for the system that utilizes the smallest items possible to achieve the task was created and is given in 4 1 3a The layout of the PCB is to implemented at a later time If any changes in connection is needed at a later date through hole connections will be added with connection to the PIC 29 Page Figure 4 1 3 a PCB Schematic 4 2 Software Implementation 4 2 1 Obstacle Detection Module The controls team members working on the path planning algorithm were the key users of the obstacle detection module This can be seen clearly in the software block diagram Fig 4 2 a Our implementation of the obstacle detection module is explained in the following sections 1 Laser Range finder hardware For the hardware we picked the Hokuyo URG 04L X model which is widely used in robotic applications The range detection specifications are given below e Voltage 5 0V 5 e Current 0 5A Rush current 0 8A e Detection Range 0 02m to approximately 4m e Laser wavelength 785 nm Class 1 30 Page e Scan angle 240 e Scan time 100msec scan 10 0Hz e Resolution Imm e Angular Resolution 0 36 e Interface USB 2 0 RS232 e Weight 5 0 oz 141 gm 2 Laser Range finder Gumstix Interface The interface preferred was the serial communication link because this would minimize the power consum
7. even a system on chip would be minor compared to the power used by the motors The weight budget showed considerable room for play as well so those factors while still important were of less concern than initially thought Thus the following table comparing and scoring main controller options was produced All options considered included USB host capability and a WiFi module Option Size weight Score Power Score Price Score Other Score Total No Linux TI Stellaris 1 12x12mm 56MA 3 3V difficult USB Xbee PRO 2 5x3cm 1 250mAQ3 3V 2 50 2 host 3 2 Gumstix Linux USB Overo Fire 17x58mm onboard CPU Palo 35 98 5x64mm 0 550mAQ3 3V 1 280 0 power easy 3 4 Linux 1 USB ISEE IGEPv2 93x65mm 1 650mA 5V 0 250 0 HDMI out 2 3 Hats USB Compui as enbeerda chu EM 43530 TOM D E pewereasy 3 5 HeH Computab enbeard cPu EM Ak 0 Z5ee6bme oM s27 0 pewer eaesy 3 3 Linux USB hub BeagleBoard 83x83mm powerful xM USB WiFi 36x18mm 0 750mA Q5V 0 220 0 HDMI 3 3 Linux 3 USB TechNexion Debug LCD TAO 3530 64x35mm speakers Thunder 105x74mm 1 3W 0 275 0 HDMI 2 1 Table 2 2 2 a Hardware Options Scoring Options were scored based on size and weight power consumption price and other features for usability and expandability The highest score was given to a system from a company named CompuLab However upon contact the company declined to sell single products to academia Thus the Gumstix Overo Fi
8. spidev test program an oscilloscope the register watch function of the MPLAB IDE used to program the PIC and the console output of the Gumstix Thus far the both the PIC and the Gumstix have been shown to be receiving data from each other However the PIC is not processing the data correctly and the data between the PIC and the Gumstix is not being accurately transferred At best the Gumstix has been shown to correctly receive a repetitive bit pattern from the PIC These issues are still being worked on by the current team 5 1 2 PIC Testing The pulse width modulation output component of the PIC has been tested with an oscilloscope to ensure that the outputs are of the expected duty cycle and the waveforms are clean and stable These tests have been successful PWM outputs have not been tested with the Gaui as the PIC has not yet been integrated with the flight platform The MaxSonar EZ4 sonar module has been tested by displaying the received range value on the Explorer 16 s LED bank Using a yardstick to measure actual ranges to a variety of surfaces the sonar module has been shown to be generally accurate within an inch between the range of 8 and 44 inches All ranges under 8 inches are reported as 6 inches Test results are reported in the diagram below 38 Page Measured distance vs Actual distance with LV MaxSonar EZ4 70 60 50 40 30 20 Measured distance using sonar inches 10 0 123 45 6 7 8 9 101
9. 5 Testing 5 1 Hardware Testing 5 1 1 Gumstix Testing OOOO E GO GO JJ JJ JJ DAAA Un AG 1 Page 5 1 2 PIC Testing 38 5 2 Sensors Testing 39 5 2 1 Laser Range Finder Testing 39 5 2 2 Sonar Testing 40 5 3 Power Testing 40 5 3 1 Endurance Test 40 6 Future Work s 9 99 9 9 ss lLlLnLLLLLLLLLLLLLLLLLLLL 42 6 1 Current Status 42 6 2 Future Implementations 42 7 Lessons Learned LLL 43 7 Importance of Communication 43 7 2 Full Team from Start 43 7 3 Attention to Detail 43 7 4 Too Much in Too Little Time 44 8 ClosureMaterial eee 45 8 1 Project Team Information 45 8 1 1 Client Information 45 8 1 2 Faculty Advisor Information 45 8 1 3 Student Team Information 45 8 2 Closing Summary 46 8 3 References 47 8 4 Appendices 48 8 4 1 Appendix I Competition Rules 48 6 4 2 Appendix II Gumstix AngelStrike Change Log 50 6 4 3 AppendixlII Gumstix User Manual 53 8 4 4 Appendix IV PICstix Communication Protocol 55 2 Page List of Figures Figure 1 3 2 a System Block Diagram Figure 2 2 1 a Software Flow Diagram Figure 2 2 2 a Main Control Board Initial Design Figure 2 2 2 b Option 1 System On Chip Figure 2 2 2 c Option 2 All in one MCU Figure 2 2 2 d Option 3 Divide and Conquer MCUs Figure 2 2 2 e Draft System Design with Gumstix Figure 2 2 2 f Controller Design Figure 3 2 1 a Project Schedule Figure 4 1 3 a PCB Schematic Figure 4 2 1 a Overall System Level Software Block D
10. Battery BEC Voltage Regulator A voltage regulator will be used to for the power system This voltage regulator will produce 11 1V to the ESC s and to the motors 3 3V to the PIC and 5V to Laser Sonar GumStix Camera IMU The setup is like a simple circuit the fig is given below ESC s Laser 11 1 V Current Measure Gumstix SES eee Voltage Regulator 5 V Camera 3 cell Sonar 3 3V IMU PIC Figure 4 3ba Power System Block Diagram 37IPage 3 Testing 5 1 Hardware Testing 5 1 1 Gumstix Testing The Gumstix s ad hoc WiFi network has been tested through extensive normal use Throughout the implementation process the WiFi connection has been constantly used for configuring and testing other aspects of the Gumstix Not once has the connection been unexplainably dropped or found to be non responsive Thus the stability of the connection has been tested and found to be satisfactory However constant use has also shown that establishing the connection to the Gumstix can sometimes require several attempts This is believed to be an issue that occurs only shortly after the Gumstix has been booted Allowing the Gumstix to run for around a minute before attempting to connect to it reliably yields a successful connection The SPI connection between the PIC and the Gumstix has been tested using a readily available
11. and a Gumstix Summit expansion board These components have been received assembled and successfully booted The default Gumstix rootfs and Angstrom Linux kernel have been modified rebuilt and redeployed to the Gumstix nonvolatile memory The modified kernel includes user space SPI support through the spidev protocol driver as well as a stable version of gcc for native compilation on the Gumstix The Gumstix has also been configured to automatically set up an ad hoc WiFi network on bootup complete with a DHCP server that allows for easy connection from a development machine All changes made to the Gumstix kernel and configuration have been documented and included in Appendix II and III Additionally the physical connections required for testing the SPI connection from the Gumstix to the PIC and the RS 232 connection from the laser rangefinder to the Gumstix have been soldered to the appropriate through hole pins on the Summit expansion board A communications protocol designed for the SPI connection between the Gumstix and the PIC dubbed the PICstix protocol has been designed and is included in Appendix IV SPI communication between the Gumstix and the PIC is still under development Such low level communication between a Linux kernel and an embedded microcontroller is proving to be difficult to implement On the Gumstix the connection is implemented in software using the spidev protocol driver which is included in the Gumstix kernel
12. and available once SPI is enabled The unimplemented items for the Gumstix include the direct interrupt request line to the PIC the connection from the cameras to the Gumstix and the implementation of the PICstix communications protocol The implementation of these items was omitted due to complications with higher priority items such as reliable SPI data transfer between the PIC and the Gumstix Early in the implementation process the Gumstix was discovered to be a temperamental device While it works well enough once it is set up correctly setting it up can be difficult and much of its SE See documentation is written by users with considerable amounts of experience with such systems Issues encountered included e Failure to boot with factory installed image e Difficulty connecting to Iowa State s WiFi to download packages e Failure to set up a stable gcc installation with the Gumstix s package manager e The need to rebuild the kernel to support SPI e The overlooking of the non standard 1 8V logic level on the GPIO pins All of these issues have since been resolved 4 1 2 PIC Implementation The final choice for the microcontroller to be used in the system is a PIC32M X795F512L This PIC has been received in the form of a plug in module PIM that can be used with the Explorer 16 development board A PicTail daughter board is used with the Explorer 16 to bring out the pins necessary for the PIC s SPI PWM and sonar connections
13. 1121314151617 1819202122 23 24252627 282930 31 32 33 34 35 36 37 38 39 4041 42 43 44 45 46 Actual distance using yardstick inches Please see the Gumstix testing section for details on testing the SPI connection from the PIC to the Gumstix 5 2 Sensors Testing 5 2 1 Laser Range Finder Testing In the initial plan as per our design document submitted last semester the obstacle detection module was to be tested on the autonomous system by introducing obstacles at different sides and comparing the output of the module 0 1 with the desired answer obstacle present not present a binary value that can be encoded as 1 and 0 respectively Since the platform itself is not being controlled by the pic or gumstix yet the test plan shifted a little bit from our original plan The test was run without running the module on a flying platform Although it is very likely that the vibrations on the platform due to flight and the noise in motion might introduce more errors in the algorithm the goal was to first test this on a stationary system 39 Page The following table demonstrates the results of the test Number of trials in each unit 15 IM True Negatives False Positives False Negatives Left 14 28 85 71 Right 100 O B 64 28 Front 98 4 1 6 28 571 71 42 Average 99 46 0 5 26 19 73 81 Table 5 2 1 a Testing Results for Laser Range Finder Obstacle Detection Module The following is an example of the output on the con
14. 2640 Fax 515 294 3262 mnelson 1astate edu 8 1 3 Student Team Information The ECpE 491 Senior Design Team website is located at http seniord ece 1astate edu may 1 1 10 This site will be updated as the school year continues The team members are 45 Page Mazdee Masud Iowa State University Electrical Engineering 131 N Hyland Avenue 14 Ames IA 50014 319 431 5804 mmasud 1astate edu Anders Nelson Iowa State University Electrical Engineering 504 1 2 Lynn Avenue Ames IA 50014 515 447 8359 anelson7 1astate edu 8 2 Closing Summary Mathew Wymore Iowa State University Computer Engineering 1019 Delware Avenue 17 Ames IA 50014 641 295 5522 mlwymore iastate edu Kshira Nadarajan Iowa State University Computer Engineering Ames IA kshira90 1astate edu The IARC is an exciting challenging and educational opportunity for its participants Prize money aside Iowa State University and the SSCL stand to gain good reputation if their team fields a competition worthy vehicle This project is an integral part of such a vehicle The proposed design has been carefully crafted to meet the requirements set forth by the competition rules as well as the constraints imposed by the physical platform Furthermore the design has been created with expandability and usability in mind Although we were not able to create a full competition worthier vehicle the ground work that has been laid is done with the hope of futu
15. 3380 mm nale 17 939026 Fig 4 2 1 d Urg Viewer Tool and its visual output 4 3 Power System The power system is the main source of operating all the equipment in the autonomous UAV The main focus is using a LiPo Lithium Polymer Battery This battery will be used for three reasons e High charge discharge efficiency e Lightweight e Adaptability to a wide variety of packaging shapes and ruggedness The power system will be powering the On Board Micro controller the motors of the quad copter the IMU the Sensors and the camera The block diagram in figure 4 3b shows a view of what the power system connects to The LiPo battery that we are using 1s two 3 cell packs with 11 1V voltage 3200mAh capacity and 20C maximum for the continuous current output The batteries will be connected in 3s2p to get 6400mAH capacity The system we are getting for the battery is Parallel Pack This is a form of combination pack that has the similar specifications as the serial packaging Also it will have all the advantages as the serial packaging In this form of packaging 3 single cells will be combined again to form a 3 cell package Again 3 single cell packs or 2 cell and 1 cell pack will be combined Every single cell will have the same voltage i e 11 1 V but the capacity of them will be different and it will be combined to get 6400mAh with a 20C maximum continuous current 36lPage Hi hs nec Di a Figure 4 3 a Image of LiPo
16. 9 28 27 5 43210 Main Control This instruction is used to alter the PIC run state as designated Main Control Opcode 00001 Run State Codes Normal Operation 0x00000F Simulate Self Destruct OxX0000F0 Shutdown 0x000F00 Reset OxO0F000 Lead Run State Designation Opcode 56lPage 3 30 29 28 27 5 43210 NOTE Host opcodes 0011 and 0000 as well as all opcodes with a leading 1 are currently reserved Device Instructions All of the following instructions are sent from the PIC to the Gumstix Data Response These instructions are sent as responses to the Gumstix s requests for data from the PIC Data Response Opcodes Altitude 00100 Lead Distance signed fixed cm Opcode 3 30 29 28 27 15 14 5 43210 Roll 00101 Pitch 00110 Yaw 00111 Lead Distance signed fixed deg Opcode 3 30 29 28 27 15 14 5 43210 Acknowledge Update These instructions are sent to the Gumstix to confirm that a command has been received or to report on the execution of a command The data format for acknowledge update instructions is composed of two parts the command being acknowledged or updated and a unique integer called the command ID When the PIC receives an instruction it decodes the command contained in the instruction and assigns a command ID to the command beginning with O and incrementing with each command up to 262 143 The next command ID after the maximum is 0 Data reque
17. Aerial Vehicle 4 Page 1 Introductory Material 1 1 Executive Summary The team will be working on developing the electronics on an autonomous unmanned aerial vehicle UAV for use in the International Aerial Robotics Competition This competition involves using the vehicle to penetrate and navigate an office environment to complete tasks outlined in the competition rules Our team will be working with the Space Systems and Control Lab SSCL of Iowa State University as well as two multidisciplinary senior design teams from other departments The other two teams will be in charge of developing the platform on which to put the control electronics and designing the controls including navigation algorithm and vision system The SSCL will act as an advising element to the senior design teams and will be providing the funding for the development of the project While designing the electronics of the platform we conducted research into past competitions and competitors and we considered several possible solutions In this document we will be describing the decisions we made in choosing the optimal solution for the various problems and its subsequent implementation Our design consists of five main modules that will be described later in this document The general outline is that the UAV will use sensors such as a laser range finder and an inertial measurement unit IMU to collect the data to be used by the microcontroller system to be used in the stab
18. Page 7 Lessons Learned 7 1 Importance of Communication This senior design project was extensive There were 3 senior design teams all working on this one project Finding the correct level of communication was very difficult Although staying in touch with what the other teams were doing sometimes the detail at which it was discussed proved to be detrimental to the accomplishing of the work For example at the start of the second semester new people were added to the project in the form of a new Engr 466 team later the Controls team and the PhD student Koray mentioned previously in this report With the new people came new ideas We spent the first few weeks going over the design decisions of the past semester and fielding the different thoughts and visions that came up In the end only the PIC version changed with all the rest remaining the same However this took much time that could have been spent actual implementation Just like too much too little can also be a bad thing Differing visions of the system and styles of implementation can lead to the But I thought sentence started that means something went wrong in communications For our team communication was a large problem both too much and too little With so many people all working on different yet related things communication had to be good to make it all work out as planned We learned that communication was the most important part of our project Unfortuna
19. aids may be used external to the designated flight area It will be assumed that these navigation aids were positioned by a mother ship around the building but not on top prior to a aerial robotic sub vehicle launch The navigation aids must be portable and must be removed once the team leaves the competition area GPS is not allowed as a navigation aid D D D e D a ays ZS CY I C TY C C C1 a AL a a ANC aia ZS ava a a LAT Y LA e LI LI UN y Vas v y y A U y w V L Li L uw i V C y v U y y Q De C a amoto A Amn a ALE D DLC vr be none C C v 5 oett D 5 Vid UVulecJzXWXV32 Di 7UvCcOCOTIT VV 2 To D D D L D D D nlied a min ing A ATOTO a a ATnhnea LO arma LA IJ WV Kl Li LA LA eg L4 a a aa ava aa U Vv LA y LL Y Aw J 4 aL WI UT CUYO 9 LU D a CLC nara a AA Aen mq Q Cl a Ane Q a y y U vv SAS y U ye L LI L y D Q amana a CY 13 AO C cT CLC Q CY I4 aa AO a a nara a ava a y U Y y VY LA LA UN LL y y LIN LI v y y y y Y v dis SE entering the arena under autonomous ee end ES e must remain within the bounds of the arena or the attempt will end Vehicles leaving the arena or in the Judges opinion are about the leave the arena will have their flight terminated by a Judge Flight termination actuation will be controlled by a Judge not the team Each team will supply the designated Judge with its manually actuated kill device as they enter the arena prior to their attempt s and must demonstrate that the ki
20. are not determined through mapping the platform will provide an API to such an algorithm that will now be able call our functions as long as it provides key information parameters like speed and direction of motion 2 Heading This module will be implemented on the main on board controller on the robot It acquires information from the positioning system and sends commands to the motor controller 3 Motion Controller This is the module which controls the motors to achieve the desired speed motion The feedback about the percentage thrust achieved from this module is also sent to the heading module 4 Dynamic Stability Control Module This module uses the data from the internal sensor consisting of the inertial unit to maintain stability of the robot It is also possible to integrate information from external sensors like range detection units such as the IR to combine the stability control and the obstacle avoidance but we wanted to modularize our design to minimize interdependence 5 Obstacle avoidance module This module reads the current sensor data and identifies 1f there 1s any obstacle to avoid If there is the system is sent back to the motion control state where the motion parameters are re calculated based on odometry information If there 1s no obstacle then the system returns to positioning with a Final Met feedback Here is a graphical view of the software block diagram consisting of all the modules mentioned abov
21. be picked up by another team after this year to expand it to the full autonomy required for the competition 5 The parts and components that we have agreed upon shall integrate into the system without any major compatibility issues 6 The resolution of the inertial unit and other sensors will allow for adequate accuracy in implementation of complex obstacle avoidance algorithms 7 Page 1 6 2 Updated Limitations List 1 The delivered platform will not be able to perform object recognition but it will enable future addition of an object recognition system 2 The robot will not be able to bear any additional weight other than the on board components 3 The robot will not be able to hover or stay powered beyond a time period of 12 minutes if the need for such a situation arises 4 There will be a single robot platform developed and there will be no backup structure 5 After the first semester major changes in the platform itself will not be easily possible 6 The team has limited time for implementation due to other course studies 1 7 Expected End Product and Other Deliverables The deliverable for this project 1s electronics for a quadcopter that 1s capable of stable flight obstacle avoidance and remote termination in case of emergency The platform will also be easily expandable to enable autonomous navigation The steps taken to ensure ease of expansion have been indicated in our design decisions choice of sensors and the
22. before We have learned a great deal through this project but we still have much we would have liked to be able to do But we set ourselves up to do more than we had time to do It reaches appoint in which we had to select with the help of our advisor what the most important items were to have for future teams Although we didn t complete all we planned to do we learned how to prioritize to the things we could do 44 Page 8 Closure Material 8 1 Project Team Information 8 1 1 Client Information The client for this project is the Space systems and Controls Lab This is a multi disciplinary lab in the aerospace department at Iowa State University which runs multiple projects such as High Altitude Balloon Experiments in Technology CySAT Cyclone SATellite cubesat project and the Mars Analog Vehicle for Robotic Inspection amp Construction The Director of the Lab is Matthew Nelson and he is also the Advisor for our team The contact information for the client is Space Systems and Controls Lab 2362 Howe Hall Ames IA 50011 2271 mnelson iastate edu 515 294 2640 8 1 2 Faculty Advisor Information Our faculty advisor is Matthew Nelson the Director of the Space Systems and Controls Lab His contact information 1s Chief Design amp Operations Engineer Department of Aerospace Engineering Space Systems amp Controls Laboratory 2271 Howe Hall Room 2331 Iowa State University Ames IA 50011 2271 Office 515 294
23. cell and 1 cell pack will be combined Every single cell will have the same voltage i e 11 1 V but the capacity of them will be different and it will be combined to get 6500 mAh with a 20C maximum continuous current From these options the parallel pack was the best option Taking a recommendation from Koray it was decided to wait until the platform was completed before batteries were selected As such we would be able to measure the exact current draw of the system and so choose exactly the capacity that would be needed to provide the flight time that is desired 224 Page 3 Resources and Schedules 3 1 Resources Requirements 3 1 1 Personnel Effort Requirements The requirements in labor that will be used for this project can be broken into 3 main sections The sections of labor are in Documentation Design and Implementation These sections can each be further divided into subtasks that must be accomplished for the overall project The tables below list out how the tasks were estimated to be split between members of the senior design team as well as the totals for each section of labor Documentation Expected Labor Table 3 1 1 a Documentation Expected Labor Project Plan Plan Presentation Design Document Design Presentation Final Documentation Anders Nelson 10 10 28 30 1 Mazdee Masud mEmT P E NE MathewWymore sof 10 ts 29 Kshira Nadarajan e of ss of 3s Design Expected Labor Tab
24. ch Considerations The testing will contain several different approaches They are the following e Communication This test is on the communication between the platform and the remote base station The distance and the speed of communication will be tested e Integration This test is to determine the proper connections have been made and communication between components is fully functioning e Obstacle avoidance This is the test on the sensors The reliability and the accuracy of obstacle avoidance will be tested from the movements of the platform in various directions e Endurance Power this is the battery testing The battery will be run under expected load and voltage over time will be monitored during testing 2 2 Detailed Design 2 2 1 Software System The software system consists of modules that run of different controllers but work in unison to provide the end user a friendly API Currently the software system consists of the following modules Positioning System This system serves as the part of the navigation block that will be used for single waypoint navigation This will be implemented on the base station controller The positioning module will eventually require an implemented Simultaneous Localization and Mapping Algorithm but our end deliverable will only issue basic commands directing the robot to move in a given direction for a given distance or speed The current position and the desired lOlPage final position
25. challenge within the scope of the senior design project is that we have to design and build the on board electronics and power systems for a platform that will fly autonomously and implement obstacle avoidance and stability control 1 3 2 General Solution Approach Our solution to this problem is to build a platform that will be able to make most of the important decisions required for sensor support communication and power management on board It will send information such as the range finder and image video data through a wireless link to a remote base station where the heavy computations such as localization and search algorithms will be implemented A control system shall be developed by the Engr466 Controls team which the base station will be able to wirelessly command the robot to move according to the instructions based on an API developed for this purpose This API will allow implementation of important mapping and search algorithms to enable complete autonomy The robot will be tested in a controlled environment where the behavior can be observed and improved It is to be noted that our platform will only enable the implementation of localization algorithms and serve as a functional platform but not implement it The following is the general system block diagram that indicates the components that we propose to implement Accelerometer IMU Ei On Board Microcontroller t Y VENE i Processing Figure 1 3 2 a Sys
26. control system the implementation of a remote manual kill switch Figure 1 3 2a is a block diagram of the initial high level system designed to provide that functionality I2 Page Note that the initial expected inputs of the on board microcontroller were an IMU and a sensor array including sonar and a laser rangefinder The expected output of the microcontroller was to the four motor controllers of a quadcopter and a wireless communications unit was expected to provide communication with the remote processing as well as kill switch and JAUS functionality The camera and vision system was expected to exist separately Using these I O requirements the following general design for a main control board was created Note that the camera was now being considered as a direct input into the microcontroller unit In later iterations the camera system was again made a separate component as it was considered out of the scope of this project Also a camera system is expected to require dedicated communication channels due to the high bandwidth and processing power required for transferring and working with video seyoums J035 amp gJauje jl ni indui jeues ul KL Microcontroller Main Control Board Figure 2 2 2 a Main Control Board Initial Design At this point the issue was raised that in general small microcontrollers do not have the USB host capabilities that would be needed for a USB laser rangefinder The team was relucta
27. d into the Gumstix use vi file path If you are unfamiliar with vi it is a text editor that runs within the shell It does not support mouse clicks Press i to enter insert mode so you can edit the file To exit insert mode press escape Commands are entered preceded by a colon Type w to save or q to quit Use q to quit and discard unsaved changes Since vi does not echo changes immediately developers may wish to edit source files on their development machine and use scp to transfer them to the Gumstix You can use gcc to natively compile programs on the Gumstix Gcc was included in the latest version of the rootfs flashed to the Gumstix The documentation for gcc can be found on the Internet or entering man gcc into the terminal of the development machine Note The Gumstix kernel does not include manual pages so the man command will not work from within a Gumstix session 53lPage Finally when youre finished with the Gumstix always shut it down properly Connect to the Gumstix and enter shutdown now Wait at least five seconds then you can safely unplug the power from the Gumstix board NOTE The PICstix protocol has not yet been implemented and is provided as a resource and suggestion for future teams 54 lPage 8 4 4 Appendix IV PlCstix Communications Protocol Overview The PICstix Communications Protocol in the scope of our project is used to define the serial communications between the Gumsti
28. e lllPage POSITIONING Paikan L 4 Kin SOFTWARE SYSTEM FLOW CHART m j COMMUNICATION MODULE BACKUP COMMUNICATION LINK TO MOTOR CURRENT FEEDBACK CONTROLLER POSITION WITH TARGET PERCENTAGE KILLSWITCH POSITION amp THRUST ACTIVATION MOTION TARGET STOP la A NEW TARGET POSITION amp MOTION PARAMETERS MOTION CONTROL RE ere eS OBSTACLE AVOIDANCE 4 j f D d INTERNA E 4 SENSOR RANGE SENSOR DATA IMU DATA Blue color fill indicates independent module on main platform Continuous line indicates process done on main on board controller mr T K ees Dotted line indicates that the OBSTACLE OBSTACLE PRESENT process is carried out by the Base DYNAMIC STABILITY DETECTED Station controller CONTROL PM Dashed line indicates that the loc process is carried out in the motor controller NO OBSTACLE Figure 2 2 1 a Software Flow Diagram 2 2 2 Control System Controllers The control system is the brains of the autonomous UAV The control system has three main functions e It uses sensor data to provide flight via the motor controllers e It provides a platform for executing autonomous actions needed for the competition e Itcommunicates with the base station accepting command decisions and providing data useful in making those decisions In addition the control system supports manual flight via a hobbyist RC
29. ed to go with the Hoguyo URG 04LX Laser range finder Logitech C905A webcams and MaxSonar EZA with serial interface The Hoguyo URG 04LX range finder was selected for its large field of view and the capability to interface with either USB or RS232 interfacing The field of view 1s a sweep of 240 degrees with a 4 meter range This large area sweep is necessary for a robust navigation algorithm and easy collision avoidance The webcams were a recommendation from Koray From his past experience using vision systems on RC helicopter navigation the Logitech C905A webcams are light have high resolution and can auto adjust through circuitry on the camera The EZ4 sonar was selected due to its output through a serial connection This eliminates the need to do analog to digital conversion and also send a ping to the sonar that many systems require This part lowers the complexity of the connection that much further and saves time in programming 2 2 4 Power System The power system is the main source of operating all the equipment in the autonomous UAV The main focus is using a LiPo Lithium Polymer Battery This battery will be used for three reasons e High charge discharge efficiency e Lightweight e Adaptability to a wide variety of packaging shapes and ruggedness The power system will be powering the On Board Micro controller the motors of the quad copter the IMU the Sensors and the camera The block diagram in figure 1 3 2a shows a view of what
30. er on the Gumstix to make connecting to it easier To do this create etc udhcpd conf with the contents start 192 168 2 3 end 192 168 2 254 interface wlanO max leases 64 Use this command to run the DHCP server udhcpd etc udhcpd conf sdmay11 10 Finally set the DHCP server to run on bootup by adding the following lines to etc rcS d S40networking after echo n Configuring network interfaces ifup a echo done echo n Starting DHCP server udhcpd etc udhcpd conf echo done Creating and deploying a new build The Gumstix kernel and rootfs source can be downloaded modified and rebuilt using OpenEmbedded Instructions for obtaining the Gumstix source can be found at http gumstix org access source code html To deploy a new build you will need a bootable microSD card Instructions for creating one can be found at http gumstix org create a bootable microsd card html A bootable microSD should also be included with the AngelStrike project materials The images for the new build need to be copied to the microSD card Instructions for doing this are included on the page for creating a bootable microSD card 50 Page Finally you can flash the images on the microSD card into the Gumstix s nonvolatile memory using a script as described at http gumstix org how to 70 writing images to flash html gcc You can try using opkg to install gcc with opkg install task native sdk However this method has been fou
31. iagram Figure 4 2 1 b Visualization of range scanning Figure 4 2 1 c Laser Range Scanning Resolution and Area Coverage Figure 4 2 1 d Urg Viewer Tool and its Visual Output Figure 4 3 a Image of LiPo Battery Figure 4 3 b Power System Block Diagram Figure 5 1 2 a Sonar Range Testing List of Tables Table 2 2 2 a Hardware Options Scoring Table 3 1 1 a Documentation Expected Labor Table 3 1 1 b Design Expected Labor Table 3 1 1 c Implementation Expected Labor Table 3 1 1 d Labor Totals Table 3 1 2 a Components Estimate Table 3 1 3 a Financial Summary Table 5 2 1 a Testing Results for Laser Range Finder Obstacle Detection Module 3 lPage List of Symbols C capacity of a battery kg kilograms unit of mass LiPo Lithium Polymer a type of battery mAh milli Ampere hours unit of electric charge V Volts unit of electromotive force List of Definitions 466 team a team of mechanical and aerospace engineers responsible for creating the quadrotor platform API Application Programming Interface GPS Global Positioning System IARC International Aerial Robotics Competition IMU Inertial Measurement Unit JAUS Joint Architecture for Unmanned Systems MCU Microcontroller Unit RC Radio Control RF Radio Frequency SSCL Space Systems and Control Laboratory at Iowa State University TI Texas Instruments an electronic components manufacturer UAV Unmanned
32. ility and flight control In addition to these sensors we will also include a communication system to communicate sensor and control data to a base station that will process the computation intensive navigation and decision making algorithms 1 2 Acknowledgement We would like to acknowledge our advisor Matthew Nelson of the SSCL for technical advice and oversight In addition Koray Celik a PhD student in the SSCL was a major advisor for our team His experience in aerial robotics was a unparalleled source of experience all the teams on this project would have been lost without We would also like to acknowledge the Engineering 466 and 467 teams for their help patience and efforts on this project 1 3 Problem Statement 1 3 1 General Problem Statement The International Aerial Robotics Competition states in its mission that the main motivation behind this competition 1s to promote and push the research and implementation of efficient indoor navigation systems flight control and autonomy in aerial robots The problem is that the UAV must be Pace capable of flying autonomously 1 e without any real time human control within an indoor environment without the aid of GPS navigation techniques The robot will also be expected to complete a basic set of tasks such as identifying and replacing a USB drive as in previous competitions These tasks must be completed within ten minutes The robot must weigh no more than 1 5kg Our specific
33. le 3 1 1 b Design Expected Labor Software System Anders neson 10 A0 15 to 8 MazdeeMasud 10 tt dd a Mathewwymore 10 10 S A a s H KshraNadarajan 10 30 5 O d a Total Ts 5 25 200 Implementation Expected Labor Table 3 1 1 c Implementation Expected Control System On Board Programming Sensor Integration Power System Communication System Parts amp Integration Testing Final System Testing Seegen 0 Mazdee Masud 20 10 10 1 5 4 amp Je Mathew Wymore as 30 5 0 1 4 amp 160 KshiraNadarjan 15 30 5 A 10 60 Total o o 70 80 a 25 30 tf a 640 Labor Totals Table 3 1 1 d Labor Totals Implementation Anders Nelson 60 50 160 Mazdee Masud 50 el 270 Mathew Wymore ei 50 el 270 KshiraNadarajan el a el mp 1080 SCH Page 3 1 2 Other Resource Requirements This section includes the items needed for implementing our project These are the electronic components for the platform This list does not include those items used for implementing the platform that was done by the Platform team Some items included are those that were intended to be bought but were recommended against buying so as to concentrate on other aspects of implementation Micr
34. le image Finally deploy the new build Other Gumstix resources http www jumpnowtek com http old nabble com Gumstix f22543 html 52 Page 8 4 3 Appendix Ill Gumstix User Manual Connecting to the Gumstix via console session See the documentation at http gumstix org connect to my gumstix system html Connecting to the Gumstix via WiFi Plug in the Gumstix and give it time to boot If it was properly shutdown last time it should set up an ad hoc network called gumstix network Use your computer s wireless utility to connect to this network You should be automatically assigned an IP similar to 192 168 2 3 with a subnet mask of 255 255 255 0 If not try setting your IP manually Once the WiFi connection is established use ssh to connect to the Gumstix ssh root overo local If you get a warning about adding an RSA key to the list of known hosts type yes If you get a warning about the host key conflicting with the current known key that is probably due to a reinstallation of the Gumstix kernel The previous known key for the Gumstix should be able to be removed using the command ssh keygen R overo local Once you are connected to the Gumstix you will find that there is currently no password To get back to your local machine use exit To get a file from the Gumstix to your local machine use scp root overo local file path lt destination path gt Using the Gumstix To edit a text file when you re logge
35. ll switch 1s functional for the Judge Either separate kill switches can be provided for each vehicle in multiple vehicle swarms or a single kill switch that disables all vehicles in the swarm simultaneously is deemed acceptable 8 The ground station equipment other than the optional navigation aids manual kill switch mechanisms and Judges FAUS compliantterminalinterface must be portable such that it can be setup and removed from the arena quickly A suggestion would be to setup the equipment 48 Page on a roll cart similar to that shown in Figure 1 Figure 1 Roll Cart Operations Teams will be given four 4 flight attempts The team with the highest static judging score will be given one 1 additional attempt Each team will be given 15 minutes to setup their system and adjust parameters If the team is unable to launch an aerial robot within the 15 minute window the attempt is forfeited Each team 1s granted one 1 pass Once a set of attempts has been completed by a given team the entire team will be required to leave the arena No hardware may be left in place During the static display of the vehicle s the vehicle s will be measured to verify the 1 meter maximum dimension constraint The vehicle s in takeoff configuration will be weighed to verify the 1 50 kg maximum weight restriction The vehicle s will also be examined to assure that all kill switch functions are fully operational prior to flight Competition A
36. m Te uone1uasa4g Vejd Ye ot0z 9 6 uejd Paloig 0107 0 8 suoday Ayaan TTOZ E 8unsa jeu TTOZ OT T Sunsa jemu TTOZ L E sjuaunsn py jeuly Hoz 8z c 340AN1JOS UOEHUNWWOD TiOz E uopensuowag 148113 arduis TTOZ TZ Z BEMYOS uon ajaq Go TIOZ L asemyos Junaanaue Jeg TTOZ T T 3Je1j0 VON GEIS 10814 TTOZ TE T uoneueuisdui SUOHEIUNUAUO TTOZ LT T uoneiueuirajdui osuas jeulra1x3 uoneuawadu YAMASI uonequeurejdui 43j 0J300904J21A uonequausajdui nil uonejuaua duu uejsAG Jaog suiei8erg xoo g BIEMYOS uonuya wajqosd uonezijeniu 25 Page On this schedule it is important to make note that this is the original schedule for the setup from the first semester After the new team came on board second semester different priorities were changed For example basic maneuvering and flight stability became part of the new Engr 466 Controls team Thus it is no longer a viable part of our schedule Even removing such items our schedule slipped much during the second semester The first several weeks were spent bring the new team up to speed defining roles of the teams reevaluating decisions and so on Some of these items causing the change in the original schedule plan are included in the implementation section below 26 Page 4 Implementation 4 1 Hardware Implementation 4 1 1 Gumstix Implementation The Gumstix module is composed of a Gumstix Overo Fire computer on module unit
37. nd to be unreliable A better method is to include gcc in the rootfs build Assuming you have OpenEmbedded set up on your system you can do this by editing org openembedded dev recipes images omap3 console image bb Add this line in the tools section task native sdk Then rebuild the image using bitbake omap3 console image SPI To enable spidev for use in connecting with the PIC you need to disable the SPI devices built into the kernel by default This section assumes you have OpenEmbedded set up on your system Please note that version numbers may change The devices can be disabled by editing the board overo c file First navigate to the file cd overo oe tmp work overo angstrom linux gnueabi linux omap3 2 6 36 r97 cd git arch arm mach omap2 Make a copy just in case cp board overo c board overo c orig And edit board overo c A copy of the edited version of board overo c has been included with the AngelStrike project materials Then from linux omap3 2 6 36 r97 make a patch file git diff no prefix git arch arm mach omap2 board overo c orig git arch arm mach omap2 board overo c my board overo patch Now edit the bitable recipe to use the patch Open overo oe org openembedded dev recipes linux linux omap3_2 6 36 bb In the SRC_URI declaration add the line file my board overo patch SllPage Then rebuild the kernel and rootfs bitbake c clean virtual kernel bitbake virtual kernel bitbake omap3 conso
38. nt to exclude the possibility of a laser rangefinder for use in navigation and mapping by future teams and the project advisor agreed While small laser rangefinders using the RS 232 communications interface do exist the team found that such lasers are more expensive models selling for approximately 1000 more than the USB model the team had found In the interest of budget and expandability the team decided to require the system to support a USB laser rangefinder I3 Page This decision became crucial to the microcontroller system design System on chip computer on module options were now considered with the other option being a smaller microcontroller with USB host capabilities such as the TI Stellaris At this point the following three high level system options were proposed Option 1 System on chip PWM UO Pins IMU serial 8 16 bit PWM MCU Parallel ar Serial Parallel ar Serial Gumstix Linux SoC Shaded components are outside the scope of this design Digital out IMU is assumed Analog IMU may be used with minor alterations Power high Weight high Expandability medium 0 Flexibility high Usability high Overkill high Price high Comments Seems unnecessary given advent of full host MCUs Figure 2 2 2 b Option 1 System on chip I4 Page Option 1 featured a system on chip module that could run Linux connected to a smaller microcontroller
39. o Battery powered o 10 minutes minimum flight time 12 minute goal Four brushless motors at 11V Electronics systems e Operational o Able to handle onboard stability control o Wireless base station communication Wireless link capable of at least 42 meters e Expandable o Potential for navigation in a GPS denied environment Connectivity for laser range finder Considerations for computer vision system o Potential for executing remote autonomous commands o Connectivity for manual remote kill switch o Connectivity for wire burn USB stick drop off system 2 1 3 Design Constraints e Compatibility o Must integrate into Platform team s vehicle platform o Must potentially fulfill competition requirements e Time o Deliverables due in May 2011 o Team has other time consuming obligations e Experience 9 Page o Team has limited design experience o Team has limited implementation experience o Budgetis supplied by SSCL o Budget is not definite but definitely limited 2 1 4 Technical Approach Considerations and Results The design of the systems of the platform will be simulated and analyzed The results of each simulation will determine the designs and specs that will be considered The considered design will be approved and then it will be implemented to get the prototype The prototype will be tested further and follow the testing approaches Upon passing all the testing the final platform will be delivered 2 1 5 Testing Approa
40. ocontrollers Gumstix Overo Fire 219 00 Gumstix Summit 49 00 PIC32MX795F512L PIM 25 00 Sensors Hoguyo URG O4LX Laser Range Finder 2 350 00 Maxbotix MaxSonar EZ4 Sonar 29 95 29 95 Analog ADIS16400 IMU 417 00 417 00 Logitech C905A Webcam 52 99 105 98 Miscellaneous 5V US Power Adapter 10 00 10 00 CLM 112 02 LM D A Connector 12 91 12 91 Estimated PCB cost 45 00 45 00 TOTAL ESTIMATED COST 3 263 84 Table 3 1 2 a Components Estimate 3 1 3 Financial Requirements The following is the summary of the financial requirements for this project This is based on a labor cost estimate of 20 per hour Financial Summary Table 3 1 3 a Financial Summary CostSource Hours Costper hour 1080 20 21 600 Components 3 264 24 864 Project Total This total is without the cost of the platform designed by the Engr 467 Platform Team or the future items that may be needed to develop this project further 24 Page 3 2 Schedules Figure 3 2 1 a Project Schedule 3 2 1 Project Schedule E A e epes 000 eee M se e m pi EE Ier neon emm meti E ee Ier eem CB Je e Fe Le Fe ll BEE EIER Di t10z 8t P HOz Tz nm TIOZ Z E o A Pmirme EE EE rt D ee e po Uwe sse m ee o aaa la Je e EE EE DE El EE Li eem mem eg e EE repens mm o emm EE EE see iti i l e Rn ns Loo me omm oom oom Do om oom lo om LT om
41. ote Base Station Vision Data fram Gumstix Opency gt Detect Signs Calculation of location eatimate in X and Y No continue processing Inge Images Sign Detacted OR Target Reached Yes change pasilion target Main Motor Control Loop PIC32 Obstacle Avoidance A Heading Madule Gumstix Liltrzas aud Sensor Data Depth Sensing Laser Range Currant Position Finder uin Estimates Trem Radio Beacon Madule Obstacle Detectia Target Calculation based on outputs of vision input current position and obstacle Stability Control Mechanism avoidance routines Motion Commands Target positon Speed Yaw Pitch Roll KILLSWITCH TERM IMATION Motor Cantrolar Stability Control Lomp hAaboar Feedback Fig 4 2 1a Overall System level Software Implemented by us Implemented by other Block Diagram including obstacle detection module teams Uncolored Unimplemented Viible Ranging Area Blind Region 34 Page 4 Interface with other modules The obstacle detection module was designed exactly to the specification of the navigation module implemented by the controls team The algorithm implemented by them is a Follow the left wall algorithms The mission of the robot in the competition is to detect a USB drive and replace it with a decoy a searching task During the large group mee
42. overall physical structure of the platform For example the processor has USB host capabilities to allow for the use of devices such as laser range detectors and portable camera and vision sensors The chassis also has been designed to accommodate the weight and volume of the laser range finder This platform will hold power for at least 12 minutes while operating in an indoor environment The electronics will be able to interact and take in data as required by the system The robot will be able to communicate with a base station which will receive sensor data and send back navigation commands A complete documentation manual along with the detailed API specifications will be provided to the client for ease of control through the base station The API will specify functions required for the base station to command the robot to take necessary decisions through a wireless RF communication link 8lPage 2 Approach and Product Design Results 2 1 Approach Used 2 1 1 Design Objectives e Design the onboard electronics and power systems for an autonomous unmanned aerial vehicle capable of competing in the IARC e Design the basic onboard software for the abovementioned UAV e Design systems that can be integrated with the vehicle platform designed by the Platform team e Design systems that can be expanded as part of a competition worthy UAV by a separate team 2 1 2 Functional Requirements e Lightweight o Entire platform under 1 5kg e Low power
43. ption on the Gumstix and also reserve the USB host for other sensors like cameras Since the URG works at 5V and the Gumstix IO pins read at 1 8V some additional circuitry was to be added later to adjust the communication channel A circuit was built using the Sipex 232acp chip was used to pull down the voltage and enable communication at the TTL level but since this chip was designed for pulling down the voltage to a range of 2V 4 V the communication with the Gumstix serial pins were not possible A PCB design has been created in which this issue is addressed For testing the software the Urg was just connected on plug and play mode with a laptop computer running 32 bit Linux 3 Obstacle Detection Software The algorithm for obstacle detection module is described in the following section Algorithm 1 For each lt angle range gt pair a Calculate the absolute distance relative to the center refer to Fig 1 2 Distance cos 90 angle range b If distance lt 2m amp amp distance gt 1m probabilityOfObstacle 2 distance 1 Since the probability that it is an obstacle is weighted based on how close it is c If distance gt 2m Not considered an obstacle probabilityOfObstacle 0 0 3llPage d If distance 12m Surely an obstacle probabilityOfObstacle 1 0 e cumulativePrediction cumulativePrediction k m m k m probabilityOfObstacle This step is based on the Impulse Response filter of the form
44. re in a system similar to Option 1 became the highest scoring option 17 Page Meanwhile a 16 bit PIC MCU from Microchip s PIC24 series was chosen as the flight controller Since many companies offer similar MCUs a PIC was chosen because of the SSCL s history of work with PICs allowing the team to tap into existing equipment resources and an experienced knowledge base The selected PIC fits its purpose well It features nanoWatt XLP low power technology and a wide variety of I O options including 25 remappable I O pins which will allow the team to accommodate for any sensors which may be connected to the flight controller for basic obstacle detection Additionally the PIC supports the major serial I O options for interfacing with the main controller and the IMU as well as five PWM channels for the motor controllers And the PIC has five input capture lines which can be used for processing signals from a hobbyist RC receiver for manual flight control The final iteration of the control system high level design is shown below New additions include the RC receiver and a heartbeat signal between the flight controller and the main controller This heartbeat will allow the two controllers to track each other s presence and take appropriate measures should either fail ISIPage Draft System Design Manual control Killswitch PWM Heartbeat Flight commands Separate Unknown Computer Vision System Optional Gumstix Overo
45. re teams completing the project We have learned valuable lessons through the design and implementation of this project It was an eye opening experience about the true nature of engineering within the limitations of the real world 46 Page 8 3 References International Aerial Robotics Competition IARC Site Association for Unmanned Vehicle Systems International AUVSI Web Retrieved 10 October 2010 lt http Aarc angel strike com gt Overo Fire COM Product Page Gumstix Corp Web Retrieved 2 December 2010 lt http www gumstix com store catalog product_info php products_id 227 gt Summit Expansion Board Product Page Gumstix Corp Web Retrieved 2 December 2010 lt http www gumstix com store catalog product_info php products_id 215 gt Powerizer High Power Polymer Battery Product Page BatterySpace com Web Retrieved 2 December 2010 lt http www batteryspace com Powerizer High Power Polymer Battery 11 1v 3300mAh 36 63 Wh 40A rate aspx gt ADIS16405 High Precision IMU Product Page Analog Devices Inc Web Retrieved 2 December 2010 lt http www analog com en mems imu adis 16405 products product html ppa_print_table gt 47 Page 8 4 Appendices 8 4 1 Appendix Competition Rules The following is an excerpt of the rules from the International Aerial Robotics Competition IARC Mission 6 outline Mission 6 is the current mission being held in August 2011 General Rules Governing Entries 1 Vehicles mus
46. rea The competition flight area arena will be constructed within an area that is approximately 30 m long by 15 m wide and 2 5 m high This area will be divided into a number of rooms and corridors with various obstacles of various heights The launch location will be fixed at a distance of 3m and oriented toward a 1 x 1 meter minimum opening into a corridor Navigation aids if used may be located anywhere in a 3 meter perimeter bounding the outside of the arena see Figure 2 A list of typical materials and construction notes which may be updated from time to time is provided at http Aiarc angel strike com IARC Arena Construction pdf so that teams can construct similar practice arenas for use in refining their aerial robotic systems prior to arrival on the Competition day 36m 33m 3m SES SS TUTOR AID PLACEMENT ZONE NOTE Internal wall and obstacle placement is purely notional Actual placements and numbers of rooms may differ No entry door will be less than 1 meter in width Figure 2 Arena dimensions and notional internal layout 49 Page 8 4 2 Appendix Il Gumstix AngelStrike Change Log WiFi gumstix net To set up an ad hoc network on bootup edit the Gumstix s etc network interfaces to include the following lines allow hotplug wlanO auto wlanO iface wlanO inet static address 192 168 2 2 netmask 255 255 255 0 wireless mode ad hoc wireless essid gumstix network Set up a DHCP serv
47. s of the platform and external sensors that take measurements of the environment around the platform The internal sensors category is composed of the inertial measurement unit IMU The IMUs looked at for this project were those with a minimum of 6 degrees of freedom This means that the IMU allows measurement of acceleration along each of the axis and measurement of rotation about the axis in 3 dimensions These work as feedback for stable flight control The IMU that was selected is a 9 degree of freedom IMU from Analog devices called ADIS16400 This IMU has temperature calibration on the device and a very high degree of sensitivity In addition speaking with Koray Celik a PhD student in the SSCL with extensive aerial robotics experience recommended this IMU very highly for our use This option serves the project well 20 Page The external sensors needed for this project would be a laser range finder for use in navigation 2 cameras for navigation and object recognition and sonar for altitude measurements The range finder and cameras were originally eliminated from our project scope since navigation algorithms and object recognition are to be implemented by later teams However at the start of the second semester a new Engr 466 team was added to our project They became the Controls team for the project and thus were able to add input into what sensors were needed for the project From their input and Koray s suggestions it was decid
48. small as 0 2 of this range 28 Page The unimplemented items for the PIC currently include the input from the IMU the direct interrupt request line from the Gumstix the implementation of the PICstix communication protocol the input from the RC receiver and the programming of the flight control loops The failure to meet these implementation goals stems from two main reasons The first major issue that delayed PIC development was that the PIC was upgraded from a PIC24 to a PIC32 approximately two thirds of the way through the semester This design change was made based on the recommendation of a project leader more experienced with aerial robotics systems From an engineering standpoint the upgrade provided significant performance increase especially for floating point calculations allowing more flexibility in the control loop programming Additionally the upgrade had nearly negligible changes on the power cost and weight budget At the time the upgrade was not expected to slow development much but in retrospect it did slow development considerably The second issue plaguing PIC development was the voltage difference with the Gumstix which caused many items to be ignored in the last weeks in an attempt to obtain reliable communications between the two controllers the system is based around 4 1 3 PCB Implementation A part of the circuitry needed for the overall system is to be implemented on a custom PCB On the PCB is the IMU
49. sole when there was an obstacle on the left hand side of the sensor 5 2 2 Sonar Testing Please see 5 1 2 paragraph 2 for sonar testing results as this is included in the PIC testing 5 3 Power Testing 5 3 1 Endurance Test The LiPo battery has some set of characteristics When the battery is new the output is not to the optimum level After few cycles of charging the battery the battery starts producing the output according to our desired level During this lifetime of the battery it starts to lose its capacity and after more cycle of charges the output continues going down The plan for now is to have two sets of battery One set for testing the flight of the platform other one is only for the competition The competition set will be used and charged few cycles to get the maximum output for the competition After the Platform team completed the platform near the end of the year it was possible to do a test on power draw of the motors while flying Using a simple RC controller batteries with known charge capacity were used to fly the quadcopter for as long as it could Using two 3cell LiPo 3200mAh batteries 40 Page with the platform weight at 1278g the platform was able to fly for 20min 52 sec The platform weight was slightly less than the possible amount of the competition but this gives a good estimate for us to use on the motor power draw It can be concluded that 2 standard 3200mAh LiPo batteries will be a sufficient
50. st instructions are not assigned command IDs The PIC then sends the command ID back to the Gumstix in the acknowledge instruction The same command ID is used when the PIC sends an update instruction to the Gumstix The basic acknowledge update format is 18 bits for the command ID 5 bits for the opcode of the host instruction being acknowledged or updated referred to as the command type and 5 bits for the opcode of the ackowledge update instruction Lead Command ID Type Opcode 3 30 29 28 27 10 08765 43210 Acknowledge Update Opcodes Command Received 01000 Command Update 01001 Command Executed 01010 57 Page Error Executing Command 01111 Autonomous Mode Acknowledged 00010 Manual Mode Acknowledged 00011 Normal Operation Acknowledged 00001 Self Destruct Acknowledged 00100 Reset Acknowledged 00101 Shutdown Acknowledged 00000 NOTE Device opcodes 0110 0111 and 1011 as well as all opcodes with a leading 1 are currently reserved 58lPage
51. t 1 3bits 10bits Ex 3 75 gt 00000000001 1 1 1 0000000 The idea here is to eliminate the need for floating point data to be sent between host and device Data with a whole part larger than 512 or a fractional part smaller than 0 1 is not expected but clearly supported Host Instructions All of the following instructions are sent from the Gumstix to the PIC Flight Control These instructions cause the PIC to adjust motor speeds and make the platform move Horizontal Motion Opcodes Forward 01000 Backward 01001 Strafe right 01110 Strafe left 01111 Lead Distance signed fixed cm Opcode 55 lPage 3 30 29 28 27 15 14 5 43210 Vertical Motion Opcodes Up 01010 Down 01011 Lead Distance signed fixed cm Opcode 3 30 29 28 27 15 14 5 43210 Rotational Motion Opcodes Turn right 01100 Turn left 01101 Lead Distance signed fixed deg Opcode 3 30 29 28 27 15 14 5 43210 Data Request These instructions cause the PIC to send a response with the requested data The data field is empty for these instructions Data Request Opcodes Altitude 00100 Roll 00101 Pitch 00110 Yaw 00111 0 Opcode 31 5 43210 Mode Switch This instruction requests that the PIC change operating mode as designated Mode Switch Opcode 00010 Mode Designation Codes Autonomous 0x00000F Manual 0x0000F0 Lead Mode Designation Opcode 3 30 2
52. t be unmanned and autonomous They must compete based on their ability to sense the semi structured environment of the Competition Arena They may be intelligent or pre programmed but they must not be flown by a remote human operator Any number of air vehicles may be deployed so long as the gross aggregate weight of each air vehicle does not exceed 1 50 kg 2 Computational power need not be carried by the air vehicle Computers operating from standard commercial power may be set up outside the Competition arena boundary and uni or bi directional data may be transmitted to from the vehicles in the arena however there shall be no human intervention with any ground based systems necessary for autonomous operation computers navigation equipment links antennas etc 3 Data links will be by means of radio frequencies in any legal band for the location of the arena 4 The air vehicle s must be free flying autonomous and have no entangling encumbrances such as tethers The air vehicle s can be of any type During flight the maximum dimension of the air vehicle can not exceed one 1 meter The maximum takeoff weight of the vehicle cannot exceed 1 50 kg The vehicle must be powered by means of an electric motor using a battery capacitor or fuel cell as a source of energy The vehicle must be equipped with a method of manually activated remote override of the primary propulsion system 5 A maximum of two 2 non line of sight NLOS navigation
53. tely we were not able to improve until it was too late to slow the loss of time 7 2 Full Team from Start As mentioned in the previous section we gained team members in the middle of the year At this point we lost valuable time defining the roles of the teams and catching the new ones up on the system we spend the past semester designing What would have been best would have been to have the full team at the start That way it would have been easier to say exactly who did what and know the thoughts of the full team on a solution before starting the actual design process We lost time when the newer members of the team joined 7 3 Attention to Detail As much as we would like it to be so components don t always work the way we want or expect them to For example the little detail of voltages The Gumstix takes in a voltage of 5V However it only outputs logic at 1 8V This small detail created problems for us when we looked at a communication channel between it and the PIC The PIC at 3 3V did not see the small voltages So this adds another 43 Page circuit to be included on the custom PCB In turn it means not being able to order the PCB when you may want Little details in a large project can slow it down 7 4 Too Much in Too Little Time This project was more complex than most of the other projects in senior design It required working with a large team working out a bunch of details and doing things we had never worked with
54. tem Block Diagram 6lPage 1 4 Operating Environment The operating environment will be based on the competition set up which imitates the interior of an office The environment will be completely indoors as the main objective of the competition is to achieve efficient indoor navigation There will not be external factors such as wind or rain since it will be completely indoors The robot will also have to navigate without the use of a GPS system The missions is intended to be a stealthy one so there shall be no human beings inside the actual office setting where the robot has to operate 1 5 Intended Users and Uses 1 5 1 Intended Users The system will be used by the SSCL team for the IARC competition 1 5 2 Intended Uses The system will have a specific purpose of doing the mission outlined in the competition i e getting inside the secured compound and retrieving the flash drive However the scope for this senior design team is to design the electronics platform to be capable of expansion without implementation of the systems that will make it autonomous mainly the object recognition and mapping systems of the base station 1 6 Assumptions and Limitations 1 6 1 Updated Assumptions List 1 The platform delivered to us by the 467 team will be capable of stable flight 2 No additional money apart from that provided from the SSCL will be required 3 No major change in the competition mission will take place 4 This project will
55. that would handle flight stability calculations and the output to the motor controllers This option was initially thought to be overly large and power hungry for the project Option 2 All in one MCU PWM I O Pins Serial 32 bit USB host MCU 1 0 Pins Expansion Pins Parallel or Serial Parallel or Serial RF Unit Shaded components are outside the scope of this design Digital out IMU is assumed Analog IMU may be used with minor alterations Power low Weight low Expandability medium 0 Flexibility low Usability low Overkill low Price low Comments MCU is doing a lot Major fail point Figure 2 2 2 c Option 2 All in one MCU Option 2 consisted of a single 32 bit microcontroller with USB host capabilities such as a TI Stellaris with a separate communication unit such as an XBee Although the smallest and most power IS Page efficient of the three options this option was considered too rigid with little room to expand an already busy microcontroller Option 3 Divide and conquer MCUs PWM UO Pins IMU Serial 8 16 bit PWM MCU Parallel or Serial Farallel or Serial Expansion 32 bit USB host MCU UO Pins Pins Parallel or Serial Parallel or Serial RF Unit Shaded components are outside the scope of this design Digital out IMU is assumed Analog IMU may be used with minor alterations Power medium 0 Weight medium 0 E
56. the power system connects to The LiPo battery that is considered ideal is a 3 cell pack with 11 1 V voltage 6500mAh capacity and 20C maximum for the continuous current output There are three main battery options for the quadcopter These options were e Single Pack In this pack the ideal battery that is considered will be in the form of one single pack It can be found off the shelf or it can be ordered with the required specifications The single pack 21 Page will consist of 3 cells packed together Since this 1s a huge pack with everything together the amount of space needed to fit it will be larger e Series Pack This is one form of combination pack to meet the requirement of the ideal package Here three separate single cell packs or 2 cells and 1 single cell pack will be combined This will be done by combination of the different packs to make it a 3 cell pack with 11 1 V combined from each of them The 6500mAh capacity will be same for all the separate packs with the 20 C maximum continuous current This form of packaging will help putting the three cells separately by accommodating them in suitable space on the platform e Parallel Pack This 1s another form of combination pack that has the similar specifications as the serial packaging Also it will have all the advantages as the serial packaging In this form of packaging 3 single cells will be combined again to form a 3 cell package Again 3 single cell packs or 2
57. tings this was discussed and chosen based on different considerations We worked closely with the other team for this and their algorithm required a discrete input Is there an obstacle on the left On the right In the front This was based on a certain minimum distance that could be adjusted but is currently estimated at 1 8m because the platform spans close to a meter and a clearance of 400 cm on either side was kept in mind This estimate can be further adjusted based on the sensitivity of the motor and the platform s motion behavior The obstacle detection module therefore is designed to give these outputs as required by the inputs of the navigation algorithm More on the navigation team s algorithms can be found in the manual of the Controls team s report 5 Urg Ctrl Library and Urg Viewer The Urg community online is very active and there is excellent documentation available online at http www acroname com robotics info articles laser laser html The urg viewer is a graphical toll kit which can be used to visually perceive the current readings of the laser range finder It 1s basically a capture of the range and bearing information projected in real time as the laser range finder is moved and is scanning This can be used as both a de bugging tool at the remote base station and also to study the behavior and noise patterns of the sensor Refer to Fig 4 2 1d for a snapshot of what this looks like 35 Page X 520 mm Y
58. x single board computer and the 32 bit PIC microcontroller The PIC is used for reading in IMU data and sonar data and outputting PWM signals used to drive motor controllers The PIC can switch between autonomous and manual flight control modes The Gumstix is responsible for assembling the data gathered from the environment and making macro control choices 1 e move forward x distance The Gumstix also uses a laser range finder to monitor obstacle proximity The Gumstix can quickly halt platform movement via an interrupt request signal to the PIC That signal is not part of the serial communications but will be discussed at the end of this document Details The PICstix protocol is designed for 32 bit word communication between the two controllers Each 32 bit word will be referred to as an instruction Instructions use little endian format The Gumstix 1s the host and the PIC is the slave device Instructions come in two categories host instructions from the Gumstix to the PIC and device instructions from the PIC to the Gumstix Instructions of both types use a 5 bit opcode defined as the least significant bits of the instruction The leading four bits are left at O In general the remaining 23 bits are used to carry data Lead Zeros Data Opcode 3 30 29 28 27 5 43210 Some of the data is sent in a signed fixed point number format with one sign bit 12 bits for the whole part and 10 bits for the fractional part signed fixed g
59. xpandability high Flexibility medium 0 Usability medium 0 Overkill low Price law Comments Divide and conquer lessens risk of catastrophic failure and makes for easier programming Figure 2 2 2 d Option 3 Divide and Conquer MCUs Option 3 was considered to be more favorable with the addition of a separate smaller microcontroller for flight stability and a 32 bit USB host capable MCU for sensor input and 16 Page communications with the RF unit This option would provide the advantage of sandboxing the flight stability allowing the UAV to stay aloft even if the main controller should fail Also the flight control unit could be programmed and then left alone aside from minor performance tweaks which would be a major usability boost for a future group implementing autonomous functionality with no knowledge of the flight control details While the team was initially in favor of Option 3 the project advisor encouraged further research into system on chip options Part of the reasoning behind this decision was that a controller running Linux would already have USB drivers hugely simplifying I O programming Further research indicated that many other elements including wireless communications power programming implementation and general expandability and usability would be simplified with a system on chip device running Linux Additionally the power budget indicated that the power required by the electronics

Autonomous UAV Final Report - Senior Design

Contents

Download Pdf Manuals

Related Search

Related Contents