A LabVIEW Based Autonomous Airship Flight Controller

MECH5030M Individual Project Report Team 23 Leo Rampen - 200406830 Supervisor: Dr. R. W. Hewson Examiner: Dr. H. M.
Thompson
Design of an Autonomous Airship Platform
26th April 2012
Design of an Autonomous Airship Platform

Control and Electronic Systems Design
Leo Rampen 2012 MECH5030M Aeronautical and Aerospace Engineering University of Leeds Woodhouse Lane, Leeds LS2 9JT
MECH5030M Individual Project Report Design of an Autonomous Airship Observation Platform
Leo Rampen
Supervised By:
Dr. Rob Hewson Prof. Martin Levesley Dr. Peter Culmer April 26, 2012
Leo Rampen
April 26, 2012
Abstract
There is a demand for aordable aerial observation capabilities across a number of sectors. The recent rise in low cost sensors and computer platforms allows the realisation of a low cost autonomous aircraft. This report details the design, implementation and testing of the control and electrical system of an autonomous airship. The report identies key work done in implementing and testing both a ight control system and the corresponding electronics for an autonomous airship. The use of PID feedback controllers for orientation, altitude and navigation is discussed and the results of simulating a waypoint navigation controller with dierent environmental conditions are demonstrated. The message sending process of a designed and implemented TCP and Wi-Fi based communication system is shown, and the content and format of the selected messages is given. A ground station concept making use of an interactive map is shown. The report goes into detail on the limitations of the sensing options, describing the fusion strategy used to mitigate these. Finally, the electronic circuit boards and electrical systems designed and built are described. The implemented ight control system is mostly functional. Simulation will allow the selection and validation of control constants. All the objectives that were initially set have been met to some degree, with those that are short waiting on nal system integration. Final system integration - the connection of all the components along the blimp envelope - will allow ight testing shortly.
ii
Leo Rampen
April 26, 2012
Acknowledgements
The achievements made during the course of this project would not have been possible without an exceptional eort by all the project team. Moving from design concepts to a working airship system in the time available has required consistent meetings, long design discussions and a great deal of hard work. The support and ideas of all the team members have made this possible. Team Members Joe Beaumont Davis Chamia Rhys Neild
The enthusiasm, advice and assistance of our three supervisors has been invaluable. Regularly meeting with us to explore our concepts and ideas allowed the project to get o the ground. Technical support from the supervisors has been hugely helpful in the design and manufacturing phase. Supervisors Dr. Rob Hewson Prof. Martin Levesley Dr. Peter Culmer
The assistance of our industrial sponsor, National Instruments, has been particularly useful. The hardware and support provided by the NI team aided us immeasurably. Industrial Advisors Hannah Wade - National Instruments
iii
Leo Rampen
April 26, 2012
Contents
1 Introduction 1.1 Report Overview . . . . . . . . . . . . . . . . . . . . . . 1.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . 1.2.1 Control, Navigation and Communication Software 1.2.2 Electronics and Electrical Systems . . . . . . . . . 2 Context and Literature Review 2.1 Flight Control Systems . . . . . . . . . . . . . . . . . 2.1.1 Summary of Existing Computer and Autopilot 2.1.2 Control Algorithms and Processes . . . . . . . 2.2 Navigation and Autonomy . . . . . . . . . . . . . . . 2.3 Communication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 3 4 4 4 6 8 8 9 9 9 10 12 13 13 14 14 15 15 17 17 18 19 21 21 21 22 23 23 24 iv
. . . . . . Platforms . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
3 Equipment and Software Used 3.1 Software Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Lab Equipment Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Hardware Used in Final Aircraft Design . . . . . . . . . . . . . . . . . . 4 Development of a Flight Control System 4.1 Orientation and Velocity Control Loops . 4.1.1 Flight Modes . . . . . . . . . . . 4.1.2 Testing and Simulation . . . . . . 4.2 Navigation System . . . . . . . . . . . . 4.2.1 Heading and Altitude Control . . 4.2.2 Navigation Simulation . . . . . . 4.2.3 Waypoint Structure . . . . . . . . 4.3 Communications Protocol Design . . . . 4.3.1 Low Level Protocol . . . . . . . . 4.3.2 Implemented Message Protocol . 5 Sensing and Actuation 5.1 Communicating with Sensors 5.1.1 Inertial Sensors . . . . 5.1.2 Ultrasonic Rangender 5.1.3 GPS Module . . . . . 5.2 Sensor Fusion . . . . . . . . . 5.2.1 Validation . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Leo Rampen
April 26, 2012 26 26 26 27 29 30
6 Electronic Systems Design 6.1 Power Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Circuit Board Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Aircraft Wiring Harness . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Conclusion 8 Future Work Appendices A Control System LabVIEW VIs B Test Interface Groundstation - LabVIEW VIs C Navigation Simulation - MATLAB Code D Sensor Fusion Validation - MATLAB Code E EAGLE CAD Circuit Diagrams and PCB Designs F Interactive Waypoint Selection Map Code
34 70 76 80 85 91
Leo Rampen
April 26, 2012
List of Figures
3.3.1 Images of the aircraft systems . . . . . . . . . . . . . . . . . . . . . . . . 4.0.1 The main components of the ight control system. . . . . . . . 4.0.2 The aircraft axes of rotation and standard co-ordinate system. 4.2.1 Stable simulation responses. . . . . . . . . . . . . . . . . . . . 4.2.2 Undesirable controller responses. . . . . . . . . . . . . . . . . . 4.3.1 The TCP communication component structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12 13 16 16 18 22 23 24 25
5.1.1 The I2 C reading process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 A single UART byte frame. The number of start and stop bits is variable. 5.2.1 The Direction Cosines Matrix complementary lter fusion method process 5.2.2 Integrated gyroscope (blue) and fused (red) orientations demonstrating roll axis divergence during small movements. . . . . . . . . . . . . . . . . . . 6.2.1 The three circuit boards designed and built. EAGLE schematics are included in Appendix E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 A top level view of the aircraft wiring diagram. . . . . . . . . . . . . . . E.0.1The breakout board PCB design for the GS1011 wireless module. . . . . E.0.2The design for a stripboard based IO pin breakout board for the sensors. E.0.3The design of the stripboard based servo breakout board. . . . . . . . . .
27 28 86 86 90
List of Acronyms
ADC analogue to digital converter AHRS attitude heading reference system CPP Contract Performance Plan ESC electronic speed controller FPGA eld programmable gate array HIL hardware in the loop I2 C Inter-Integrated Circuit
vi
Leo Rampen IDE integrated development environment IMU inertial measurement unit IO input / output LSB least signicant bit MSB most signicant bit PID proportional-integral-dierential sbRIO single board RIO onboard ight computer TCP Transmission Control Protocol UART Universal Asynchronous Receiver/Transmitter UAV unmanned aerial vehicle
April 26, 2012
vii
Leo Rampen
April 26, 2012
1.
Introduction
Aerial observation is used globally for military operations, law enforcement, infrastructure inspection and environmental monitoring.[1] One of the primary barriers to the wider adoption of aerial observation is the high cost involved. Operating a helicopter can cost anything from 500 through 3000 an hour dependent on application.[2] Fixed wing aircraft tend to be cheaper, but costs are still in the same region. Both types of aircraft require expensive and permanent infrastructure for operation. In the eld of aerial observation, the advantages of an unmanned platform are considerable. A compact system can be deployed from a greater range of spaces, and incurs very few of the costs attached to manned aircraft when not in use. Unmanned aircraft can remain on station for extended periods of time, limited by the capacity of batteries or fuel tanks rather than the mental capacity of their pilots. The lighter weight and reduced safety requirements of systems that dont need to carry a pilot generally reduces overall cost and complexity. Most unmanned aerial vehicles (UAVs) in operation today are military. While some commercial UAVs are in use, legislation generally limits them to under 7 kg.[3, 4] At this scale, UAVs are best suited to emerging applications such as local surveillance, agricultural monitoring and low altitude aerial photography. Most commercial platforms are based on radio controlled multi-rotor helicopters or aircraft. An as-yet unexplored area is the use of buoyant or semi-buoyant airships for small scale observation. The aim of the project was to demonstrate the concept of buoyancy in an UAV by designing, building and testing an autonomous aerial observation platform. An extensive literature review and design requirement consideration led to the objectives identied in the project Contract Performance Plan (CPP). Key areas of work were identied as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. Airship envelope design and manufacture Gondola structural design and manufacture Propulsion system design, testing and manufacture Electronic system design and manufacture Control and navigation system design and implementation Communications system design and implementation Ground station design and implementation Camera hardware design and manufacture Vision software design and implementation 1
Leo Rampen
April 26, 2012
Distribution of work dened by the CPP was altered slightly as the project progressed. The key change pertinent to this report was the assignment of ground station design and implementation to Rhys Neild. The areas of work that are discussed in this report are highlighted in bold.
1.1
Report Overview
This report covers work done in the design and implementation of an airship (or blimp) ight control system. This includes an active orientation control using feedback controllers, autonomous navigation algorithms and a wireless communication system. Also discussed in this report is the design and building of an electrical system for the aircraft. This included the design of a number of circuit boards for interfacing with sensors and the design of a complete wiring harness electrical system to provide power and control signals across the length of the aircraft.
1.2
Aims and Objectives
Before any technical work was done, time was taken to identify a number of key project aims. The overall project aims are identied in the project CPP.
1.2.1
Control, Navigation and Communication Software
As stated in the CPP, the aim relevant to the aircraft control is as follows: The airship must have a degree of autonomy and navigational capability with a view to further advancements to the complexity of the automation system in the future. This lead to the development of a number of relevant objectives. These are enumerated here as they are in the CPP. 12. Visual data must be able to be streamed back to the groundstation. 13. The airship must be able to track its current location and orientation. 14. The airship must be able to travel to a specied location and actively correct its trajectory. 15. The airship must have an on-board active stabilisation system. 16. If communication is lost, the airship must be capable of returning to the point of launch Later in the project, these were modied slightly. In the place of objective 16, a simpler requirement to shut o power on loss of communications was dened. It was deemed safer to allow the aircraft to slowly fall from the sky than to try and return to the point of launch. 2
Leo Rampen
April 26, 2012
1.2.2
Electronics and Electrical Systems
Electronic system objectives were not initially dened to the same extent. At the initial stage of the project it was unclear what hardware was to be used and how it would be electronically interfaced. Most electronics work was related to linking the single board RIO onboard ight computer (sbRIO) with sensors, actuators and motors. As work progressed, a number of objectives materialised. 1. Understand the voltage and current requirements of all electrical components. 2. Design and manufacture circuit boards to connect the sbRIO to relevant components. 3. Design and manufacture a wiring harness to provide power and command signals to all systems. 4. Procure or design and manufacture power supplies to convert the battery voltage to that required by the components used. These objectives were crucial for the overall functionality of the aircraft. Many software tests could not be performed before the completion of the supporting electrical systems, and so priority was given to many of these objectives.
Leo Rampen
April 26, 2012
2.
Context and Literature Review
A wide range of research papers are available detailing aerial vehicle control and autonomy. Additionally, there are several open source autopilot systems designed to provide autonomy for small aircraft. The selection of a communication method and the design of a communications protocol were both inuenced by existing literature and autopilot systems. Analysis of control and communications methods outlined in both these areas gave considerable insight into potential modes of operation. A broad understanding of the topic, including an appreciation for how existing autopilots implement features, proved vital during the design and implementation of an autonomous control system.
2.1
2.1.1
Flight Control Systems

Summary of Existing Computer and Autopilot Platforms
A range of light weight compact computing hardware exists. These tend to be based on well documented microcontrollers such as the AVR ATMega series or on more capable ARM processors. Based on these computers are many commercial and hobbyist autopilots for small aircraft. This section aims to provide a broad overview of possibly suitable compact computing platforms and an indication of any existing autopilot implementations. Computer Platforms Numerous compact computer platforms are available for embedded control systems. Primary aspects for consideration are weight, power consumption, cost and, perhaps most importantly, the complexity of developing for the platform. Arduino The Arduino is an open source electronics prototyping platform. The Arduino project develops a range of compact and cheap microcontroller development boards based around the Atmel ATMega family of processors and a simple development environment. A simplied C++ based programming language is used. The system is almost unique amongst microcontrollers in its ease of set up and use.[5] Primary advantages include the very low cost, light weight and large active developer community. A wide range of libraries have been developed for it and a number of existing autopilot systems could provide a good source for reference code and implementation details. 4
Leo Rampen
April 26, 2012
There are some limitations. Principally, the low clock speed of the processor limit the extent to which complex control algorithms can be run. The total size of the code executed on the system is also constrained, although the larger onboard storage (EEPROM) of newer devices such as the Arduino Mega largely negate this problem. Due to low processing power, the platform is unable to do any digital video processing or machine vision. Any camera used in conjunction with an Arduino must be capable of independently transmitting video data to the ground station. The arduino is the base platform of the Ardupilot open source autopilot system.[6] Gumstix Gumstix is a family of very compact computer modules. Primarily based around an ARM processor, the Gumstix platform comprises of the main computer module and a range of expansion boards.[7] The platform runs an embedded Linux software stack. Development is generally in C++. The platform is signicantly more powerful than the Arduino. The additional processing power available gives the potential for digital video processing and communication. An embedded Wi-Fi module could reduce the overall system weight. Primary disadvantages include the limited developer community, low familiarity with C++ and the much greater complexity involved in setting up a full operating system stack to run developed software. National Instruments Single Board RIO Industrial partners National Instruments have a range of embedded computer devices. The range of Single Board RIO devices oer particular potential for development. The sbRIO 9602 has both an onboard real time processor and an embedded eld programmable gate array (FPGA). The advantage of this over a microcontroller (which must run all programmed statements in order) is the complete parallelisation and high speed of the input / output (IO). Unlike a conventional microcontroller, a large number of high speed IO protocols can be implemented at once. A signicant advantage of the sbRIO over any other possible options is the Labview graphical development environment. This provides a large number of pre-made functions for robotics, communications and control use, allowing for faster development. The support National Instruments can provide is also an advantage of this platform. The sbRIOs principal disadvantage is the weight, size and power requirements of the board. A 3 cell Lithium Polymer battery has a nominal voltage of 11.1 V. The sbRIOs required 19-30 V input means an additional voltage boost converter would be needed for power. 5
Leo Rampen
April 26, 2012
Other Options There are a range of other microcontrollers available, some of which are already used for autopilot implementations. Other Atmel based microcontrollers include the low power ATTiny and the more powerful AVR32.[8] The multi core Parallax Propeller microcontroller provides the basis for a number of dierent autopilots.[9, 10] There are a number of dierent computer modules based around the ARM architecture, including the BeagleBoard and the OpenPilot platform. For these platforms, the primary limitation is the software development system used. Most embedded microcontrollers have a complex development process in low level languages. Developing on an unsupported platform with a small development community and an unfamiliar language and process could prove a signicant project risk.
2.1.2
Control Algorithms and Processes
Active ight stabilisation in three dimensions can be complicated and require careful controller design. For the airship design, the natural stability in roll removes the need for active control in all axes and the large buoyancy component reduces the need for high frequency control response. A number of existing systems make use of an attitude heading reference system (AHRS), comparing the aircraft orientation with a desired one and generating control inputs from the mixed outputs of independent proportional-integral-dierential (PID) control loops.[11, 6, 12] Sensor Fusion For the AHRS, making sense of inertial measurement unit (IMU) data can be a complicated process. Each sensor has its own range of strengths, weaknesses and sources of error. Gyroscopes provide a linear and fairly smooth output, but have no absolute reference. Accelerometers provide an absolute reference indicating the direction of gravity, but are subject to large amounts of noise. Magnetometers also provide an absolute reference, indicating the direction of the magnetic eld in which they sit. Unfortunately nearby metallic objects or electrical currents can skew the output.[13] A sensor fusion algorithm must be used to maintain a valid aircraft orientation over time and through aggressive movements. A number of options, ranging from simple gyroscope integration to complicated and computationally intense Kalman ltering processes are available for sensor fusion.
Leo Rampen
April 26, 2012
Gyroscope Integration Gyroscope integration provides the simplest method of orientation calculation. Each time the gyroscope is read, the value (in radians per second) is integrated and added onto previous rotations. The computational and mathematical simplicity of this method is outweighed by the susceptibility of gyroscopes to drift over time. Integration errors, rounding errors and measurement errors add up, leading to an indicated orientation that can be signicantly dierent to the actual one. If the gyroscope is ever moved to such an extent that the output saturates, the orientation will be subject to larger errors. Complementary Filter A complementary lter introduces a weighted accelerometer reading into the orientation reading. This is most succinctly demonstrated mathematically as is shown below.
t = wg (t1 + gyro dt) + wa xacc In this equation, t represents the angle at this timestep, wg and wa are the integration and accelerometer weightings, t1 is the angle at the previous timestep and gyro is the latest gyroscope reading. Typical values for wg and wa might be 0.98 and 0.02 respectively. The small accelerometer weighting will, over time, correct the angle with absolute readings. The small weighting acts as a low pass lter, minimising the response to noise.[14] Direction Cosines Matrix A further advancement of the complementary lter concept represents orientation with rotation matrices, which are known as a direction cosines matrix as the values are the cosines of the angles between the aircraft orientation and the global coordinate system. An advantage of this method is the ability to multiply the matrices together to calculate the outcome of a number of rotations. The orthogonal properties of the rotation matrix can be monitored and the matrix normalised if theyre found to stray. This process reduces small integration and rounding errors. In the method described by Mahoney et al. and further expanded into a practical implementation by Premerlani and Bizard, a proportional-integral controller is used to combat gyroscope drift. Yaw, pitch and roll error signals are created from the absolute sensors. The output of the controller is fed back into the gyroscope readings.[15, 16] This is the method implemented in the Ardupilot system.[6]
Leo Rampen
April 26, 2012
Kalman Filter A Kalman lter uses past state knowledge and a model of the dynamic system to make a prediction of the current system state. This is then updated based on observed sensor measurements. A properly congured Kalman lter produces a statistically optimum output for the sensor information given. Downsides of a Kalman lter for orientation estimation are the complexity of nding the correct noise and uncertainty values for initialisation, and the computational and mathematical complexity of the process. There are a few examples of Kalman lters used in existing UAV control systems.[11, 12]
2.2
Navigation and Autonomy
Most autonomous navigation systems use GPS for navigation between waypoints. Other systems have used machine vision or laser rangenders.[12, 17] The simplest GPS navigation simply points the UAV at the heading to the waypoint, while more complicated systems use some form of trajectory or path following between waypoints.[18, 19]
2.3
Communication Options
Reliable communication for aircraft command is vital. A number of low cost options are available. The selected option is largely dependent on the nal computer chosen, as each device has dierent capabilities. The most basic form of wireless communication acts as a virtual serial port. Devices available include Bluetooth modules, Zigbee low power transceivers, and Wi-Fi modules.[20, 21] These are all limited by the baud rate of the serial port (usually up to around 1 Mbps) or the protocol bandwidth. For faster data throughput (required for video transmission), other protocols must be considered. Wi-Fi modules interfacing over SPI can achieve higher speeds, or a Wi-Fi based ethernet bridge could allow standard network speeds.[22] For testing purposes, range is less important. Wi-Fi has been successfully tested past 37 km, while high end Zigbee modules have stated ranges in excess of 80 km.[23, 21] CAA rules limit aircraft to a 500 m radius and line of sight, reducing the need for long range radio.[24]
Leo Rampen
April 26, 2012
3.
Equipment and Software Used
A variety of software and hardware was used during the design and manufacturing process. An additional summary of the key components used in the nal aircraft is given.
3.1
Software Used
A summary of some of the software vital for the project is given. This is by no means an exhaustive list, but provides an indication of the key software used. The control system was implemented using National Instruments LabVIEW software. This is a graphical programming environment with emphasis on the data ow between functions. EAGLE electronic circuit CAD software was used for the design and circuit board layout of all the boards produced. Mathworks MATLAB was used to simulate some basic navigation scenarios and to test the navigation controller code. The Python scripting language was used to test data communication, and to implement a web server to allow interactive waypoint mapping. Javascript was used to build a mapping interface. Solidworks 3D CAD software was used to quickly prototype designs and to determine component layout. The Arduino integrated development environment (IDE) was used in conjunction with the Wiring C++ based programming language for Arduino software development.
3.2
Lab Equipment Used
A range of lab equipment was used. A number of items proved useful in debugging and testing electronic systems independent of each other. The ability to quickly check that signals and voltage levels were correct proved invaluable while building the electrical systems. An oscilloscope was used for debugging of implemented FPGA digital IO. This included checking that the digital signals produced by a serial implementation were correct and ensuring that the length and timing of the pulses generated for servo control were ideal. 9
Leo Rampen
April 26, 2012
An Arduino microcontroller development board was used for serial debugging and sensor testing. The simplicity of the Arduino language and the wide range of code examples available allowed quick testing independent of LabVIEW. This proved important in identifying any pin connection problems and ruling out faulty sensors. A multimeter proved invaluable in continuity testing, circuit resistance measurement and voltage checking. The ability to quickly probe the produced circuits allowed potential problems to be diagnosed independently of other systems. A number of hand tools were used for nal assembly.
(a) An Arduino microcontroller development board.
(b) Sensors tested in a breadboard.
3.3
Hardware Used in Final Aircraft Design
Final components used in the nal aircraft design were selected based on cost, weight, ease of use and availability. A summary of the key components used and their selection criteria is below. The single board RIO onboard ight computer (sbRIO) provided by National Instruments. After considering the options identied in Section 2.1.1, the sbRIO was selected due to the large body of support from our industrial partners National Instruments. The sbRIO was programmed using the LabVIEW graphical programming environment. This board was damaged during the project, and so late stage development and testing was done on an NI cRIO platform. A DLink DIR615 wireless router. This provides wireless communications capabilities and acts as a network switch to allow use of the network camera. Initially a more compact wireless module was selected for use, but problems in achieving the bandwidth required lead to a change to a wireless router. Communication options are discussed in Section 2.3, while justication for the selection of Wi-Fi is given in Section 4. 10
Leo Rampen
April 26, 2012
A Sensor Stick IMU. This is a simple board providing an electrical interface to a gyroscope, an accelerometer and a magnetometer. Section 2 discusses a number of sensing options considered. An SRF02 ultrasonic rangender. This provides accurate short-range height readings for landing and maintaining ground clearance. A GS407 Ublox5 GPS module. This provides GPS location data for navigation and location telemetry. An Axis M1054 network camera for visual observation. This is mounted on a gimbal device for pan and tilt movement. Discussion of camera selection and gimbal design is documented in Rhys Neilds report.[25] Three brushless motors driven by standard hobby electronic speed controllers (ESCs). All are commanded by standard pulse width servo control documented in greater detail in Section 5. Two are located at the front, mounted on an arm able to swivel to provide thrust vectoring. One is located at the rear, mounted on a bracket to allow swivelling. This provides a pitching and yawing moment. The propulsion system is dened in more detail in the report by Davis Chamia.[26] A range of hobby servos using the same pulse width control dened above. Four servos are used in the control surfaces. Two are used to swivel the motors, one at the rear and one at the front. An additonal two are used for the camera gimbal movement.
(a) The propulsion gondola and a motor.
(b) The main gondola with most of the electronics mounted
Figure 3.3.1
11
Leo Rampen
April 26, 2012
4.
Development of a Flight Control System
The aircraft designed is a complex system utilising 13 servos, 4 control surfaces, 3 motors and 6 sensors. To eectively provide control of the system, a number of dierent aspects had to be developed. The basic ight control system can be divided into three main areas: 1. The ight controller, composed of a number of feedback control loops. 2. The waypoint navigation system generating control inputs. 3. The communications system, receiving and sending data to the groundstation. Each of these components provides important contributions to the overall autonomy of the aircraft. An illustration demonstrating how these relate to each other is shown in Figure 4.0.1.
Figure 4.0.1: The main components of the ight control system. A standard aircraft co-ordinate system was used for consistency. This is demonstrated in Figure 4.0.2. Notably, the Z axis acts down in this coordinate system. The following sections describe the implemented software built in LabVIEW. Some images of the VIs built are included in Appendix A. For the full LabVIEW VIs the author can be contacted.
12
Leo Rampen
April 26, 2012
Figure 4.0.2: The aircraft axes of rotation and standard co-ordinate system.
4.1
Orientation and Velocity Control Loops
The control system uses PID control loops to generate motor control outputs based on a range of inputs. Motors are commanded in terms of X, Y and Z dimension thrusts, and then an overall thrust and swivel angle is computed for the front and rear motors. Saturation values are used to limit thrust, and priority is given to vertical thrust to reduce the likelyhood of losing altitude. This system lies in the Flight state controller part of Figure 4.0.1.
4.1.1
Flight Modes
The ight controller has a number of clearly dened ight modes. Each mode makes use of sensor data - IMU orientation, GPS altitude and ultrasonic rangender ground height - to compute motor and control surface control outputs. Forward ight mode takes a heading, altitude and ground speed as inputs. A desired pitch is generated based on the error to the target altitude. Tail motor thrusts and control surface angles are computed from the orientation error. Forward thrust is computed from the ground speed error. Motor outputs in each axis are summed and swivel angles computed. 13
Leo Rampen
April 26, 2012
The initial implementation of the orientation controller operates only on yaw and pitch. Roll was initially ignored due to the natural stability of the airship. Dierential thrust on the front motors, although an option, was not utilised. Hover ight is somewhat dierent. The altitude controller sets thrust equally on all three motors. Desired orientation is set at level, with the orientation controller maintaining this. Landing is very much like hover, but a constant vertical velocity is maintained. The ultrasonic rangender is used for precise height measurement. In Take-o mode, the aircraft rises to hover at 2 m, before proceeding to be commanded normally. An idle mode is implemented which shuts o all motors.
4.1.2
Testing and Simulation
The ight control system is set up for hardware in the loop (HIL) testing. When a Simulation boolean is dened, sensor data is replaced with data read over the network from a simulation running elsewhere. The desired motor control inputs are then passed back over the network for simulation input. This allows the full system to be tested on the intended hardware before any ying takes place. Some information about the implementation of the simulation is outlined in the report by Joe Beaumont.[27] The simulation system is not yet fully functional.
4.2
Navigation System
An initial project requirement was to introduce a degree of autonomy into the airship. The aircraft is always in one of 3 discrete modes. In manual control mode, no navigation commands are generated. Orientation and forward throttle commands are communicated directly from the ground-station. Two autonomous modes - waypoint navigation mode and machine vision navigation mode - were implemented. Machine vision mode is covered further in Rhys Neilds report.[25] The navigation system makes use of a GPS receiver for location information. Desired waypoints are communicated with the aircraft over WiFi. The navigation controller generates heading, velocity and altitude requirements which are fed into the controllers described in Section 4.1. This arrangement can be described as a cascading controller, as it makes use of a number of PID loops in a row. This simplies the tuning process.
14
Leo Rampen
April 26, 2012
4.2.1
Heading and Altitude Control
The navigation system uses a simple PID controller to determine desired heading. The bearings from the previous waypoint and the current GPS location to the target waypoint are computed and the error used to drive the controller. As a crosswind will manifest as a steady state error, integrator windup will cause the aircraft to compensate by crabbing into the wind. With no integrator component, the aircraft would drift downwind before approaching the waypoint heading into the wind. The desired aircraft velocity is proportional to the distance to the target waypoint. A saturation value is set as the cruise velocity. By using a low saturation value and a high proportional constant, the cruise velocity is maintained for most of a waypoint leg. The cruise velocity must be selected to maintain vertical control authority and will be nalised based on real world aircraft performance. The altitude commanded by the navigation system is based on the dierence in height between the target and previous waypoint. As the aircraft progresses between the two, the desired altitude is increased proportionally. Each waypoint denes an acceptance radius, typically 5 metres. When the distance to the waypoint is under this, it is deemed reached and any tasks dened are completed. If the boolean ag pass through is true, the velocity is maintained through the waypoint. If a hover time is dened, the aircraft will hover until this has elapsed. If the boolean ag land is true, the aircraft will land at the waypoint. If no ags are set as waypoint tasks, the current waypoint variable is incremented and the aircraft will y to the next waypoint. Because of the slow speed of the aircraft, the navigation system is run at 5 Hz to reduce the overall processing power needed.
4.2.2
Navigation Simulation
The navigation algorithms were simulated in Mathworks MATLAB software. A vastly simplied navigation problem was set up and the PID controller implemented. This allowed the mathematics to be validated and initial values for controller constants to be determined. Aircraft position was calculated through simple addition of the previous position, the aircraft speed and the wind vector. The initial integrator guess was the bearing to the target waypoint. This simulation was eective as a concept validation, but would require signcantly more work to eectively model a true navigation system.
15
Leo Rampen
April 26, 2012
The output of the simulation is shown across Figures 4.2.1a to 4.2.2b. The gures all represent the navigation system with a crosswind applied. The red pentagram represents the previous waypoint, while the green asterisk represents the target. The black diamonds show the path of the aircraft. With the right controller constants, the aircraft can follow the required track even with crosswinds close to its full ight speed. Wind speeds above the aircraft ight speed cause the controller to break down and the aircraft to blow o course. The selected process gains must reect the fact stability of the navigation system is more important than the response speed. Complete system simulation will allow further tuning of the process gains. The MATLAB code used for the simulation is included in Appendix C.
(a) A stable but poorly damped response
(b) A better response in a crosswind near the aircraft velocity
Figure 4.2.1: Stable simulation responses. The black arrow represents wind direction and speed.
(a) Complete controller breakdown in a wind faster (b) A very unstable response indicating poor tuning. than the aircraft speed
Figure 4.2.2: Undesirable controller responses.
16
Leo Rampen
April 26, 2012
4.2.3
Waypoint Structure
An array data structure is used to represent waypoints. Rows represent individual waypoints, while columns reect the data dened by that waypoint. Table 4.2.1 shows the information in a waypoint. This includes the co-ordinates and a number of boolean ags indicating tasks to undertake once the waypoint is reached. A seperate conguration variable is used to identify the current waypoint. Any changes to the order of waypoints is made by reordering the rows in the array.
Column 0 1 2 3 4 5 6 7 8 9 Data Latitude Longitude Altitude Hold time Acceptance radius Pass straight through Yaw angle Return to launch Land Camera viewpoint Format Degrees Degrees Metres Seconds Metres Boolean Radians Boolean Boolean Integer
Table 4.2.1: The data represented by each column in the navigation waypoint array. The waypoint array contains many similar rows. Other arrays are assembled in a similar fashion.
4.3
Communications Protocol Design
A range of commands were required to be sent to the aircraft. Commands included waypoints indicating where to y to, viewpoints indicating the required position of the camera, conguration settings and manual ight control settings. Additionally, telemetry data was required to be returned to the ground station. This called for a reliable and eective message communication system. Some key requirements were identied: 1. Control commands must be communicated quickly and without corruption. 2. Aircraft telemetry must be communicated at high frequency. 3. Video data from the onboard camera must be communicated to the ground station at an acceptable frequency. 4. The system must maintain a heartbeat signal, indicating a successful connection. This problem was addressed in two parts. The rst was a system to transfer string data between the ground station and the aircraft. The second was the design of an extensible messaging protocol with low processing overheads.
17
Leo Rampen
April 26, 2012
Figure 4.3.1: The TCP communication component structure.
4.3.1
Low Level Protocol
The Transmission Control Protocol (TCP), a standard networking protocol designed to deliver an ordered stream of bytes reliably, was used. The ground station acts as a client, initiating all connections, while the aircraft control system acts as a server. The ground station periodically polls the aircraft for required data (such as aircraft orientation), and the blimp responds. When any user controller parameters on the groundstation are changed, the new data is sent to the aircraft. This process is demonstrated in Figure 4.3.1. Initially two 4 byte integers are sent. The rst integer reects the total size of the data payload to follow and tells the server how much data to read. The second integer is a command byte which identies the type of message being sent. The client periodically sends commands (identied by a command byte in the range 2 to 9) and requests for data (with command bytes above 20). If the sent message is a command the aircraft will reply with ACK to acknowledge receipt. If the sent message is a request for data the aircraft will reply with that data. Data at the client is produced by events (such as the user changing a conguration value) or by timed loops. When data to be sent to the aircraft is produced, it is added to LabVIEW named queue. A loop continually checks the queue for data to send. When 18
Leo Rampen
April 26, 2012
data is in the queue, a TCP connection is initiated with the server on the aircraft and the data is transferred. Any messages received in reply are added to another queue, which is parsed by a separate loop. The use of LabVIEW named queues to transfer data ensures that all generated data is eventually transferred to the remote system. Periods of high data generation, perhaps occurring when a number of timed loops coincide with each other, are smoothed out by periods with less communication. As long as the amount of data generated does not exceed the total throughput of the network connection over time, data will be transferred. The aircraft continually listens for connection attempts. When one is made, the received message is parsed and any relevent local settings updated. If the message is a request for information, a reply is made. The data connection is continually monitored with a heartbeat signal. The aircraft is periodically polled every second, and key information about the current ight mode is returned. Other data is only sent if the heartbeat signal was recently received. If the aircraft receives no signal for 5 seconds, the ight control loops are ended, the motors shut down and the aircraft enters an idle state. This is a safety feature.
4.3.2
Implemented Message Protocol
Existing protocols and systems were identied and analysed. Many existing open autopilot systems make use of the Micro Air Vehicle Communication Protocol (MAVLink) system originally developed for the Pixhawk UAV.[12, 6] MAVLink eciently transfers pre-dened data across serial links. The MAVLink system generates C based message packing and unpacking functions to allow the creation of a simple string from the required message data.[28] A number of challenges were identied in using the MAVLink system. While LabVIEW does allow for the calling of externally compiled libraries written in C, past experience has proved that this can be complex to implement. The key requirement that the software written was able to be executed on both the Windows based ground station and the aircraft also limited this option. Additionally, LabVIEW data types are not directly transferable to C types. Problems were anticipated with oating point numbers and 2 dimensional arrays. The decision was made to develop a protocol inspired by MAVLink, but solely written in LabVIEW. The large feature-set of MAVLink provides many functions not required for 19
Leo Rampen
April 26, 2012

Downlink Data Represented GPS Reading Orientation Motor and servo settings Camera frame MD5 hash of conguration settings Current waypoint
Int 2 3 4 5 6 7
Uplink Data Represented Waypoints Viewpoints Camera conguration Aircraft conguration Manual control commands Shut down command
Array Size 10xN Array 11xM Array 5x1 Array 6x1 Array 6x1 Array Boolean
Int 20 21 22 23 24, 25, 27, 28 26
Array Size 6x1 Array 3x1 Array 7x1 Array String Strings Integer
Table 4.3.1: The message types communicated. The Int column represents the command byte for that message. the initial aircraft prototype, and so a subset of key features was developed. The format of data was modied to closer reect LabVIEW data types and software design methods. The selected communication messages are demonstrated in Table 4.3.1. To represent most of the data sent, an array structure was used. As a means of example, Table 4.2.1 shows the columns and data represented in the waypoint array. This structure allowed by virtue of its ordered nature a clear waypoint hierarchy. A disadvantage of this system was the requirement to communicate the entire array when any changes were made. This could be negated with a dierential algorithm. Messages consisting only of one number or boolean are sent as simple numerical strings. Data integrity was ensured by the aircraft regularly taking the MD5 checksum of all conguration arrays. The groundstation compares the checksum sent by the aircraft to that of its own conguration arrays. If they dont match, the conguration arrays are re-sent to the aircraft. This system sets the ground station as the Master, and ensures all settings on the aircraft are up to date. A simple groundstation was written to ease the passing of data between the user and the control system. In conjunction, a map based waypoint selection system was written in Javascript, HTML and Python. This allows a user to select a series of waypoints on an interactive map, and upload them to the aircraft. The aircraft location is also plotted on the map. The user interface, the LabVIEW VIs and map source code are included in Appendices B and F.
20
Leo Rampen
April 26, 2012
5.
Sensing and Actuation
Interfacing with the selected sensors and actuators is a vital aspect of the control system. The hardware used is detailed in Section 3.
5.1
Communicating with Sensors
Three primary sensors are used on the aircraft. The inertial measurement unit (IMU) is a small board comprising of three chips. The ADXL345 accelerometer, HMC5843 magnetometer and ITG-3200 gyroscope chips are all MEMs devices which communicate over a standard Inter-Integrated Circuit (I2 C) interface. The SRF02 Ultrasonic Rangender is a lightweight distance sensor. It uses acoustic pulses to determine distance, and is also communicated with by I2 C. The GS407 Ublox5 GPS is a small GPS module with support for standard NMEA sentences. It communicates over a Universal Asynchronous Receiver/Transmitter (UART) serial interface.
5.1.1
Inertial Sensors
Reading over I2 C All I2 C devices have a 7 bit slave bus address which for all practical purposes is xed. To read values from an I2 C device, rst a command byte must be written to the device slave address. Commands are dened by the device datasheet. On receipt of a command, the device will respond with the requested data. Data is represented as bytes in the form of least signicant bits (LSBs) and most signicant bits (MSBs). These can be joined in a bit shift operation to give the output value. The data read from each chip can then be interpreted based on the datasheet instructions to yield an acceleration, rotation rate or orientation with respect to North in standard units. The process used to read X, Y and Z acceleration values from the ADXL345 accelerometer is shown in Figure 5.1.1. The other two chips are broadly similar. Development of the LabVIEW I2 C implementation drew from the LabVIEW built in examples and from I2 C guides for the Arduino platform.[29]
21
Leo Rampen
April 26, 2012
Figure 5.1.1: The I2 C reading process. 1. 6 bytes, starting at the 0x32 register of the accelerometer (which is at the slave address 0x53), are read. 2. The returned 6 byte data array is indexed for individual bytes. 3. The data returned is built into numbers. The 6 bytes correspond to the X, Y and Z LSBs and MSBs. 4. The resulting 16 bit signed integer is converted to an unsigned integer 1 5. The integer is then scaled by a value dened in the datasheet - in this case 256 . Sensor Limitations Each sensor has limitations, both in terms of drift and environmental noise and in terms of fundamental hardware limitations. The digital sensors used all provide internal analogue to digital converters (ADCs), and so the limitations and sensitivity of each chip is quantied in its datasheet. The three inertial sensors and their resolutions and limits are summarised on Table 5.1.1. The gyroscope and accelerometer bias can generally be negated by averaging readings over a stationary period.
ADXL345 ITG-3200 HMC5843 Accelerometer Gyroscope Magnetometer Limits 2g 2000 /s 1.0 Ga Resolution 3.9 mg 0.07 /s 1300 counts/mGa Tolerance 40 mg 40 /s 5% [30] [31] [32]
Table 5.1.1: Inertial sensor resolutions and limits.
5.1.2
Ultrasonic Rangender
The SRF02 rangender also interfaces over I2 C, but required more careful consideration. The timing requirements of acoustic sensing mean that the sensor takes approximately 65 ms to determine range. To determine distance, an initialise ranging command must be sent, and then time allowed to pass before the distance is read o the device. The device returns 255 for both bytes until a range is available, and so a while loop was set up to continually poll it until valid data was returned. 22
Leo Rampen
April 26, 2012
5.1.3
GPS Module
The GPS required implementation of a serial protocol over the sbRIO digital IO pins. While the sbRIO hardware does have a standard serial port, the placement away from the other board digital IO pins made it impractical to use. Like the I2 C implementation, this was based on LabVIEW implemented examples with some modication to better integrate the code with the rest of the IO code running on the FPGA. The serial protocol is a very open specication. The baud rate (indicating bit length), number of start bits, number of stop bits and the presence of a parity bit for error detection are all predened. From the idle condition of high, a byte is communicated over the TX pin by rst making the pin low for the start bit length, before setting the pin to high or low at the dened baud rate. The end of transmission is indicated by a number of stop bits. The basic byte frame is demonstrated in Figure 5.1.2. The GS407 module used is read at 9600 baud with 8 data bits, 1 stop bit and no parity bits. Data received from the GPS is in the form of NMEA 2.0 standard sentences. A parser for this format is included within LabVIEW.
Figure 5.1.2: A single UART byte frame. The number of start and stop bits is variable.
5.2
Sensor Fusion
As discussed in Section 2.1.2, fusing the data read from the IMU to generate an accurate and reliable orientation is crucial. From the methods discussed, the Direction Cosines Matrix method was selected for implementation. This presented a good compromise between the complexity of implementing a Kalman lter and the limited accuracy of a simple gyroscope integration method. The method has been shown to be eective in a number of existing autopilot systems, and so presented less of a project risk than other methods. A full account of the mathematical equations used is given by Premerlani and Bizard.[16] The implemented algorithms use a feedback controller. The process is demonstrated graphically in Figure 5.2.1. At point 1, gyroscope data is read through the process outlined in Section 5.1.1. The X, Y and Z values are multiplied by the timestep and built into a rotation matrix representing the rotation during the timestep. Rotation rates are assumed to be constant through 23
Leo Rampen
April 26, 2012
Figure 5.2.1: The Direction Cosines Matrix complementary lter fusion method process the timestep. At point 2, the produced rotation matrix is multiplied by the previous rotation matrix to produce a matrix representing the aircrafts current orientation. With no correction, this orientation matrix only demonstrates aircraft orientation with respect to initial start orientation. At point 3, small numerical and integration errors are corrected. A property of a direction cosine matrix as used here is that it is orthogonal - the matrix multiplied by its transpose yields an identity matrix. Any small changes which cause the loss of orthogonality can be corrected. Point 4 takes into account magenetometer and accelerometer values, computing the error between the orientations indicated by the absolute sensor and that indicated by the gyroscope based rotation matrix. The PI produces an oset (point 5) applied to the next gyroscope values read.
5.2.1
Validation
To validate the method, a number of IMU readings were taken. The basic integral method discussed in Section 2 and the feedback method discussed above were implemented in MATLAB and the resulting rotations plotted. Figure 5.2.2 shows the dierence between the integrated and fused roll orientation over a 40 second period of small movements. All the MATLAB code used for this is included in Appendix D.
24
Leo Rampen
April 26, 2012
Figure 5.2.2: Integrated gyroscope (blue) and fused (red) orientations demonstrating roll axis divergence during small movements.
25
Leo Rampen
April 26, 2012
6.
Electronic Systems Design
The airship requires a large number of electrical systems to maintain autonomy. Sensors, servos and motor ESCs were interfaced with using digital IO on the sbRIOs. The power requirements of each component had to be assessed and power supplies with the correct voltage and current capabilities designed and built.
6.1
Power Budget
The voltage and current requirements of each electrical component used was assessed and a power budget constructed. Broadly, most systems required either 3.3 V or 5 V. Balancing this requirement with the battery supply voltage of 11.1 V and the Single Board RIO voltage requirement of 19 - 30 V required careful consideration. The power required by each item is demonstrated in Table 6.1.1. Power sources used are also shown. Each servo must be considered in terms of its stalled current - the current draw seen when the servo is unable to move due to being physically blocked. For the camera and router, a 5 V 3A switching step down converter was used, while for the camera gimbal a 5 V linear regulator was used. The continuously high power draw of the router and camera called for the weight and cost of an ecient switching regulator, while the high peak current but low average current of the camera gimbal proved to be suitable for a cheaper and lighter linear regulator.
Power Supply Battery Boost converter Switching buck converter Voltage regulator Voltage regulator Rear ESC voltage regulator Front ESC voltage regulator Source Battery Battery Battery sbRIO 5 V out Battery Battery Voltage 11.1 V 20 V 5V 5V 3.3 V 5V 5V Peak Current 30 A+ 3A 3A 3A 250 mA 1A 2A Powers Motors sbRIO Wi-Fi router, camera Gimbal servos Sensors Rear servos Swivel servo
Table 6.1.1: The power converters used on the aircraft. The source of all electrical power is the battery.
6.2
Circuit Board Design
Three circuit boards were designed for the aircraft. The rst, a breakout board for the GS1011 Wi-Fi module described in Section 3, was produced as a PCB. Because of the limited bandwidth possible, the GS1011 module and PCB were not used in the 26
Leo Rampen
April 26, 2012
nal design. To reduce turn-around time and allow easier modication, the last two (connecting the sbRIO pins, sensors, servos, motor controllers and power supplies) were developed on 0.1 pitch copper stripboard. Figures 6.2.1a to 6.2.1c show the three designs. The full EAGLE circuit diagrams and PCB layouts are included in Appendix E.
(a) The GS1011 Wi-Fi module (b) The sbRIO actuation breakbreakout board out boards.
(c) The sensor breakout board.
Figure 6.2.1: The three circuit boards designed and built. EAGLE schematics are included in Appendix E. The initial design for the sensor breakout board had problems with electrical noise. Attempting to operate both the GPS and the IMU on the same circuit caused communications with the IMU to break down. Additional capacitors and a rerouted power supply yielded no improvement. A second design, moving the GPS o the board entirely and seperating the sensors electrically as much as possible was found to be functional.
6.3
Aircraft Wiring Harness
Providing the correct voltage, power and signals to the dierent components of the aircraft required some consideration. A wiring harness was designed to do this eectively. Wire gauge was selected based on current requirements. A single ground plane is in operation throughout the aircraft, with high impedence resistors used to protect the digital IO of the FPGA from too much current. A simplied aircraft wiring diagram is shown in Figure 6.3.1. Not shown are the main motors (which are on an arm protruding from the propulsion gondola) and the three control surface servos for the other ns.
27
Leo Rampen
April 26, 2012
Figure 6.3.1: A top level view of the aircraft wiring diagram.
28
Leo Rampen
April 26, 2012
7.
Conclusion
This report has demonstrated some of the tasks undertaken to meet the initial objectives. For all objectives, signicant progress has been made. An implemented ight control system allows the autonomous operation of the aircraft. A functional communications system allows user commands to be processed and telemetry data returned. A complete electrical system allows the reading of sensors and the commanding of control surfaces and motors. Additional safety features to shut down the aircraft on loss of communication and monitor the control system for errors have also been implemented. In some areas, work is close to complete. The electrical system is fully functional, and the communications system has shown high resiliency. While the ight control system has been implemented to match all objectives, without considerable further testing it is unclear where bugs and errors lie. Hardware in the loop simulation will allow the control loop constants to be tuned and cause any errors or oversights to surface. The project has a legacy which includes a signicant amount of LabVIEW code and a number of electronic circuit boards. The circuit diagrams of the boards are included in Appendix E. Use of the airship system would require inspection of these diagrams to ensure correct wiring connections. By necessity, a wide range of elds must be investigated to build a complete control system. Gaining an understanding of dynamics, feedback controllers, electronic circuit design and a great deal more has been both an engaging and an enjoyable process.
29
Leo Rampen
April 26, 2012
8.
Future Work
While a lot of work has been done, a great deal remains. In particular, the tuning of the ight control loops will require some focus both during simulation and in ight tests. Some nal integration work is required to connect the tail assembly to the main electrical system. It is anticipated that this work will continue during May. The damaged sbRIO limits aircraft ight capability. If a similar board cannot be sourced, a dierent control board (such as an Arduino) will have to be used. The route to be taken will become clear after further feedback from National Instruments. Flight testing is planned for the near future. The work required on the control system building up to this will depend on the computer board used for ying. If an Arduino has to be used, porting the control system will take some additional time. In the longer term, a number of design changes could be made. The bulky and heavy Wi-Fi router was selected for ease of setup. With further work, a much lighter weight module such as the GS1011 could achieve the bandwidth required for video. The overall weight of the control system could be reduced by designing and etching a single printed circuit board. This was initially considered, but the complexity of a single design coupled with the risk of mistakes rendering the board useless led to the current stripboard based solution. National Instruments have a lighter sbRIO board with a proprietary high density connector. A PCB designed to interface with that board would save signcant weight.
30
Leo Rampen
April 26, 2012
Bibliography
[1] A. Horcher and R. J. Visser, Unmanned aerial vehicles: Applications for natural resource management and monitoring, tech. rep., San Dimas Technology and Development Center. [2] BBC, North wales police reveal 1.7m helicopter running cost, Dec. 2010. http: //www.bbc.co.uk/news/uk-wales-north-east-wales-11985097. [3] CAP722 - unmanned aircraft system operations in uk airspace guidance, tech. rep., Civil Aviation Authority, Apr. 2010. [4] The air navigation order 2009, tech. rep., UK Government, Nov. 2009. [5] Arduino homepage, 04 2012. http://www.arduino.cc/. [6] Ardupilot mega, Apr. 2012. http://code.google.com/p/ardupilot-mega/wiki/ home?tm=6. [7] Gumstix, 04 2012. http://www.gumstix.com/. [8] Microcontrollers - Atmel Corporation, 04 2012. http://www.atmel.com/products/ microcontrollers/default.aspx. [9] Octopilot, Octopilot, 06 2009. http://code.google.com/p/octopilot/. [10] Attopilot, Attopilot v3 AHRS IMU, 04 2012.
http://www.
attopilotinternational.com/products/acs/attopilotahrs.html.
[11] J. S. Jang and D. Liccardo, Automation of small uavs using a low cost mems sensor and embedded computing platform, in 25th Digital Avionics Systems Conference, 2006 IEEE/AIAA, pp. 1 9, oct. 2006. [12] L. Meier, P. Tanskanen, F. Fraundorfer, and M. Pollefeys, Pixhawk: A system for autonomous ight using onboard computer vision, in Robotics and Automation (ICRA), 2011 IEEE International Conference on, pp. 2992 2997, may 2011. [13] S. Fux, Development of a planar low cost Inertial Measurement Unit for UAVs and MAVs, Masters thesis, Swiss Federal Institude of Technology, Zurich, 2008. [14] S. Colton, The balance lter, a simple solution for integrating accelerometer and gyroscope measurements for a balancing platform, tech. rep., June 2007.
31
Leo Rampen
April 26, 2012
[15] R. Mahoney, S.-H. Cha, and T. Hamel, A coupled estimation and control analysis for attitude stabilisation of mini aerial vehicles., tech. rep., Nov. 2006. [16] W. Premerlani and P. Bizard, Direction cosine matrix imu: Theory, tech. rep., May 2009. [17] Y. Lin, Hyypp, and A. Jaakkola, Mini-uav-borne lidar for ne-scale mapping, Geoscience and Remote Sensing Letters, IEEE, vol. 8, pp. 426 430, may 2011. [18] W. Ren and R. Beard, Trajectory tracking for unmanned air vehicles with velocity and heading rate constraints, Control Systems Technology, IEEE Transactions on, vol. 12, pp. 706 716, sept. 2004. [19] D. Nelson, D. Barber, T. McLain, and R. Beard, Vector eld path following for miniature air vehicles, Robotics, IEEE Transactions on, vol. 23, pp. 519 529, june 2007. [20] Wireless product specications, Apr. 2012. http://www.lm-technologies.com/ adapters/LM058_Bluetooth_Serial_Adapter/. [21] Digi XBee Wireless RF Modules - Digi International, Apr. 2012. http://www. digi.com/xbee/. [22] Gs1011MXXS size-optimised Wi-Fi modules, Apr. 2012. http://www.gainspan. com/products/GS1011MS_modules.php. [23] K. Chebrolu, B. Raman, and S. Sen, Long-distance 802.11b links: performance measurements and experience, in Proceedings of the 12th annual international conference on Mobile computing and networking, MobiCom 06, (New York, NY, USA), pp. 7485, ACM, 2006. [24] CAP658 - Model Aircraft: A Guide to Safe Flying, tech. rep., Civil Aviation Authority, Apr. 2010. [25] tech. rep. [26] D. Chamia, Design of an autonomous airship platform, tech. rep., University of Leeds, 2012. [27] J. Beaumont, Design of an autonomous airship platform, tech. rep., University of Leeds, 2012. [28] Mavlink micro air vehicle communication protocol, 04 2012. qgroundcontrol.org/mavlink/start.
http://
[29] Connecting to sparkfuns 9dof sensor stick: I2c access to adxl345, itg-3200, and hmc5843, 02 2012. http://chionophilous.wordpress.com/2012/02/10/
connecting-to-sparkfuns-9dof-sensor-stick-i2c-access-to-adxl345-itg-3200-and-hmc5843/.
[30] ADXL345 data sheet. [31] ITG-3200 data sheet. [32] HMC5843 data sheet. 32
Leo Rampen
April 26, 2012
Appendices
33
Leo Rampen
April 26, 2012
A.
Control System LabVIEW VIs
The LabVIEW VIs included are the main ones written for the ight control system. The MasterControl.vi control system sits over 14 pages. 3 loops are within it. The top one checks that a heartbeat has been received within the last 5 seconds, and if it hasnt it puts the system into idle mode, shutting down propellers. If no heartbeat has been received within a reasonable period of time, it restarts the system. The second one is the comms loop. This loop runs continuously, listening for connection attempts over TCP. If made, the connection data is inspected for the command byte and the message is read to the relevent conguration variables or the data requested is returned to the groundstation. The third loop is the overall system state machine. This operates in 4 states. In startup, sensors are initialised and the conguration is read from a le stored onboard. In the ight state, the main control loops including those to read sensors, navigate and control the camera are run. If a shutdown signal is received, from either the heartbeat checker or the ground control station, the system enters the shut down state. Here motors are turned o, sensors are shut down and any conguration is saved. Saving the conguration allows waypoints and system conguration to persist over multiple resets and power loss conditions. This is a poor way to inspect LabVIEW virtual instruments. For the les involved, please contact the author at mn08lhsr@leeds.ac.uk or leorampen@gmail.com
34
Page 1
MasterControl.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\MasterControl.vi

Last modified on 21/04/2012 at 19:37 Printed on 24/04/2012 at 16:32
Set last comms as never
Check how long since last heartbeat
Last Heartbeat Time
True Shut down Shut Down
User Commanded Shutdown 00:00:00.000 DD/MM/YYYY Last Heartbeat Time If we haven't been contacted for 3 minutes (but the timestamp isn't 0) 180 Reset the RIO and load everything again (should fix any problems) True
100000
Restart (Self)
Comms In and Out - Receive commands from the groundstation and either respond with the data required, or store the data sent.
False
False
14 Shut down process: Set motors armed to 0 Initiate a connection Don't start if there's an error 5131 4 Read all byt es 1 2 3 If not landed, initiate main loop with "return to launch" as waypoint 0 0 1 2 Altitude K_I 0 1 2 Yaw K_P 0 1 2 Yaw K_D Yaw K_I 0 1 2 Altitude K_P Altitude K_D 0 1 2 Navigation K_I Navigation K_P Navigation K_D Read the first 4 bytes It'll say how many bytes in total are being sent 0 0 0 0 0 Reset All Feedback 4 5 6 Velocity K_I Velocity K_P Velocity K_D 0 1 2 Hover Altitude K_I 0 1 2 Hover Yaw K_I Hover Yaw K_P Hover Yaw K_D Hover Altitude K_P Hover Altitude K_D Pitch K_I Pitch K_P Pitch K_D ACK
Ensure aircraft landed (cut motors, see if falls? or ultrasonic rangefinder value (might not work at low heights).
status
"Run"
Orientation and Velocity Control Loop - 10 Hz System Mode High frequency loop IMU read and control feedback stuff only Flight Mode Wait Finished Late? [i-1] Altitude controller Desired Orientation TO DO LIST: Elevator and positive motor "force stealer" IMU: Fix yaw 3D correction Ensure axes are correct Constants for the IMU DCM feedback method 0 0 1 1 1 1 1 1 1 1 1 Simulation Desired Altitude GPS Altitude Rangefinder Altitude 0 0 0 0 0 Current R Matrix 0 Front Swivel Angle Add in altitude controller input Motor Thrust Desired Velocity GPS Velocity Rear Swivel Angle "Flight" If we're in hover mode, we need to maintain altitude FPGA VI Reference Out Rear Thrust
Mo
0 0
0 IMU Error FPGA VI Reference Out Current R Matrix
0 0 0
4 Hz General Loop 4 Hz Low frequency loop - read GPS Read at 4 Hz GPS Latitude
FPGA VI Reference Out
GPS Data
GPS Longitude
Convert from knots to m/s GPS Data Simulation watchdogID GPS Error GPS Altitude Tell the watchdog we're still alive Navigation, Command and Rangefinder Loop - 10 Hz Shut Down GPS Heading 0.51444 GPS Velocity
FPGA VI Reference Out 100 Rangefinder Error Rangefinder Altitude
Simulation
Conduct waypoint navigation
"Waypoints"
Waypoint Array Current Waypoint

Control Command Mode Desired Orientation Homepoint Flight Mode GPS Data Desired Altitude Desired Velocity Desired Orientation
Current Waypoint
Desired Velocity "Manual"
Still need
Desired Altitude
Viewpoint Source GS Commanded Viewpoint Current Viewpoint Viewpoint Array Current Viewpoint 0
4 5 6
GP
Defined by Nav or Manual Control
60s - Save config every 60 seconds
only execute every 60 seconds

0 Motors Armed Control Command Mode
Current Waypoint
Viewpoint Source Current Viewpoint
Waypoint Array
Viewpoint Array 60 Camera Config Homepoint Shut Down
Page 2

Flash LED or power stuff off or whatever Need to power cycle to bring back on.
Send "Shutting down" over wifi
Comms Error
status
Rear Motor Setting Everything's finished, close up Shut Down Right Motor Setting Elevator Angle
Left Motor Setting
Rudder Angle
Control Surface Error
Shut Down
Potential option is to check the required tail thrust, and if it's positive (ie down), then replace it with a moment balanced front Z thrust up. Another thing to have would be to check the velocity, and replace a force in the tail with a corresponding control surface force.
We need some sort of controller here, maybe?
Shut Down
Page 3

0 1, Default
"Wayp
Return heartbeat
"SEND-DATA" <name>LEEDS BLIMP</name><ms-count> 1 </ms-count><system-mode>
Waypoint Array Current Waypoint

9
%s
System Mode </system-mode><command-mode>
Last Heartbeat Time
%s
Control Command Mode </command-mode><flight-mode> Flight Mode
%s
</flight-mode>
"False", Default
COMMAND-UNKNOWN
2 Write to the waypoint array ACK 0 0 0
Waypoint Array
3 Write to the viewpoint array
0 0
Viewpoint Array ACK Define some initial variables
Initia
Waypoint Array
Viewpoint Array
Camera Config
Manual Control Commands 4
Write the camera config Homepoint 0 0 ACK Camera Config Shut Down
Load the co
Control Command Mode
Motors Armed
Current Waypoint
5 Write the aircraft config ACK
Viewpoint Source
Current Viewpoint
Read the configuration to variables 0 0 Motors Armed 0 1 2 3 4 Control Command Mode Simulation GS Commanded Viewpoint
Current Waypoint
Viewpoint Source GS Commanded Viewpoint
6 "Manual" Manual Control Commands 0 0 Write manual control commands if we're in manual control mode
ACK
0 1 2 3 Control Command Mode
Desired Orientation
Desired Velocity Flight Mode Desired Altitude
Default
0 Otherwise, just store the commands and don't act on them.
Page 4

Default 0, Default "Idle", Default Current Viewpoint In idle, there is no thrust 0 0 1 2 0 0 1 "Machine Vision" 0 0 stabilised control -1 0 0 0 -1 0 0 0 -1 Current R Matrix "Hover" Desired Orientation 1 2 Current R Matrix
Desired Altitude GPS Altitude 0 Rangefinder Altitude
Waypoint Array
0 0 0 GPS Data "Takeoff"
Needs input to hold position while hovering
We need a takeoff controller
0 0
"Land"
We need a controller for constant rate of descent
0 10
"Start Up", Default
Set mode to run Run FPGA VI Reference Out Simulation
GPS Data Flash the LED to indicate startup complete 0
1 2 500 5 0
Define the flight mode Flight Mode Idle Motors Armed 0 1 2 3 4 Control Command Mode Flight Mode Move the control surfaces here, maybe? Start a watchdog. This is only in place when the mode is not "wait". If the VI crashes in any mode other than "wait", this'll reset the hardware. watchdogID
Current Waypoint
Viewpoint Source GS Commanded Viewpoint
Waypoint Array
Viewpoint Array
Camera Config
Page 5

False False
0 0
0 0
Page 6

Shut down time
flight mode to idle Idle Flight Mode
Contr
Cu
Turn off the watchdog watchdogID
Vie
GS Com
Page 7

"Shut Down"
Save everything to disc Motors Armed
Motors off, elevators to 0
Close the FPGA reference FPGA VI Reference Out FPGA Error Out Wait
Waypoint Array
Viewpoint Array Camera Config Homepoint
Page 8

7
If the command sent is 1, shut down and wait. Otherwise, run normally User Commanded Shutdown
ACK
Write the camera config
ACK Homepoint
10
ACK
Simulation
11
ACK 0 0 IMURollPitchYaw
12
Get Date/Time In Seconds
Template for Simulation
oldest read timestamp latitude (deg) 0 0 0 1 2 3 4 longitude (deg) ground speed (knots) true track angle (deg) altitude above mean sea level (m) GPS data
ACK
13
ACK
Current Rangefinder Altitude
20 Send GPS data
GPS Latitude GPS Longitude GPS Altitude GPS Velocity Rangefinder Altitude GPS Heading 20
Page 9

"Wait"
Wait
Shut Down
Start Up
Page 10

21 Send orientation
Current R Matrix 21
22 Send current control data
Left Motor Setting Right Motor Setting Rear Motor Setting Front Swivel Angle Rear Swivel Angle Elevator Angle Rudder Angle 22
24
Send Waypoint Array Hash
24
Waypoint Array
25
25
Viewpoint Array
26
26
Current Waypoint
27
27
Camera Config
28
Motors Armed
Control Command Mode 28 Viewpoint Source
Don't check current waypoint or viewpoint because they're subject to change by navigation
Page 11

1000, Default
Nothing here! ACK
True
True
Page 1
CalcNavAngles.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Navigation\CalcNavAngles.vi

Last modified on 21/04/2012 at 19:35 Printed on 24/04/2012 at 16:49 CalcNavAngles.vi
Current Position Desired Position Timestep
Yaw Angle Required
This VI takes two vectors. Each is generated by another VI between 2 GPS coordinates. Each vector has it's origin in the first position, with North as the reference point (3D North). The angle between the origin and the target (in both cases, the target is the target waypoint) is calculated. The error betweent the two is then multiplied by a proportional constant (currently 1). The resulting error is added onto the bearing to the target to get a new bearing requirement. The level to which the new bearing doesn't point towards the target is defined by the extent to which the aircraft isn't on track.
This VI takes two vectors. Each is generated by another VI between 2 GPS coordinates. Each vector has it's origin in the first position, with North as the reference point (3D North). The angle between the origin and the target (in both cases, the target is the target waypoint) is calculated. The error betweent the two is then multiplied by a proportional constant (currently 1). The resulting error is added onto the bearing to the target to get a new bearing requirement. The level to which the new bearing doesn't point towards the target is defined by the extent to which the aircraft isn't on track. Current Position Bearing to target from current position Yaw 0 1
Desired Position
2 Bearing to target from previous wp 0 1 2
Yaw Angle Required
Timestep
Navigation K_I
Navigation K_P
Navigation K_D
Page 1 CalculateYawPitch.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\CalculateYawPitch.vi Last modified on 21/04/2012 at 19:37 Printed on 24/04/2012 at 16:43
CalculateYawPitch.vi
Desired R Matrix IMU R Matrix Timestep
Tail Y Thrust Tail Z Thrust
This VI computes yaw and pitch thrust values. Yaw is the thrust acting at the tail in the Y direction. Pitch is the thrust acting the tail in the Z direction. These are computed from the current IMU rotation matrix and the desired rotation matrix from navigation or manual control.
The output is a motor value, positive yaw means a thrust towards the right hand side (looking forward). Positive pitch mean thrust acting downwards. Standard aircraft axes are used, as defined in Leo Rampen's report.
Pitch K_I
Pitch K_P
Pitch K_D Tail Z Thrust
IMU R Matrix
Desired R Matrix
Tail Y Thrust
Timestep
Yaw K_I
Yaw K_P
Yaw K_D
Page 1 checkRangefinderi2c.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Rangefinder Interface\checkRangefinderi2c.vi Last modified on 19/04/2012 at 16:33 Printed on 24/04/2012 at 16:36
checkRangefinderi2c.vi
FPGA VI Reference In
Previous Range
Simulation
Range error out
error in
This VI polls the i2c rangefinder, and outputs either the previous range (input it) or an updated range depending on whethe it's ready or not. Range in cm.
False Enabled Read the range registers Simulation If it's the first time, returns 0 If it's busy, returns 255 If it's got a range, returns range Read registers 2 and 3 If it's not 255, set the range is what's read. Wait 20 ms, and then tell it to get a new range. If it is 255, do nothing.
Check the output
Range only valid if output != 255
Previous Range
True
Range
0 FPGA VI Reference In 0 255 0 error in 2 pulse rangefinder 0 0 51 error out
Port
1
Bytes To Read
1 70
Page 1
DriveMotors.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\DriveMotors.vi

Last modified on 18/04/2012 at 13:18 Printed on 24/04/2012 at 16:49 DriveMotors.vi
Motors Armed Rear Swivel Angle FPGA VI Reference
Left Motor Right Motor Front Swivel Angle

error in
Rear Motor
Rear Motor PWM FPGA VI Reference Out Right Motor PWM Left Motor PWM Swivel Servo PWM error out Rear Swivel Servo PWM
This VI writes to the FPGA the PWM values required to command the motors and swivel servos for the front and rear motors. It outputs the PWM values commanded (they have saturation points beyond which they won't increase, so it is useful to know the values). This needs to be modified to reflect each individual piece of hardware. Scale the thrust values, and then add the lowest PWM command to get the final output. Set the saturation values for the motors. Servos also need calibration.
False Motors Armed
FPGA VI Reference
error in error out Left Motor Scale 1 Right Motor False
Add
0
2500 Peak current value
True
Left Motor PWM Right Motor PWM Front Swivel Angle Check with testing
True
Swivel Servo PWM
Rear Motor PWM 1 Rear Swivel Servo PWM
Rear Motor
False 1 0 2500 Peak current value
Rear Swivel Angle
Check with testing
True
False
False
True
False
True
True
Page 1 FlightAltitudeController.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\FlightAltitudeController.vi Last modified on 21/04/2012 at 19:37 Printed on 24/04/2012 at 16:47
FlightAltitudeController.vi
FPGA VI Reference Required Altitude Current GPS Altitude Current Rangefinder Altitude Timestep error in FPGA VI Reference Out Pitch Angle error out
This VI takes the required altitude, the current GPS altitude and the current rangefinder altitude and outputs a desired orientation in the pitch axis. If the rangefinder reads under 1 m, then the VI will maintain that height rather than descend.
Check rangefinder If we're away from the ground, hold based on GPS. If we're under 2m, hold based on rangefinder Check GPS altitude
If rangefinder < 1m, set 1 m as required altitude Else, set GPS as required altitude
FPGA VI Reference
Required Altitude
Tr
Current GPS Altitude
Current Rangefinder Altitude Saturation of +/- 0.25 rad (~30 deg) 2 Timestep
0.25
Pitch Angle
-0.25
Altitude K_I error in Altitude K_P error out Altitude K_D Fal Fal
Tr
Tr
Page 1
FrontAngleCalculator.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\FrontAngleCalculator.vi

Last modified on 11/04/2012 at 16:54 Printed on 24/04/2012 at 16:54 FrontAngleCalculator.vi
Front X Thrust Front Z Thrust
Motor Thrust
Motor Swivel Angle
This VI takes as an input the required X and Z forces for the front motors, and converts that to swivel angle and thrust. Differential thrust is currently not calculated, but could be in the future. Swivel angle is +/- pi, from horizontally forward.
Motor Thrust
Front Z Thrust
Resultant Thrust
Motor Swivel Angle
Front X Thrust
Page 1
GetAltitude.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\GetAltitude.vi

Last modified on 21/04/2012 at 19:37 Printed on 24/04/2012 at 16:55 GetAltitude.vi error in
Required Altitude Current GPS Altitude Current Rangefinder Altitude Timestep FPGA VI Reference
FPGA VI Reference Out Front Z Thrust

Tail Z Thrust
error out
This VI takes the required altitude, the current GPS altitude and the current rangefinder altitude and gives two Z axis motor outputs (positive down). If the rangefinder reads under 1 m, then the VI will maintain that height rather than descend.
Check rangefinder Check GPS altitude
If rangefinder < 1m, set 1 m as required altitude
Else, set GPS as required altitude If we're away from the ground, hold based on GPS. If we're under 2m, hold based on rangefinder FPGA VI Reference FPGA VI Reference Out
Required Altitude
Tr Tail Z Thrust
Current GPS Altitude
Hover Altitude K_D
Hover Altitude K_I Hover Altitude K_P Current Rangefinder Altitude
Front Z Thrust
2
Timestep
error out
error in
Fals
Fal
Tru
Page 2
GetAltitude.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\GetAltitude.vi

Tr
Page 1
GetGPS.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\GPS Interface\GetGPS.vi

Last modified on 19/04/2012 at 16:33 Printed on 24/04/2012 at 16:27 GetGPS.vi
FPGA VI Reference
Simulation
Previous GPS data error in
FPGA VI Reference Out GPS data error out
This VI gets the current GPS coordinates. It's designed to request data 6 times from the GPS, yielding all six commonly returned strings. The NMEA parser outputs the GPS data.
False Previous GPS data
FPGA VI Reference Out Return old GPS data if invalid. Iterate 6 times because that gets us all 6 returned strings
Simulation
6 FPGA VI Reference
Check to see if the data's invalid

True
GPS data
error in
Get GPS Coordinates error out
Page 1 InitGPS.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\GPS Interface\InitGPS.vi Last modified on 19/04/2012 at 16:33 Printed on 24/04/2012 at 16:46
InitGPS.vi
FPGA VI Reference error in

Simulation
FPGA VI Reference Out GPS data error out
This VI initiates the GPS. It first checks that NMEA strings are being received from the GPS. It then waits until the NMEA strings are making sense - ie a position has been found. WARNING: This VI *could* run indefinitely if there's no chance of a GPS fix. Consider that before using it.
True
GPS data
GPS data
FPGA VI Reference error out
error in
Simulation
False
Data is now valid Wait for GPS fix Wait for valid data
Initiate serial link
baud rate
9600
data bits
Set to other one normally
parity
None stop bits 1 bit
Page 1
InitIMUi2c.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\IMU Interface\InitIMUi2c.vi Last modified on 18/04/2012 at 13:16 Printed on 24/04/2012 at 16:57
InitIMUi2c.vi
FPGA VI Reference
Simulation
FPGA VI Reference Out error out
error in
This VI transfers data to and from the FPGA VI to send and receive bytes from an I2C port. It's hard coded for our "Sens Stick" IMU. Input - FPGA reference and error. Output - FPGA referance and error. Connect it in your init code, and use it' sister function (IMU read) to get data at control loop speed.
False
Disabled
Init magnetometer FPGA VI Reference Init accelerometer

Init IMU i2c bus
Init gyro FPGA VI Reference Out Writing to register 16: binary 11011 (see notebook)
0 0 error in
2D 8
10110 11011
2 0 error out
100000
1E
68
Simulation
0 53
Enabled
True
Page 1 initRangefinderi2c.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Rangefinder Interface\initRangefinderi2c.vi Last modified on 18/04/2012 at 13:16 Printed on 24/04/2012 at 16:51
initRangefinderi2c.vi
FPGA VI Reference error in

Simulation
FPGA VI Reference Out error out
This VI inits the SRF02 Ultrasonic Rangefinder device i2c bus. Call it once in init.
FPGA VI Reference
False Disabled Init Rangefinder i2c bus error in
error out
Simulation
400000
Enabled
True
Page 1 NavigationMain.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Navigation\NavigationMain.vi Last modified on 21/04/2012 at 19:35 Printed on 24/04/2012 at 16:38
NavigationMain.vi Holding Info Holding Info Out Flight Mode Desired Velocity
Current Waypoint
Timestep GPS data Homepoint
Desired Orientation
Waypoint Array
This VI conducts navigation algorithms.
Current Waypoint Out Desired Altitude
It has three steps. Initially, it loads information from the waypoint array passed, and decides the target and previous coordinates. It then determines the flight mode based on the waypoint array. This is either hover, flight or land. If hover, the VI will maintain hover for the time described in the waypoint array.
Finally, depending on flight mode it produces control outputs - desired orientation (roll and pitch are 0), desired velocity an desired altitude.
Read the waypoint parameters, set target coordinates, past coordinates

Timestep
See how far we are from the target waypoint GPS Coordinates Current Waypoint Array Target Coordinates Acceptance Radius These are where we want to go
Pass Through True 5 False
Get current waypoint Waypoint Array
Check the waypoint parameters
We're in the acceptance radius. Either start the

False
Target Coordinates Current Waypoint

7 8 4 Homepoint 3 6 Land Hold Yaw Angle
Hold Time Hold Time
0 3 True
Acceptance Radius
We're not going to the homepoint
Land
Current Waypoint
Holding Waypoint Holdi
Holding Info
False Start Hold Time These are where we're coming from
Hover
Previous Coordinates
Holding Waypoint 0 3
GPS Latitude GPS data GPS Longitude
Get previous waypoint for path following. If no previous defined, use homepoint
GPS Bearing
GPS Coordinates
GPS Alititude GPS Velocity
0.51444
False
False
False
"Land"
We're not there yet, so set flight mode to false

0 0 3 3 We're not going to the homepoint Flight Flight Mode
True
True
0 Desired velocity is 0
Desired Veloc
3 If we're going to the homepoint
Hold Yaw Angle
0 0
Desired Or
Desired orientation
"Flight", Default
Current Waypoint Out Current Waypoint
hover timer and hover, or move on to t If we're to land, disregard everything else Previous Coordinates Target Coordinates GPS Coordinates
False 2 0 0
0 0 0 Flight Mode
Desired Orientation Desired Orientation
Desired Altitude Calculate distance travelled, and scale the desired path vector by that to get an approximate altitude you should be at.
Desired Velocity
Flight Mode Start Hold Time
Forward Flight Speed Calculation Flight Mode Pass Through False Simple proportional forward flight speed
Desired Altitude
Saturated speed if true GPS Coordinates Target Coordinates Proportional constant 0.5
Desired Velocity
Minimum speed
Saturation speed
00:00:00.000 DD/MM/YYYY 0 Holding Info Out Start Hold Time Holding Waypoint
Saturation Speed
5
True
"Flight", Defa
We're in the acceptance radius. Either start the hover timer and hover, or move on to the next waypoint
False
If we're to land, disregard everything else
Previous Coordinates
True Land False
Target Coordinates GPS Coordinates

2 Holding Waypoint Holding Waypoint
Current Waypoint
Hold Time
Start Hold Time
Calculate distance travelled, and scale the desired path vector by that to get an approximate altitude you should be at.
Hover
Flight Mode
Forward Flight Speed Calculation False Simple proportional forward flight speed Pass Through
GPS Coordinates Target Coordinates Saturation Speed

5
Proportional constant 0.5
Saturation
Minimum s
False
Simple prop
If we're to land, disregard everything else GPS Coordinates

True
Target Coordinates
False
Current Waypoint
Hold Time
Holding Waypoint
Holding Waypoint
Start Hold Time
Hover
Flight Mode
"Hover"
False
Not holding - move on to the next waypoint
Flight
Flight Mode
Target Coordinates
2
Current Waypoint
Current Waypoint
Set target altitude from waypoint

0 Desired velocity is 0
0 0 True Hold Yaw Angle
Desired orientation
False
Current Waypoint
Holding Waypoint Holding Waypoint
Start Hold Time
Hover
Flight Mode
False
Holding Waypoint
Start Hold Time
Hover
Flight Mode
True True We're here because the current waypoint is being held on, but has passed it's hold time.
Start Hold Time
Current Waypoint
Current Waypoint
Increment current waypoint

Flight Flight Mode
Set flight mode to "flight"
0 0
Desired Orientation
Desired Altitude
Saturated speed if true
Desired Velocity
False
Saturated speed if true Proportional constant 0.5

Minimum speed
Saturation speed
True
Desired Altitude
Desired Velocity
Desired Orientation
False We're still hovering
Hover
Flight Mode
True We're here because the current waypoint is being held on, but has passed it's hold time.
Current Waypoint
Current Waypoint
Increment current waypoint

Flight Flight Mode
Set flight mode to "flight"
True
Land
Flight Mode
Page 1
OutStringParse.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Communications\OutStringParse.vi

Last modified on 12/04/2012 at 10:45 Printed on 24/04/2012 at 16:50 OutStringParse.vi Command Byte Input String error in (no error) String to Send
error out
Use this VI to convert a spreadsheet string into one suitable for transmission. The command integer specified is concatenated, and EoL characters are converted to ampersands for easier transmission and subsequent parsing.
Command Byte Command 4 bytes
String to Send
Replace EoL with & Input String
error out
error in (no error)
&
Page 1 PID.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\PID.vi Last modified on 21/04/2012 at 19:34 Printed on 24/04/2012 at 16:48
PID.vi K_D
K_I
Timestep (ms)
result
K_P
Setpoint
Current Value
This is a simple PID implementation. Give it a setpoint and current value, plus a bunch of gains, and it'll do the rest.
Setpoint Reset All Feedback
Current Value
Integrator
0 K_I
K_P
result
Proportional
Timestep (ms)
1000
K_D
Derivative
Reset All Feedback
Page 1 ReadIMUi2c.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\IMU Interface\ReadIMUi2c.vi Last modified on 19/04/2012 at 16:33 Printed on 24/04/2012 at 16:23
ReadIMUi2c.vi error in Previous R Matrix
FPGA VI Reference
Simulation
Previous Gyro Correction Timestep Previous Integral Term
FPGA VI Reference Out error out Gyro Correction Integral Term R Matrix
This VI reads the IMU. Addresses are hard coded. It takes the FPGA reference (opened and with the IMU inited already) and outputs the orientation of the IMU. Call it at whatever frequency you want to read the IMU.
Simulation
False
Enabled Previous Integral Term
Timestep
Previous R Matrix Accelerometer Raw
The final accelerometer data (x, y, z)

Accelerometer G
Gyroscope Raw
0 0 1 1 2
Previous Gyro Correction
2 3 4 5
Convert into numbers FPGA VI Reference

0 is least significant bit 1 is most significant
Read the gyro values

0 1D
Read the magn values 0 0 3 1 2 3
cross over wires

0 error in 0 0 1 2 3 4 5
32
0
53
6
68
6
4 5
256
1E 6
Page 2 ReadIMUi2c.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\IMU Interface\ReadIMUi2c.vi Last modified on 19/04/2012 at 16:33 Printed on 24/04/2012 at 16:23
R Matrix
Gyro Correction
Timestep
Filter the output
Previous R Matrix Previous Gyro Correction

Previous Integral Term
Integral Term
120 -6
14.375
appended array
-20
Computing magnetometer orientation vector
Magnetometer
True
0 1 2 0
Magnetometer is orientated differently on the chip - swap x and y
http://stackoverflow.com/questions/1251828/calculate-rotations-to-look-at-a-3d-point
error out
Page 1 ReceivedStringInitialParse.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Communications\ReceivedStringInitialParse.vi Last modified on 12/04/2012 at 10:45 Printed on 24/04/2012 at 16:52
ReceivedStringInitialParse.vi
Received String
error in (no error)
Received Data
Command Integer
error out
This VI takes received data strings and strips out the command byte. It also converts any ampersands to EOL characters. The returned string can be put straight into the spreadsheet string to array function.
Received Data
Received String
&
Command Integer
0
error in (no error)
error out
Page 1 TailAngleCalculator.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\TailAngleCalculator.vi Last modified on 11/04/2012 at 16:49 Printed on 24/04/2012 at 16:56
TailAngleCalculator.vi
Tail Y Thrust Tail Z Thrust
Tail Thrust Tail Swivel Angle
This VI takes required Y and Z thrusts for the tail and converts them into a positive thrust value and a swivel angle. Swivel angle is defined as +/- pi, where 0 is vertically upwards (although the Z axis acts downwards, the motor spends most of it's time providing an upwards thrust).
Tail Z Thrust Tail Thrust
Resultant Thrust
Tail Swivel Angle

Tail Y Thrust
Page 1
VelocityControl.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\cRIO-ReadIMU\Control Loops\VelocityControl.vi

Last modified on 21/04/2012 at 19:37 Printed on 24/04/2012 at 16:53 VelocityControl.vi Desired Velocity GPS Velocity Timestep This VI takes in the desired and current GPS velocity, and computes X axis front motor thrust from it.
Desired Velocity
Front X Thrust
Front X Thrust GPS Velocity
Timestep
Velocity K_I Velocity K_P
Velocity K_D
Leo Rampen
April 26, 2012
B.
Test Interface Groundstation - LabVIEW VIs
A test interface for communicating with the aircraft and control system was developed. Demonstrated in the following pages is its front and back end. The mapping interface is described further in Section 4.2.
70
Page 1 Temp-GSFrontend.vi N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\ Software\FPGA IO\GS-Comms\Temp-GSFrontend.vi Last modified on 20/04/2012 at 18:11 Printed on 24/04/2012 at 22:26
Temp-GSFrontend.vi
LoadWPData
5 6
Map Interface This is a rudimentary interface to the Leeds Blimp. It's designed to let you send and receive relevant data. Use it for a better groundstation. Blimp Current Waypoint
0
Latitude
0
GPS Velocity
0 GPS Headi ng 0
Longitude
0
GPS Altitude
0
Rangefinder Altitude
0
Right Motor Setting

0
Left Motor Setting

0
Rear Motor Setting

0
Front Swivel Angle

0
Rear Swivel Angle

0
Elevator Angle
0
Rudder Angle
0
R Matrix (Orientation)
0 0 0 0 0 0 0 0 0 0 0
Blimp Address
Simulation Enabled
192.168.0.2
Heartbeat Received
Shut Down Blimp
point 0,0 is the "reset all feedback nodes" value. Set it to 1 for a little while to set them all to 0. PID Constants Last Heartbeat Time
00:00:00.000 D D /MM/YYYY 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Heartbeat String
0 0 0 0
Order is: K_I, K_P, K_D Velocity Altitude Yaw Pitch Hover Altitude Hover Yaw
We're getting data claiming to be a heartbeat, but it's not got the right text in it! Nonsense Heartbeat Received
Data GS to Blimp
This does very little. Ignore for now.

Shut D own
Data Blimp to GS
User Defined Stuff Change values to send to blimp Camera Config

0 0 0 0 0 0
Map Errors status code

0
Aircraft Config
0
source
0 0 0 0 0
Manual Control Commands

0 0 0 0 0 0 0 0
Comms Parse Data Error Viewpoint Array

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
status
code
0
source
0 0 0 0 0 0 0
Output Data Error status code

56
source TCP Open Connection in TCPSendClient.vi->TempGSFrontend.vi
Waypoint Array
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
Homepoi nt 0 0 0 0 0 0 0 0
Doesn't actually do anything yet
Shut Down Position information from the blimp Blimp orientation Blimp Heartbeat
Latitude
R Matrix (Orientation) GPS Velocity
Last Heartbeat Time
Current vehicle command state Left Motor Setting Front Swivel Angle Elevator Angle
Current Blimp Waypoin
Longitude
Nonsense Heartbeat Received

Rangefinder Altitude Right Motor Setting Rear Swivel Angle Rudder Angle
Blimp Current Waypo
GPS Altitude GPS Heading
Heartbeat Received
Rear Motor Setting
Read map waypoints
IWebBrowser2
Refresh Map Interface

IWebBrowser2 http://localhost:5000/map
Navigate URL Flags TargetFrameName PostData Headers

2000
LoadWPData IWebBrowser2 IWebBrowser2 IWebBrowser2
Navigate URL Flags TargetFrameName PostData Headers
Refresh
Busy
Start the server

"N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\Software\Waypoint Mapping\MapServer\runServer.bat" http://localhost:5000/map/wp-labview
N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\Software\Waypoint Mapping\MapServer latitude= Latitude longitude= Longitude altitude= GPS Altitude
&
Save GPS location to map
http://localhost:5000/map/
Comms In and Out - Send data to TCP server on blimp, receive data back and queue it.
GS to Blimp Blimp to GS Blimp Address
Output Data Error
5131
Blimp Address
Shut down and no remaining queue elements
Shut Down
Set up named queues for data transfer
Parse Received Data - Initiate replies Parse data received and copy it into the right variables
Run Comms loop
100
Blimp to GS
Data Blimp to GS
True
Check for entities in queue

Blimp to GS
21
Data GS to Blimp
100
GS to Blimp
0 1 2 R Matrix (Orientation)
Heartbeat Checker
If a heartbeat was received in the last 3 seconds, set to true. Otherwise, set to false.
False
Heartbeat Received
Last Heartbeat Time
GS to Blimp
SEND-DATA
Shut Down
Send Config and Control Data If the waypoint array indicator has changed, and there's a connection to the blimp, add the new array to the queue.
User defined stuff
Waypoint Array
if there's no heartbeat received, don't change the shift register (ie the change will be persistently registered until data sent).
True GS to Blimp
Heartbeat Received
Viewpoint Array
True GS to Blimp
IHTML2Document
IWebBrowser2
Document IHTMLDocument2 IHTMLElement innerHTML \s
body
Waypoint Array
Map Errors
save-bli
Comms Parse Data Error
Shut Down
3
Camera Config
GS to Blimp
True
True GS to Blimp
Aircraft Config
5
Manual Control Commands
False
Homepoint
True GS to Blimp
Shut Down Blimp
True GS to Blimp
Shut Down
True Simulation Enabled GS to Blimp
10
Get GPS (4 Hz) True GS to Blimp
Heartbeat Received
20
Shut Down
Get Orientation and Control Settings (10 Hz)

True GS to Blimp
get current blimp waypoint 21 26

Shut Down
Heartbeat Received
22
Get Checksums (1 Hz)
True GS to Blimp
24
Heartbeat Received
25
27
28
Shut Down
Send Simulation Data True GS to Blimp
Heartbeat Received
Simulation Enabled
11
12
13
IMU Roll Pitch Yaw
GPS Data
Rangefinder Altitude
Send Simulation Data True GS to Blimp
Heartbeat Received
Simulation Enabled
14
PID Constants
Leo Rampen
April 26, 2012
C.
Navigation Simulation - MATLAB Code
This is discussed in Section 4.2.
76
22/04/12 01:10
W:\TempWithoutM\PlotTrajectory.m
1 of 3
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % This is: PlotTrajectory.m % % Also Required: arrows.m % % - - - - - - - - - - - - - - - - - - - - - - - % % Author : LEO RAMPEN % % This file simulates the navigation system % % of the Leeds Blimp. It prints to a graph % % approximate paths based on the PID values % % and entered wind speed. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
clear all; clc; hold off; %Define the past and target waypoints PastLocation = [40,100]; TargetLocation = [160, 100]; %Plot a line between the two plotPoint1 = [PastLocation(1), TargetLocation(1)]; plotPoint2 = [PastLocation(2), TargetLocation(2)]; plot(plotPoint1, plotPoint2) axis([0 200 0 200]); %Set the axis scale hold on; %Plot markers for the target and past waypoints plot(PastLocation(1), PastLocation(2), 'Marker','p','Color','red', 'MarkerSize',15); plot(TargetLocation(1), TargetLocation(2), 'Marker','*','Color','green', 'MarkerSize', 20); %Define our wind speed WindSpeed = 6; %in pixels/step WindDirection = [0, 10]; %A 2D vector %Calculate the direction vector for the stated wind Wind = (WindDirection/norm(WindDirection)) * WindSpeed if (WindSpeed > 0) %Plot our wind on the graph ArrowTip = [120, 50]; ArrowBase = ArrowTip - (10*Wind); arrow(ArrowBase, ArrowTip); end %Define our aircraft disp('1 for past location, 2 for random'); %StartPosInput = input('Where do you want to start?'); StartPosInput =1; switch StartPosInput case 1 StartingPosition = PastLocation; case 2 posX = round(rand(1)*200);
22/04/12 01:10
2 of 3
posY = round(rand(1)*200); StartingPosition = [posX, posY]; end AircraftSpeed = 5 %in pixels/step AircraftPosition = StartingPosition; %Set the initial aircraft position PathBearing = atan2((TargetLocation(2) - PastLocation(2)), (TargetLocation(1) PastLocation(1))); %The bearing of the path we're following if (PathBearing < 0) PathBearing = PathBearing + 2*3.141596; end
%Plot the aircraft's initial position plot(AircraftPosition(1), AircraftPosition(2), 'Marker','d','Color','black','MarkerSize',5); dist = sqrt((AircraftPosition(1) - TargetLocation(1))^2 + (AircraftPosition(2) TargetLocation(2))^2); %Calculate the distance to the target %Control loop constants K_I = 0; K_P = 3; K_D = 0; %Calculate bearing to target BearingToTarget = atan2((TargetLocation(2) - AircraftPosition(2)), ( TargetLocation(1) - AircraftPosition(1))); if (BearingToTarget < 0) BearingToTarget = BearingToTarget + 2*3.141596; end %Calculate the initial bearing error BearingError = BearingToTarget - PathBearing; PrevBearingError = BearingError; %Initialise bearing IntegralBearing = BearingToTarget;
i = 0; while (dist > 15) && (i < 80) %Compute the distance to the target dist = sqrt((AircraftPosition(1) - TargetLocation(1))^2 + (AircraftPosition(2) TargetLocation(2))^2); %Calculate the distance to the target %Compute the bearing to the target BearingToTarget = atan2((TargetLocation(2) - AircraftPosition(2)), ( TargetLocation (1) - AircraftPosition(1))); if (BearingToTarget < 0) BearingToTarget = BearingToTarget + 2*3.141596; end %Control loops. Get the error BearingError = BearingToTarget - PathBearing; %Very simple integral control IntegralBearing = IntegralBearing + (BearingError * K_I);
22/04/12 01:10
3 of 3
%And proportional ProportionalBearing = K_P * BearingError; %And differential DifferentialBearing = K_D * (BearingError - PrevBearingError); PrevBearingError = BearingError; %Total bearing AircraftBearing = IntegralBearing + ProportionalBearing + DifferentialBearing; %Compute X and Y values for velocity VelocityAdjustment = [((AircraftSpeed) * cos(AircraftBearing)), ((AircraftSpeed) * sin(AircraftBearing))]; %Compute new aircraft position AircraftPosition = AircraftPosition + VelocityAdjustment + Wind; %plot our new position plot(AircraftPosition(1), AircraftPosition(2), 'Marker','diamond','Color','black', 'MarkerSize',5); pause(0.1); i = i + 1; end
Leo Rampen
April 26, 2012
D.
Sensor Fusion Validation - MATLAB Code
80
24/04/12 22:15
hold off clear all
M:\MATLAB\IMU\PlotIMU.m
1 of 4
FileToLoad = 'IMUDataSlowRotate.txt'; F = csvread(FileToLoad); Acc(:,1) = F(:,1); Acc(:,2) = F(:,2); Acc(:,3) = F(:,3); Magn(:,2) = F(:,4); %magnetometer X and Y swapped on the board. Magn(:,1) = F(:,5); Magn(:,3) = F(:,6); Gyro(:,1) = F(:,7); Gyro(:,2) = F(:,8); Gyro(:,3) = F(:,9); %Define the timestep dt = 0.05; %seconds %Correct the accelerometer Acc = Acc/256; %Correct the gyro %Gyro = Gyro + Gyro_Correction; %GyroOffset = sum(Gyro)/size(Gyro, 1); %These came out as: -117.962, 5.268 and 20.781 Gyro(:,1) = Gyro(:,1) + 117.962; Gyro(:,2) = Gyro(:,2) - 5.268; Gyro(:,3) = Gyro(:,3) - 20.781; Gyro = Gyro/14.375; Gyro = (Gyro*2*pi())/360; %Correct the magnetometer %do simple integration R_gyro = eye(3); R = eye(3) i=2; % %rotation matrix - just integration % while (i<=size(F, 1)) % %Integrate gyro readings % d_theta_x = Gyro(i,1)*dt; % d_theta_y = Gyro(i,2)*dt; % d_theta_z = Gyro(i,3)*dt; % %build a matrix for this step % R_gyro_step = [1, (-d_theta_z), d_theta_y; d_theta_z, 1, (-d_theta_x); (d_theta_y), d_theta_x, 1]; % %Total rotation % R_gyro = R_gyro*R_gyro_step; % i = i+1; % end %Simple integration method
24/04/12 22:15
2 of 4
i = 2 integ_orientation = [0 0 0]; while (i<= size(F,1)) %integrate and store integ_orientation(i,1) = Gyro(i,1)*dt + integ_orientation(i-1,1); integ_orientation(i,2) = Gyro(i,2)*dt + integ_orientation(i-1,2); integ_orientation(i,3) = Gyro(i,3)*dt + integ_orientation(i-1,3); if (integ_orientation(i,1) < -pi()) integ_orientation(i,1) = integ_orientation(i,1) + 2*pi(); elseif (integ_orientation(i,1) > pi()) integ_orientation(i,1) = integ_orientation(i,1) - 2*pi(); end if (integ_orientation(i,2) < -pi()) integ_orientation(i,2) = integ_orientation(i,2) + 2*pi(); elseif (integ_orientation(i,2) > pi()) integ_orientation(i,2) = integ_orientation(i,2) - 2*pi(); end if (integ_orientation(i,3) < -pi()) integ_orientation(i,3) = integ_orientation(i,3) + 2*pi(); elseif (integ_orientation(i,3) > pi()) integ_orientation(i,3) = integ_orientation(i,3) - 2*pi(); end i = i+1; end i=2; Gyro_Correction = zeros(3); correct_orientation(1, :) = [0 0 0]; I_Correction = 0; %Full DCM method % while(i<=size(F,1)) %Integrate gyro readings and add on corrections %Equation 17 d_theta_x = Gyro(i,1)*dt - Gyro_Correction(1); d_theta_y = Gyro(i,2)*dt - Gyro_Correction(2); d_theta_z = Gyro(i,3)*dt - Gyro_Correction(3); %build a matrix for this step R_gyro_step = [1, (-d_theta_z), d_theta_y; d_theta_z, 1, (-d_theta_x); (d_theta_y), d_theta_x, 1]; %Total rotation R = (R*R_gyro_step); %%%%%%%%%%%%%%%%% %Renormalisation% %%%%%%%%%%%%%%%%% %Equations 18, 19 20 and 21 error = dot(R(1,:),R(2,:)'); X_orth = R(1,:)' - ((error/2)*R(2,:)'); Y_orth = R(2,:)' - ((error/2)*R(1,:)'); Z_orth = cross(X_orth,Y_orth);
24/04/12 22:15
3 of 4
X_orth = X_orth/norm(X_orth); Y_orth = Y_orth/norm(Y_orth); Z_orth = Z_orth/norm(Z_orth); R(1,:) = X_orth; R(2,:) = Y_orth; R(3,:) = Z_orth; %%%%%%%%%%%%%%%%%%%% %Drift cancellation% %%%%%%%%%%%%%%%%%%%% %Magnetometer bearing %This is from http://code.google.com/p/ardu-imu/source/browse/branches/ArduIMU% 20v1.7/Compass.pde cos_roll = cos(integ_orientation(i,1)); sin_roll = sin(integ_orientation(i,1)); cos_pitch = cos(integ_orientation(i,2)); sin_pitch = sin(integ_orientation(i,2)); %tilt compensated X Magn_X = Magn(i,1)*cos_pitch + Magn(i,2)*sin_roll*sin_pitch + Magn(i,3) *cos_roll*sin_pitch; %Tilt compensated Y Magn_Y = Magn(i,2)*cos_roll-Magn(i,3)*sin_roll; Magn_Bearing = -atan2(-Magn_Y,Magn_X); COGX = cos(Magn_Bearing); COGY = sin(Magn_Bearing); % O_to_N = norm(Magn(i,:)); O_to_Axis = norm([Magn(i,1),Magn(i,3)]); Magn_Bearing = asin(O_to_Axis/O_to_N); %Our global frame bearing BearingCapture(i) = Magn_Bearing; Magn_X = O_to_Axis/O_to_N; Magn_Y = Magn(i,2)/O_to_N; %Yaw correction in the global frame %Equations 23 and 24 Yaw_Correction = R(1,1)*COGY - R(2,1)*COGX; Yaw_Correction = Yaw_Correction*R(3,:)'; %Skip the centrifugal stuff because we have no velocity %Equation 27 RollPitch_Correction = cross(R(3,:)',Acc(i,:)'); %%%%%%%%%%%%%%%%%%%%% %Feedback controller% %%%%%%%%%%%%%%%%%%%%% W_RP = 0.1; W_Y = 0.3; K_P = 1; K_I = 1;%2,5 Total_Correction = W_RP*RollPitch_Correction + W_Y*Yaw_Correction; P_Correction = K_P*Total_Correction; I_Correction = I_Correction + K_I*dt*Total_Correction;
% % % %
24/04/12 22:15
4 of 4
Gyro_Correction = P_Correction + I_Correction; %Look at rotation around X correct_orientation(i,1) = %Around Y - the pitch axis correct_orientation(i,2) = %Around Z - the yaw axis correct_orientation(i,3) = the roll axis. asin(dot(R(3,:),R(:,1)')); asin(dot(R(3,:),R(:,2)')); -asin(dot([R(1,1),R(2,1),0],[0, 1, 0]));
% % % % %
%Try something else %roll correct_orientation(i,1) = atan2(R(3,2),R(3,3)); %pitch correct_orientation(i,2) = -asin(R(3,1)); %yaw correct_orientation(i,3) = atan2(R(2,1),R(1,1)); i = i+1; end p = plot(correct_orientation(:,1),'Color','red') xlabel('Timestep (0.05 seconds)') ylabel('Orientation (rad)') hold on fixed_int_orient = integ_orientation; plot(fixed_int_orient(:,1)) %plot(BearingCapture(:), 'color', 'green')
Leo Rampen
April 26, 2012
E.
EAGLE CAD Circuit Diagrams and PCB Designs
The three boards designed are shown below, and their circuit schematics follow.
85
Leo Rampen
April 26, 2012
Figure E.0.1: The breakout board PCB design for the GS1011 wireless module.
Figure E.0.2: The design for a stripboard based IO pin breakout board for the sensors. 86
23/04/2012 00:21:49 C:\Users\Leo\Dropbox\LeoRampenGS1011Breakout.sch (Sheet: 1/1)
1 2 3 4
1 2 3 4
11 10 9 8 7 6 5 4 3 2 1
1 2 3 4
23/04/2012 00:23:12 C:\Users\Leo\Documents\eagle\Second RIO PCB\SensorBreakoutBoard.sch (Sheet: 1/1)
1 2
1 2
1 2
1 2 3
1 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
1 2 3 4 5 6 7
1 2 3 4 5 6
23/04/2012 00:40:10 C:\Users\Leo\Documents\eagle\Second RIO PCB\ServoBreakoutBoardWmods.sch (Sheet: 1/1)
Leo Rampen
April 26, 2012
Figure E.0.3: The design of the stripboard based servo breakout board.
90
Leo Rampen
April 26, 2012
F.
Interactive Waypoint Selection Map Code
The interactive waypoint selection map is designed to run on the groundstation. The current implementation uses a LabVIEW internet control as can be seen in the rst images. The code is launched by a BAT le which runs the ServeMaps.py web server. This acts as a gateway between LabVIEW and the Javascript and HTML based mapping interface.
91
N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\Software\Waypoint Mapping\MapServer\ServeMaps.py 24 April 2012 15:31
##################################################### # This is a web server using the Bottle framework # # It is designed to store and communicate waypoint # # information for the Leeds Blimp. # # Data is stored in SQLite. The JS map interacts # # through a POST based API and a JSON interface. # # See the corresponding map.tpl for the javscript. # ##################################################### import sqlite3 from bottle import get, post, request, route, run, template, static_file import time @route('/map') @route('/map/') def index(): return template('map') @route('/static/<filepath:path>') def server_static(filepath): return static_file(filepath, root= 'N:/Faculty-of-Engineering/Mech-Eng/Learning+Teaching/UG-Projects-11-12/Level 4/airship_platform/Software/Waypoint Mapping/MapServer/static') @post('/map/post') def save_waypoints(): conn = sqlite3.connect('blimp-data.db') conn.execute("create table if not exists waypoints (id INTEGER PRIMARY KEY, wporder INTEGER NOT NULL, latitude real NOT NULL, longitude real NOT NULL, altitude REAL NOT NULL, hover REAL NOT NULL, acceptance REAL NOT NULL, yaw REAL NOT NULL, viewpoint INTEGER NOT NULL, passthrough integer NOT NULL, launchpoint integer NOT NULL, land integer NOT NULL)") new_save = request.forms.get('new_save','') if new_save == "1": conn.execute("DELETE FROM waypoints") c = conn.cursor() wporder = request.forms.get('order','').strip() latitude = request.forms.get('latitude','').strip() longitude = request.forms.get('longitude','').strip() altitude = request.forms.get('altitude','').strip() hover = request.forms.get('hover','').strip() acceptance = request.forms.get('acceptance','').strip() yaw = request.forms.get('yaw','').strip() viewpoint = request.forms.get('viewpoint','').strip() passthrough = request.forms.get('passthrough','').strip() launchpoint = request.forms.get('launchpoint','').strip() land = request.forms.get('land','').strip() c.execute("INSERT INTO waypoints (wporder, latitude, longitude, altitude, hover, acceptance, yaw, viewpoint, passthrough, launchpoint, land) VALUES (?,?,?,?,?,?,?,?,?,?,?)",(wporder, latitude, longitude, altitude, hover, acceptance, yaw, viewpoint, passthrough, launchpoint, land)) conn.commit() c.close() return {'saved':'true'} @route('/map/wp-labview')
-1-
def return_labview_waypoints(): conn = sqlite3.connect('blimp-data.db') c = conn.cursor() c.execute("SELECT * FROM waypoints ORDER BY wporder ASC") all_waypoints_fetched = c.fetchall() c.close() all_waypoints = all_waypoints_fetched[:-1] #remove the last, empty part spreadsheet_string = "" for waypoint in all_waypoints: for column in waypoint[2:]: if str(column) == "true": column = 1 if str(column) == "false": column = 0 spreadsheet_string += str(column) + "\t" spreadsheet_string = spreadsheet_string[:-1] #remove the last tab spreadsheet_string += "*" return spreadsheet_string @post('/map/save-blimp-loc') def load_labview_data(): conn = sqlite3.connect('blimp-data.db') conn.execute("create table if not exists blimp (id INTEGER PRIMARY KEY, timestored INTEGER NOT NULL, latitude REAL NOT NULL, longitude real NOT NULL, altitude real NOT NULL)") blimp_latitude = request.forms.get('latitude','').strip() blimp_longitude = request.forms.get('longitude','').strip() blimp_altitude = request.forms.get('altitude','').strip() current_time = time.time() c = conn.cursor() c.execute("INSERT INTO blimp (timestored, latitude, longitude, altitude) VALUES (?,?,?,?)",(current_time, blimp_latitude, blimp_longitude, blimp_altitude)) conn.commit() c.close() return {'saved':'true'} @get('/map/blimp-loc') def get_blimp_location(): conn = sqlite3.connect('blimp-data.db') c = conn.cursor() c.execute("SELECT * FROM blimp ORDER BY timestored DESC LIMIT 20;") latest_blimp_location= c.fetchall() c.close() return_dict = {} i = 0 for location in latest_blimp_location: location_dict = { 'latitude' : location[2], 'longitude' : location[3], 'altitude' : location[4] } return_dict[i] = location_dict i += 1 return return_dict
-2-
@route('/map/wp-json') def return_json_waypoints(): conn = sqlite3.connect('blimp-data.db') c = conn.cursor() c.execute("SELECT * FROM waypoints ORDER BY wporder ASC") all_waypoints_fetched = c.fetchall() c.close() all_waypoints = all_waypoints_fetched[:-1] #remove the last, empty part json_return = {} json_return['total'] = len(all_waypoints) #tell the reader the total number of waypoints for i in range(0,len(all_waypoints)): waypoint_name = "wp-" + str(i) #build a dict for this waypoint waypoint_dict = { 'latitude' : all_waypoints[i][2], 'longitude' : all_waypoints[i][3], 'altitude' : all_waypoints[i][4], 'hover' : all_waypoints[i][5], 'acceptance' : all_waypoints[i][6], 'yaw' : all_waypoints[i][7], 'viewpoint' : all_waypoints[i][8], 'passthrough' : all_waypoints[i][9], 'launchpoint' : all_waypoints[i][10], 'land' : all_waypoints[i][11]}
json_return[waypoint_name] = waypoint_dict return json_return debug=True run(host='localhost', port=5000)
-3-
N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\Software\Waypoint Mapping\MapServer\static\MapConfiguration.js 24 April 2012 15:39
/* This is a javascript map configuration file for the Leeds Blimp It defines the map used, makes markers on click events, lets you define the markers, stores marker data and uploads it to the server (ServeMaps.py). It also loads the waypoints off the server and prints a little blimp where the blimp is. Fun! File by Leo Rampen, 2012 */ //make the map! var map = new L.Map('map'); var cloudmade = new L.TileLayer( 'http://{s}.tile.cloudmade.com/aab6906c5c674866b4ffe070cb508b43/997/256/{z}/{x}/{y}.png', { attribution: 'tim', maxZoom: 18 }); var leeds = new L.LatLng(53.8081524683, -1.55937194824); // geographical point (longitude and latitude) map.setView(leeds, 16).addLayer(cloudmade);
//declare some waypoint management variables var markers = new Array(); var marker_counter = 0; var all_waypoint_data = new Array(); var waypoint_order = new Array(); var polyline = new L.Polyline(leeds, {color: 'red'}); var blimpline = new L.Polyline(leeds, {color: 'blue'}); //make an icon var blimpIcon = new L.Icon(); blimpIcon.iconUrl = '/static/blimp.gif'; blimpIcon.iconSize = new L.Point(43, 23); blimpIcon.iconAnchor = new L.Point(21, 18); blimpIcon.popupAnchor = new L.Point(-2, 0); //create the blimp icon var blimp_marker = new L.Marker(leeds, {icon: blimpIcon}); //new marker from blimp location var checkBlimpLocation = setInterval(getBlimpLocation, 5000); loadPreviousWaypoints() //get the previous waypoints map.on ('click', function(e) { var marker_id = marker_counter; //unique marker ID var waypoint_data = new Array(); //to store the waypoint data waypoint_data["order"] = (waypoint_order.length); //set the order as last waypoint_order[(waypoint_order.length)] = marker_id; //Set the last waypoint as the one we just created. waypoint_data["latitude"] = e.latlng['lat']; //store lat and long waypoint_data["longitude"] = e.latlng['lng'];
-1-
//keep zeroed until defined. waypoint_data["altitude"] = '0'; waypoint_data["hover"] = '0'; waypoint_data["acceptance"] = '5'; waypoint_data["yaw"] = '0'; waypoint_data["viewpoint"] = '0'; waypoint_data["passthrough"] = false; waypoint_data["launchpoint"] = false; waypoint_data["land"] = false; modifyMarker(waypoint_data, marker_id, true); marker_counter ++; });
function removeMarker(marker_id) { map.removeLayer(markers[marker_id]); var order_index = include(waypoint_order, marker_id); if ( typeof order_index !== "undefined" ) waypoint_order.splice(order_index, 1); updateAllMarkers() } function clearAllWaypoints() { for (var i = 0; i < waypoint_order.length; i++) { map.removeLayer(markers[waypoint_order[i]]); } all_waypoint_data.length = 0; waypoint_order.length = 0; updateAllMarkers(); } function getBlimpLocation() { var url = "/map/blimp-loc?_=" + new Date().getTime(); $.ajax({ cache: false, success: function(data){ var blimp_location = new Array(); var past_locations = new Array(); blimp_location['latitude'] = data['0'].latitude; blimp_location['longitude'] =data['0'].longitude; blimp_location['altitude'] = data['0'].altitude; var new_lat_long = new L.LatLng(blimp_location.latitude, blimp_location.longitude ); map.removeLayer(blimp_marker); blimp_marker = new L.Marker(new_lat_long, {icon: blimpIcon}); //new marker from blimp location map.addLayer(blimp_marker); //add it to the map //draw the line if there's more than 1 marker. map.removeLayer(blimpline); for (var c = 0; c<20;c++) { if (typeof data[c] !== "undefined") {
-2-
if (data[c].latitude !== "") { past_locations.push(new L.LatLng(data[c].latitude, data[c].longitude )); //store the lat/long of each marker } } } blimpline = new L.Polyline(past_locations, {color: 'blue'}); map.addLayer(blimpline); }, url: url}); }
function loadPreviousWaypoints() { var url = "/map/wp-json?_=" + new Date().getTime(); $.ajax({ cache: false, success: function(data){ clearAllWaypoints(); //remove any old waypoints var wp_length = data.total; //get the number to load for (var i = 0; i < wp_length; i++) { var wp_id = "wp-" + i; var marker_id = i; //unique marker ID var waypoint_data = new Array(); //to store the waypoint data var order = marker_id; waypoint_data["order"] = order; //set the order as last waypoint_order[order] = marker_id; //Set the last waypoint as the one we just created. waypoint_data["latitude"] = data[wp_id].latitude; //store lat and long waypoint_data["longitude"] = data[wp_id].longitude; //keep zeroed until defined. waypoint_data["altitude"] = data[wp_id].altitude; waypoint_data["hover"] = data[wp_id].hover; waypoint_data["acceptance"] = data[wp_id].acceptance; waypoint_data["yaw"] = Math.round(data[wp_id].yaw * 57.2957795*1000)/ 1000; //convert back to degrees waypoint_data["viewpoint"] = data[wp_id].viewpoint; waypoint_data["passthrough"] = data[wp_id].passthrough; waypoint_data["launchpoint"] = data[wp_id].passthrough; waypoint_data["land"] = data[wp_id].passthrough; modifyMarker(waypoint_data, marker_id, true); }}, url: url }); } function updateFormData(marker_id) { var waypoint_data = new Array(); //store the waypoint data waypoint_data = all_waypoint_data[marker_id]; //get the existing data (in case the new data is undefined
-3-
//get the data from the form when the user clicks "save" waypoint_data["order"] = (document.getElementById('order').value == "") ? '0' : document. getElementById('order').value; //record the new waypoint position waypoint_data["altitude"] = (document.getElementById('altitude').value == "") ? '0' : document.getElementById('altitude').value; waypoint_data["hover"] = (document.getElementById('hover').value == "") ? '0' : document. getElementById('hover').value; waypoint_data["acceptance"] = (document.getElementById('acceptance').value == "") ? '0' : document.getElementById('acceptance').value; waypoint_data["yaw"] = (document.getElementById('yaw').value == "") ? '0' : document. getElementById('yaw').value; waypoint_data["viewpoint"] = (document.getElementById('viewpoint').value == "") ? '0' : document.getElementById('viewpoint').value; waypoint_data["passthrough"] = document.getElementById('passthrough').checked; waypoint_data["launchpoint"] = document.getElementById('launchpoint').checked; waypoint_data["land"] = document.getElementById('land').checked; modifyMarker(waypoint_data, marker_id, false); } function modifyMarker(waypoint_data_array, marker_id, newMarker) { all_waypoint_data[marker_id] = waypoint_data_array; //Set the global waypoint data variable to the data being passed if (newMarker) { var new_lat_long = new L.LatLng(waypoint_data_array["latitude"],waypoint_data_array[ "longitude"]) //the latitude and longitude of the marker markers[marker_id] = new L.Marker(new_lat_long); //new marker from the click event map.addLayer(markers[marker_id]); //add it to the map } //if there's more than one marker and the order has changed, *or* it's a new marker, reshuffle the order array var order_index = include(waypoint_order, marker_id); //find the marker's location if (markers.length > 1 && (waypoint_data_array.order !== order_index || newMarker) ) { waypoint_order.splice(order_index, 1); // remove the marker from the old position waypoint_order.splice(waypoint_data_array.order, 0, marker_id); //add the marker into the order array } updateAllMarkers() } function updateAllMarkers() { var update_order_popup_form = new Array(); //an array to hold popup form data var path_latlngs = new Array(); //iterate over each marker in order, updating the popup for it for (var i = 0; i < waypoint_order.length; i++) { //set the new order in the main waypoint array all_waypoint_data[waypoint_order[i]].order = i; //update the popup html with the new order (and anything else) update_order_popup_form[0] = "<form name='waypoint_settings' id='waypoint_settings_frm' action='#'>Waypoint Order: <input type='text' id='order'
-4-
size='4' value='" + all_waypoint_data[waypoint_order[i]].order + "'/><br />"; update_order_popup_form[1] = "Altitude: <input type='text' id='altitude' size='4' value='" + ( typeof all_waypoint_data[waypoint_order[i]].altitude !== "undefined" ? all_waypoint_data[waypoint_order[i]].altitude : "" ) + "'/><br />Hold Time: <input type='text' id='hover' size='4' value='" + ( typeof all_waypoint_data[waypoint_order[ i]].hover !== "undefined" ? all_waypoint_data[waypoint_order[i]].hover : "" ) + "' /><br />"; update_order_popup_form[2] = "Acceptance Radius: <input type='text' id='acceptance' size='4' value='" + ( typeof all_waypoint_data[waypoint_order[i]].acceptance !== "undefined" ? all_waypoint_data[waypoint_order[i]].acceptance : "" ) + "' /><br />Yaw Angle (Degrees): <input type='text' id='yaw' size='4' value='" + ( typeof all_waypoint_data[waypoint_order[i]].yaw !== "undefined" ? all_waypoint_data[ waypoint_order[i]].yaw : "" ) + "' /><br />"; update_order_popup_form[3] = "Camera Viewpoint: <input type='text' id='viewpoint' size='4' value='" + ( typeof all_waypoint_data[waypoint_order[i]].viewpoint !== "undefined" ? all_waypoint_data[waypoint_order[i]].viewpoint : "" ) + "' /><br />Pass Through: <input type='checkbox' id='passthrough' size='4' " + ( all_waypoint_data[waypoint_order[i]].passthrough == true ? "checked" : "" ) + " /><br />"; update_order_popup_form[4] = "Return to Launch Point: <input type='checkbox' id='launchpoint' size='4' " + ( all_waypoint_data[waypoint_order[i]].launchpoint == true ? "checked" : "" ) + " /><br />Land at Coordinates: <input type='checkbox' id='land' size='4' " + ( all_waypoint_data[waypoint_order[i]].land == true ? "checked" : "" ) + " /><br /></form>"; markers[waypoint_order[i]].bindPopup("Marker ID: " + waypoint_order[i] +"<p>" + update_order_popup_form.join("") + "</p><a href='javascript:updateFormData(" + waypoint_order[i] + ")'>Update</a> - <a href='javascript:removeMarker(" + waypoint_order[i] + ")'>Delete</a>").closePopup(); path_latlngs[i] = markers[waypoint_order[i]].getLatLng(); each marker } //draw the line if there's more than 1 marker. map.removeLayer(polyline); if (markers.length > 1) { polyline = new L.Polyline(path_latlngs, {color: 'red'}); map.addLayer(polyline); } //update the list of markers var wp_list_interface = new Array(); var list_contents = new Array(); for (var i = 0; i < waypoint_order.length; i++) { var wp = all_waypoint_data[waypoint_order[i]]; list_contents[0] = "Alt: " + wp.altitude + " m, "; list_contents[1] = (parseInt(wp.hover) > 0) ? ("Hover: " + wp.hover + " s, Yaw: " + wp.yaw + " deg, ") : (""); list_contents[2] = "Accept Radius: " + wp.acceptance + " m, "; list_contents[3] = "Viewpoint: " + wp.viewpoint + " "; list_contents[4] = (wp.passthrough == true) ? "+Pass Through " : ""; list_contents[5] = (wp.launchpoint == true) ? "+Return to Launch Point " : ""; list_contents[6] = (wp.land == true) ? "+Land " : ""; list_contents[7] = "<br />[<a href='javascript:openPopup("+waypoint_order[i]+ ")'>open</a>, <a href='javascript:removeMarker(" + waypoint_order[i] + ")'>delete</a>]";
-5-
//store the lat/long of
list_contents[8] = ""; wp_list_interface.push(list_contents.join("")); } clear_list("wp-list"); load_list("wp-list", wp_list_interface); } function openPopup(marker_id){ markers[marker_id].openPopup(); } function exportWaypointData() { //this function takes the all_waypoint_data array and posts it to the server. //The server then makes it available for Labview to read var url = "/map/post"; //URL to post to $.post( url, { "new_save" : 1 }); //before we post the first waypoint, tell the server to forget the old ones //loop over the waypoints in order for (var i = 0; i < waypoint_order.length; i++) { var waypoint_id = waypoint_order[i]; var waypoint_data = all_waypoint_data[waypoint_id]; //get the waypoint waypoint_data['yaw'] = waypoint_data['yaw'] * 0.0174532925; //convert to radians before sending var data = {} //initialise empty array for sending for (var key in waypoint_data) { data[key] = waypoint_data[key]; //put each key into the data array } $.post( url, data); //send to the server (add acknowledge function?) } } //helper functions //get the size of an array of arrays Object.size = function(obj) { var size = 0, key; for (key in obj) { if (obj.hasOwnProperty(key)) size++; } return size; }; //find the location of the object in the array function include(arr,obj) { for (var i = 0; i < arr.length; i++) { if (arr[i] == obj) return i; } } function add_li(list, text) { var list = document.getElementById(list); var li = document.createElement("li"); li.innerHTML = text; list.appendChild(li); } function load_list(list, list_array) { for (var i = 0; i < list_array.length; i++) { add_li (list, list_array[i]);
-6-
} } function clear_list (list) { var list = document.getElementById(list); while( list.hasChildNodes() ) { list.removeChild( list.lastChild ); } }
-7-
N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\Software\Waypoint Mapping\MapServer\map.tpl
24 April 2012 15:34
<!DOCTYPE html>  <html> <head> <title>Waypoint Selector - Leeds University Blimp</title> <link rel="stylesheet" href="http://code.leafletjs.com/leaflet-0.3.1/leaflet.css" />  <script src="/static/jquery-1.7.2.min.js"></script>  <style type="text/css"> html { overflow:hidden; } body { margin: 0; padding: 0; } #left { width: 600px; position: relative; float: left; } #right { margin-left: 5px; width: 300px; position: relative; float: left; } #right ol { font-size: 70%; } #frame { } </style>
</head> <body> <script src="http://code.leafletjs.com/leaflet-0.3.1/leaflet.js"></script> <div id="frame"> <div id="left"> <div id="map" style="height: 600px"></div> </div> </div> <div id="right"> <p><strong>List of Waypoints</strong></p> <p><a href='javascript:exportWaypointData()'>Save to Labview</a> - <a href=
-1-
N:\Faculty-of-Engineering\Mech-Eng\Learning+Teaching\UG-Projects-11-12\Level 4\airship_platform\Software\Waypoint Mapping\MapServer\map.tpl
24 April 2012 15:34
'javascript:clearAllWaypoints()'>Clear All</a> - <a href='javascript:loadPreviousWaypoints()' >Load Previous</a></p> <ol id="wp-list"></ol> </div> <script src='/static/MapConfiguration.js'></script> </body> </html>
-2-

A LabVIEW Based Autonomous Airship Flight Controller

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

A LabVIEW Based Autonomous Airship Flight Controller

Diunggah oleh

Hak Cipta:

Format Tersedia

MECH5030M Individual Project Report Team 23 Leo Rampen - 200406830 Supervisor: Dr. R. W. Hewson Examiner: Dr. H. M.

26th April 2012

Design of an Autonomous Airship Platform

MECH5030M Individual Project Report Design of an Autonomous Airship Observation Platform

April 26, 2012

April 26, 2012

April 26, 2012

April 26, 2012 26 26 26 27 29 30

April 26, 2012

April 26, 2012

April 26, 2012

April 26, 2012

Aims and Objectives

Control, Navigation and Communication Software

April 26, 2012

Electronics and Electrical Systems

April 26, 2012

Context and Literature Review

Flight Control Systems

April 26, 2012

April 26, 2012

Control Algorithms and Processes

April 26, 2012

April 26, 2012

Navigation and Autonomy

April 26, 2012

Equipment and Software Used

Lab Equipment Used

April 26, 2012

(a) An Arduino microcontroller development board.

(b) Sensors tested in a breadboard.

Hardware Used in Final Aircraft Design

April 26, 2012

(a) The propulsion gondola and a motor.

(b) The main gondola with most of the electronics mounted

April 26, 2012

Development of a Flight Control System

April 26, 2012

Orientation and Velocity Control Loops

April 26, 2012

Testing and Simulation

April 26, 2012

Heading and Altitude Control

April 26, 2012

(a) A stable but poorly damped response

(b) A better response in a crosswind near the aircraft velocity

Figure 4.2.2: Undesirable controller responses.

April 26, 2012

Communications Protocol Design

April 26, 2012

Figure 4.3.1: The TCP communication component structure.

Low Level Protocol

April 26, 2012

Implemented Message Protocol

April 26, 2012

Int 20 21 22 23 24, 25, 27, 28 26

April 26, 2012

Sensing and Actuation

Communicating with Sensors

April 26, 2012

Table 5.1.1: Inertial sensor resolutions and limits.

April 26, 2012