Introduction - teamquadrotor.files.wordpress.com · Web viewThe vehicle must also be able to...

Department of Electrical and Computer Engineering

Schulich School of Engineering

University of Calgary

Fall 2012

4th Year Project Report #2

Preliminary Design Document

Group # 23

Team UFO

Quadrotor

Group Members:

Mila GorobetsThomas BeulahMichael HimmelfarbPatrick Beasley

Sponsor’s Name:

Microlynx Systems Ltd

Dec 3, 2012

Table of Contents1. Introduction..............................................................................................................................3

2. System Level Architecture.......................................................................................................4

2.1 Graphical User Interface (GUI).............................................................................................4

2.2 Flight Control System............................................................................................................4

2.3 Bluetooth Wireless Communication......................................................................................5

2.4 Obstacle Avoidance Control..................................................................................................5

3. Preliminary Design...................................................................................................................5

3.1 Top Level...............................................................................................................................5

Physical Components:..............................................................................................................6

3.2 User Interface.........................................................................................................................7

3.3 Wireless Communication Link............................................................................................13

3.4 Microcontroller Lookup Table.............................................................................................14

Definition of Commands:.......................................................................................................14

Command Table.....................................................................................................................15

3.5 Avoidance Control System..................................................................................................15

Sensor Functionality...............................................................................................................16

Sensor Implementation...........................................................................................................16

Obstacle Avoidance................................................................................................................18

3.6 Flight Control System..........................................................................................................18

Feedback.................................................................................................................................19

Control Method......................................................................................................................19

Flight Control System Diagram.............................................................................................20

4. Prototypes...............................................................................................................................21

4.1 User Interface.......................................................................................................................21

4.2 Flight Control System..........................................................................................................22

5. Bill of Materials......................................................................................................................24

6. Appendix A............................................................................................................................25

7. Appendix B.............................................................................................................................26

8. Glossary..................................................................................................................................26

9. References..............................................................................................................................28

1. Introduction

The project to be carried out involves design and testing of an autonomously stable, but user

controllable, quadrotor. A quadrotor (also known as a quadcopter or helicopter) is a multicopter

flying vehicle, whose lift is generated by four equally spaced rotors.

The main goal of this project is to produce a portable, battery-operated quadrotor with a diameter

of approximately 30 cm. This allows for maneuverability and the ability to adapt to various

environments and missions, while also preserving the capacity of the quadrotor to carry sensors.

The designed quadrotor must have an operator-vehicle range of at least 10 meters, and

guaranteed flight time of at least 2 minutes. The vehicle must be able to hover in a stable

configuration (staying within 15 cm of a specified point in space), but upon user command move

at an appropriate rate to a new position in space. Autonomous ability to hover will allow our

project to maintain stability even if the communication link between the operator and the vehicle

is lost. Motion upon command will provide flexibility for possible future uses (for example,

military surveillance, mining operations, search and rescue). The vehicle must also be able to

detect and autonomously avoid obstacles. User commands will be delivered using a graphical

user interface (GUI), with a maximum delay of 500 ms. The GUI will also aim to provide

valuable system information to the operator, such as motor speed, location of nearby obstacles,

and important points in space.

This project will create a compact quadrotor capable of displaying several electrical engineering

design qualities – control systems, wireless communication, embedded systems, sensory systems,

and user interface design and execution. Final uses of this project will involve trade-show

demonstrations by the sponsor, as well as the possibility of use for military surveillance, search

and rescue and exploration purpose. The design process itself will have the opportunity to

influence the on-going research in the area of robotics and unmanned aerial vehicles.

The following report describes the preliminary designs carried out for the key sections of this

project. We used the top-down design methodology, and thus the project is split up into four

distinct areas: obstacle avoidance implementation, control system, communication link and the

GUI.

2. System Level ArchitectureThe diagram describing the interaction of our system’s components is shown in Figure 1. Main

parts of the system architecture are further described in the sections below.

Figure 1. Top Level System Diagram

2.1 Graphical User Interface (GUI)

The GUI is an interface that allows the user to control the quadrotor. From the GUI, the user can

control the direction the quadrotor moves, observe graphs of the motor speeds with time, retrace

paths taken, and examine the quadrotor in relative 3D space as a rendering. The GUI

communicates with the microcontroller through the Bluetooth wireless link. The GUI sends and

receives commands, which are mapped into a command table shown in Table 1.

2.2 Flight Control System

The quadrotor must be able to hover. This requires motors, accelerometers, a gyroscope, and a

microcontroller in order to remain in a constant position. The motors will provide lift, while the

accelerometer and the gyroscope provide information to the microcontroller which processes the

information and updates motor speed.

2.3 Bluetooth Wireless Communication

The communication between the user and the quadrotor will be established with a Bluetooth

module and a computer. This module will be connected to the microcontroller using a USART

(Universal Serial Asynchronous Receiver/Transmitter) serial interface. Software on the

microcontroller side will receive information from the user and adapt motor speeds to implement

the movement desired by the user. All data transferred through the Bluetooth communication

channel will need to be converted into commands that the computer program can understand. To

do this we will implement a command table to allow fluid communication of commands. There

will be commands for motor speed, proximity detection, movement direction, and others.

2.4 Obstacle Avoidance Control

Ultrasonic sensors will be used to determine the proximity of objects near the quadrotor. These

sensors will communicate with the microcontroller through an I2C (Inter-Integrated Circuit)

serial interface. Their information will be used by the microcontroller to prevent the quadrotor

from colliding with obstacles in the environment. In order for the avoidance control to be

autonomous, it must communicate directly with the flight control system to override the user

flight commands and prevent collision.

3. Preliminary Design

3.1 Top Level

The chosen design method for this project is Top-Down Design. From the system level

architecture, the design of the semi-autonomous quadrotor consists of four modules which

communicate with each other. These modules are the user interface, wireless communication

link, avoidance control system, and the flight control system. The arrows indicate how different

types of data are passed between each of the modules. Each of these modules will be described in

detail in this report.

The user interface gives feedback to the user about the quadrotor’s status, and provides a way for

the user to input desired commands. The avoidance control module and the flight control

module are onboard the quadrotor. Therefore all data that flows between the user interface and

the onboard systems must be transferred by the wireless communication link. A microcontroller

lookup table deciphers binary commands from the wireless link. The user interface sends motion

commands that are specified by the user to the flight control system. The flight control receives

these commands and executes them by controlling the quadrotor’s motor speeds. It returns three

axis acceleration values and the four motor speeds to the user interface. The avoidance system

detects obstacles and sends information about them back to the user interface. It then sends a

command to the flight control system that will make the quadrotor move away from the obstacle

if it is within 50 cm.

Physical Components: Each module requires physical hardware which is shown in the physical component diagram in

Figure 2.

Figure 2. Physical Component Top Level Diagram

The actual quadrotor frame is not being developed in this project – rather, the components are purchased, and the electronic components are what will be designed. The components for the

quadrotor were a part of a kit, which included the frame, motors, a battery, propellers and motor speed controllers. An Atmel microcontroller development board was also purchased separately.

The chosen kit features a lightweight, affordable frame, small motors, propellers of proper size, motor speed controllers suitable for the motors chosen, and a LiPo battery to power the motors.

The microcontroller board was chosen because of the abundance of input/output pins and communication ports. The maximum operating frequency of the microcontroller is 66MHz, which allows for many mathematical operations per second. This is important in our application due to the control system implementation, which requires multiple fast calculations in order to adjust the motor speeds properly.

The microcontroller board will be mounted at the center of the assembled frame.

3.2 User Interface

The purpose of the graphical user interface (GUI) in this project is to provide the quadrotor

operator with means of sending commands (via a computer), visualizing the surrounding

environment, and monitoring key components of the system. The proposed solution is to be

designed using managed Visual C++ (through Visual Studio 2010) and should be able to

communicate with the quadrotor using Bluetooth via the USB port.

The implementation will use four classes, with the applications of each described in the “Main

Features” section. The general design diagram of the GUI and its interfaces is shown in Figure 3.

Figure 3. Graphical user interface inputs and outputs

Main Features

Main graphical user interface window: this is where the user inputs will be gathered, and

outputs displayed. It will contain all features described below.

Implementation:

The form will be occupying its own class (“Form”), and designed using Visual Studio’s form

elements. The window size will be 1080x1920 pixels, but with an ability to decrease it if

needed for lower resolution screens.

3D model of the quadrotor in the surrounding environment: the user will be able to change

the view and use the rendered graphics (obstacles and waypoints) to plan further actions.

Implementation:

This is to be done using an embedded OpenGL frame in a Windows Form (this is created in

Visual C++/CLI). OpenGL is chosen because of its relative ease of implementation in

managed C++, and prior knowledge of the conventions and syntax.

The 3D model itself will be developed in Autodesk Maya – provided for free to University of

Calgary students. This software allows for an extensive development of the model using

complex shapes and textures. The final model will have color-coded propellers to

differentiate between the four available (these colors will also correspond to those on the

motor speed plots – this is further explained below).

The OpenGL frame will be contained in its own class (“OpenGL”), and during refreshing it

will run on its own thread to permit other processes to continue uninterrupted. The OpenGL

panel will be refreshed every 10 ms; this time is chosen based on prior testing – it allows for

smooth accurate rendering (not noticeable to the human eye).

Ability to add waypoints: the user will have the option to leave markers at certain locations in

space to indicate points of interest.

Implementation:

In this case, the implementation will be shared between the OpenGL and the Form classes.

The command to add a waypoint will come from the Form class, the information

(coordinates) of the position will be stored in an array, and a spherical marker will be

rendered in OpenGL. The marker will indicate the marker’s coordinates and the number.

The program will by default leave a “Home” marker to represent the quadrotor’s origin. A

button will be available on the main form to return to “Home” position at any time using the

safest path available. A separate button will allow the user to travel to a selected waypoint

(can be selected in the OpenGL panel).

Form updates will be handled on a separate thread in order to permit the communication link

to function without interruption.

Maintain a communication link with the quadrotor. This software feature will send motion

commands to the quadrotor and receive accelerometer and motor speed data back. The time

delay between when the user sends a command and when the quadrotor reacts must be at

most 500 ms.

Implementation:

The communication link will occupy its own class (“Communication”) and will reside on the

main thread. All of the other classes will branch from this thread on start up. The link will have

direct contact with the USB port to which the Bluetooth transceiver module is connected.

Received motor data will be sent to the Form class for updating the plots. The accelerometer data

will be communicated with the Calculations class in order to calculate current speed and

position. The Communication class will also be responsible for checking and echoing link checks

with the quadrotor periodically.

The following diagrams describe various required actions, and information flow within the GUI.

For convenience, the following color scheme is used:

COMMUNICATION CLASS

COMMUNICATION CLASS OPENGL CLASSOPENGL CLASS FORM CLASSFORM CLASS CALCULATIONS

CLASSCALCULATIONS

CLASS

Figure 4. Colour scheme

Beginning of Flight

Quadrotor starts up Establish communication link

Establish communication link

Update communication

light in UI

Figure 5. Initialization of the communication link

In the instance illustrated in Figure 5, the software is being initialized to interface with the

quadrotor prior to flight. An echo request will be received from the quadrotor, and this will

establish the communication link. This path will also be taken in the event of restoration of a lost

communication link.

Sending data to the quadrotor

User presses keyConvert user view

to normalized directions

Send commands to quadrotor


Wait for response with accelerometer

and speed data


and speed data

User releases key Send command to stop

Send command to stop

Figure 6. Sending user input to the quadrotor

When a user is entering data, as shown in Figure 6, motion/direction information will be

constantly sent to the quadrotor until the pressed keys are released. Since the user is able to rotate

the environment in 3D space, the desired directions will need to be converted to a standardized

view. For example, if the user rotates the view by 90 degrees and desires for the quadrotor to

move left (from the operator’s point of view), the normalized motion will either be forward or

back depending on whether the rotation was clockwise or counterclockwise.

In certain cases, the user might desire to travel to a previously set waypoint (or the “Home”

waypoint). This event chain is shown in Figure 7. The chain is similar to that for regular

commands, except for the fact that the Calculation class will calculate an entire set of directions

to reach the final destination and send them out in proper order.

User requests travel to waypoint

Calculate directions from current position to waypoint




and speed data


and speed data

Figure 7. Travel to pre-set waypoint event chain

Receiving data from quadrotor

The GUI requires feedback from the quadrotor in the form of accelerometer and motor speed

data. The motor data will go towards updating the plots on the GUI, and the accelerometer data

is used to keep track of motion and position.

Accelerometer data arrives

Calculate current position and

orientation in space

Calculate current position and

orientation in space

Update OpenGL struct

Update OpenGL model (10 ms

intervals)

Speed data arrives Update motor plots

Figure 8. Receiving accelerometer and motor speed data

In order to maintain the rendering of the surrounding environment, the quadrotor will also send

obstacle information to the GUI. No request for this information is generated by the GUI – the

application will simply wait for a message with information to arrive. This is done because the

quadrotor system’s priority will be in the communication and control systems, and the obstacle

detection system might not have time to relay all of the information at every time interval.

Ultrasonic sensor data arrives

Calculate new rendering of surroundings

Update the surroundings struct

Update OpenGL model (10 ms

intervals)

Figure 9. Receiving ultrasonic data

Echo requests

Periodically, the GUI will receive an echo request from the communication system on board of

the quadrotor. In this case, there will be a need to process the echo, and to answer it in a set

period of time (otherwise the communication link will be deemed broken, and emergency

landing procedures will be initiated).

Echo request received

Return echo to quadrotor

Return echo to quadrotor

Figure 10. Handling Echo requests

User Input

The user input has been described above for when directions need to be sent out. The controller

might also want to add waypoints at certain locations, and this event chain is demonstrated

below. This information is never relayed to the quadrotor, instead it is stored until user requests

travel to set waypoint.

Figure 11. Handling user input

A summary of the overall GUI design (a sketch of the current concept) can be found in Appendix

A.

3.3 Wireless Communication Link

Figure 12. Bluetooth High Level Design

The Bluetooth communication link connects the quadrotor and the user’s computer through a

wireless channel. The Atmel microcontroller is connected to the Bluetooth module through a

USART connection which has 1 power pin (3.3V), 1 common ground, Tx (Transmitter) line, and

Rx (Receiver) line. On the computer side, the Bluetooth USB dongle connects through a USB

2.0 port. The Bluetooth dongle requires drivers to be installed on the computer which emulates a

serial communication (COM) port. Data received by the Bluetooth dongle will be sent to this

emulated COM port, where it can be accessed by the GUI.

Communication between the quadrotor and the computer is fully duplex. This means that data

can be sent from the quadrotor to the computer and from the computer to the quadrotor

simultaneously. The user will specify commands that need to be sent to the quadrotor, such as

moving left, right, up, down, forward or backwards. However, the GUI will also require

information to update the relative position of the 3D rendering and real time graphs of motor

speed. In this case, the data will be sent from the microcontroller back to the GUI.

3.4 Microcontroller Lookup Table

The microcontroller will be programmed to receive and transmit data with binary commands

from a command table. Each command will be given a binary instruction code, but currently the

microcontroller look-up table describes how these commands will be used.

Definition of Commands: Get Motor #X speed: The microcontroller sends an unsigned integer through the Bluetooth

module which represents motor speed in percent.

Go X: The microcontroller receives an unsigned integer that tells the quadrotor to move in a

certain direction.

Get Acceleration: The microcontroller sends seven unsigned integers through the Bluetooth

module. The first unsigned integer will represent acceleration in the X direction, the second

represents acceleration in the Y direction, and the third represents acceleration in the Z direction.

The last 4 unsigned integers represent an integer number of 1us intervals that have passed since

the quadrotor started. Keeping track of relative time is important for updating the relative

position of the quadrotor in the GUI.

Get Proximity: The microcontroller sends an unsigned integer through the Bluetooth module,

which represents the distance from the center of the quadrotor to a detected obstacle (in cm).

Get Orientation: The microcontroller sends a floating point number through the Bluetooth

module which represents the quadrotor orientation (in degrees).

Get Time Overflow: The microcontroller sends an unsigned integer through the Bluetooth

module when the relative time data overflows and needs to be compensated.

Get COM confirmation: The microcontroller sends an unsigned integer through the Bluetooth

module which requests confirmation that the wireless link has been established.

COM confirmation: The microcontroller receives a confirmation from the GUI that data can be

sent through the wireless Bluetooth communication link.

Command Table Table 1. Bluetooth Command Table

Microcontroller

Commands Description Send Data Receive Data Data format

Get Motor speed #1 Sends motor speed for graphical application X 1 Byte unsigned integer




Go Left Receives direction X --

Go Right Receives direction X --

Go Forward Receives direction X --

Go Back Receives direction X --

Go Up Receives direction X --

Go Down Receives direction X --

Stop Receives Stop X --

Get Acceleration Sends: Acceleration X Y Z data, Current relative time data X 1 Byte unsigned integer

1 Byte unsigned integer


4 Bytes unsigned integer

Get Proximity Sends Proximity data: Left ,Right, Front, Back X 1 Byte unsigned integer




Get Orientation Sends Orientation in degrees X 1 byte scientific

Get Time Overflow Send if Time counter overflows X 1 Byte unsigned integer

Get COM confirmation Send Confirmation that communication is established X 1 Byte

COM confirmation Receive request to confirm communication is established X --

3.5 Avoidance Control System

In order to build an obstacle avoidance system for the quadrotor, it is necessary to have some

way of sensing the surrounding environment in order to detect obstacles. After careful

consideration of the sensors available, the Maxbotix LV-EZ1 ultrasonic sensor was selected for

this project. The ultrasonic sensor was chosen as it provides accurate proximity measurements, is

lightweight, has low power consumption, can detect translucent objects, is reasonably

inexpensive and is easy to use and implement.

Sensor Functionality The ultrasonic sensor transmits a sound wave and evaluates the echo that returns back to the

sensor. The distance to the object can be determined in several ways, but for this project the

voltage of the echo that the sensor receives will be used to determine the distance to the obstacle.

This distance measurement is quite accurate assuming that the angle of reflection from the object

is not great [1]. As the distance increases it is necessary for the object to be almost perpendicular

to the sensor in order for the echo to be received.

Sensor Implementation There will be four sensors used for detecting objects in all directions and a fifth sensor will be

pointed down for an accurate altitude measurement. The sensors in this configuration should

provide sufficient coverage for obstacle detection as shown in Figure 13.

Figure 13. Ultrasonic sensor detection spectrum at 35cm.

The four sensors directed outwards from the quadrotor will be coordinated such that the

quadrotor will attempt to maneuver away from any obstacle that comes within a 50 cm radius of

the quadrotor. Depending on which sensors detect an obstacle, the obstacle avoidance system

will have pre-determined commands that will be sent to the control system to direct the

movement. The diagram showing the layout of the ultrasonic sensors and their orientation is

shown in Figure 14.

Figure 14. Diagram of directional sensor layout showing there numbering and orientation with respect to the cardinal coordinate system.

An overview of the pre-determined directions the quadrotor will move in when the sensors detect

an object is summarized in Table 2. As the quadrotor will not always necessarily be pointing

north, these reference directions are simply used as a starting reference and will be associated

with certain commands to move the quadrotor in the appropriate direction as if it was always

pointing north. Therefore it will not be a factor if the quadrotor rotates, it will always move in

such a way as to avoid the obstacle. The sensor numbers shown in Table 2 are associated with

the sensor labeling shown in Figure 14 with the cardinal reference system.

Table 2. List showing the pre-determined direction the quadrotor will fly given cardinal reference system

Sensor(s) with Detection Direction Moved

1 South2 East

3 North4 West

1, 2 Southeast1, 2, 3 East2, 3 Northeast

2, 3, 4 North3, 4 Northwest

1, 3, 4 West1, 4 Southwest

1, 2, 4 South1, 3 West or East2, 4 North or South

1, 2, 3, 4 Land

Obstacle Avoidance The obstacle avoidance system input and output diagram is shown in Figure 15. The data

provided by the sensors is analyzed to determine the distance to the nearest obstacle in all

directions. The distance is calculated based on the voltage of the echo that is returned to the

sensor from the object. This distance will then be sent to the GUI to provide the user with

updated information on the surrounding environment. If the distance is less than 50cm, the pre-

determined command associated with the sensor that detected the obstacle needs to be sent to

override the control system to maneuver away from the obstacle.

Figure 15. Obstacle avoidance system inputs and outputs diagram.

3.6 Flight Control SystemThe purpose of the flight control system is to realize the desired values of the roll angle, pitch

angle, yaw angle and vertical velocity of the quadrotor. These desired values are the flight

control system inputs and will come from the microcontroller lookup table. This lookup table

will have predefined control inputs for every type of command that is sent from the GUI over the

wireless communication link. Diagrams defining the roll, pitch and yaw angles can be found in

Appendix B. The control system will realize these inputs by sending appropriate outputs to the

motor speed controllers. Another purpose of the control system is to provide acceleration data for

position tracking and quadrotor orientation data. The acceleration data will be sent back over the

wireless communication link to the user interface.

Feedback For the control system to fulfill its purpose, it must have a way of getting feedback about the

current quadrotor orientation and accelerations. This data will come from an inertial

measurement unit (IMU). This unit must have an onboard gyroscope, accelerometer, and

magnetometer. The accelerometer is needed to provide acceleration data for position tracking.

The quadrotor’s roll, pitch, and yaw angles can also be calculated from the acceleration vectors,

however these are prone to error from vibrations in the quadrotor frame. Therefore, the

gyroscope is used to measure the angles as well. However, the gyroscope suffers from drift error

(when the gyroscope does not return to the original zero point), so the angles calculated from the

accelerometer data can be averaged with the angles given from the gyroscope data to provide the

most accurate measurements. The magnetometer is similar to a compass; it will provide

information on the quadrotor’s absolute orientation. This will allow the control system to

determine which the way the quadrotor should move when the user is directing it using an

external coordinate system as a reference.

Control Method Inside the control system, a control method must be chosen which will realize the given control

inputs using the provided feedback. There are many different types of control methods that could

be implemented on a quadrotor. As the quadrotor is an under-actuated, non-linear system, non-

linear control methods can provide the most accurate control [2]. Examples of these methods are

non-linear H-infinity control and back-stepping control. However, these methods are very

complex and difficult to implement. Linear control methods include LQR controllers and PD

(proportional-derivative) controllers. For this project, the PD control method was chosen because

it achieves good performance while being very simple to implement. It also uses less

computational power in the microcontroller. Since the main goal of the project is to develop a

semi-autonomous quadrotor and not a more accurate flight control system, the PD controller will

suffice.

The PD control method requires the error between the feedback from the IMU and desired

control inputs. It calculates the motor speeds based on the error functions and the derivatives of

the error functions. The block diagram of a PD controller can be seen in Figure 16.

Figure 16. PD Controller Diagram

Flight Control System Diagram

The entire flight control system can now be represented by the block diagram shown in Figure

17.

Figure 17. Flight Control System Block Diagram

4. Prototypes

4.1 User Interface

Work has been carried out on the 3D model for the graphical user interface OpenGL panel. This 3D model is a representation of the actual hardware, and serves the purpose of showing the operator the orientation and position of the vehicle in space.

The model was created in Autodesk Maya 2012 using a variety of available tools. The simple shapes were made using Boolean manipulations on regular shapes – subtracting one shape from another, merging shapes, and so on. The propellers were made using bend manipulations of a flat plane made to match the actual propeller in shape.

The current state of the 3D model is shown in Figure 18. The model will be converted to the format that can be read and imported into the OpenGL frame. The propellers will be rendered in different colors to match with those used for plots in the GUI.

Figure 18: User Interface 3D Model Prototype

4.2 Flight Control SystemTo validate and verify that the flight control system can achieve the desired control inputs, a

simulation was made in Simulink. This required some detailed design steps which will not be

explained in depth in this high level design report, but the model can be seen in the Simulink

block diagram in Figure 19.

Figure 19. Simulink Prototype of Flight Control System

The simulation shows that with the proper control gains, this control scheme is stable and can

achieve the desired inputs. Example outputs of the simulation are shown in Figure 20 for control

inputs: roll angle=0, pitch angle=0.5 radians, yaw angle=0, vertical velocity=0.

Figure 20. Simulunk Simulation Outputs

5. Bill of MaterialsTable 3. Bill of Materials

Part # Description ManufacturerSupplier Quantity Unit Price Cost

MB1010Maxbotix LV-MaxSonar-EZ1 Sonar Rangefinder Maxbotix Pololu 5 $24.95 $124.75

MinIMU-9 v2

MinIMU-9 v2 Gyro, Accelerometer, and Compass IMU Pololu Pololu 1 $49.95 $49.95

T1811-2900/8142Turnigy 1811 brushless Outrunner 2900kv Turnigy HobbyKing 5 $9.72 $48.60

TR-6A/4318Turnigy 6A electronic speed controller Turnigy HobbyKing 5 $6.56 $32.80

9332000001/22607Turnigy Integrated PCB Micro-Quad (KIT) Turnigy HobbyKing 1 $14.99 $14.99

9332000002/227535030 Propellers (Black) - 3xCW and 3xCCW HobbyKing 2 $3.45 $6.90

Turnigy-3S/7637Turnigy balancer & Charger 2S-3S Turnigy HobbyKing 1 $4.49 $4.49

N850.2S.25Turnigy 2S 35-40C 850mAh nanotech LiPo Turnigy HobbyKing 1 $5.99 $5.99

AT32UC3A3-XPLD-ND

AT32UC3A3-XPLD microprocessor development board Atmel digikey 2 $31.98 $63.96Good Quality 3.3VDC 30ft Wireless Bluetooth RF Transceiver Module Card RS232 TTL Ebay 2 $6.09 $12.18Mini USB 2.0 Bluetooth Adapter Dongle for PC Laptop Ebay 2 $1.60 $3.20

TOTAL $367.81

6. Appendix A

Figure 21. Current state of the GUI design

7. Appendix B

Figure 22. Roll, pitch and yaw angle diagrams

8. GlossaryAccelerometer: A device used to determine acceleration in the X, Y, Z directions.

Bluetooth – Wireless communication standard for short-range data transmission

Bluetooth USB dongle: A USB device that connects to a computer and allows wireless communication through an emulated serial communication port.

COM: Short form of “communication”.

GUI – Graphical User Interface: An interface that allows users to interact with the device (send

commands) using images, rather than text commands (such as those used in the Command

Prompt).

Gyroscope: A mechanical device that determines angular position in 3D space using angular moment.

I 2 C - Inter-Integrated Circuit: A protocol used for wired serial communication between a host device and a slave device. This interface is useful for hooking sensors up in a slave configuration.

IMU - Inertial Measurement Unit: An onboard unit that uses accelerometers, gyroscopes and magnetometers to measure the orientation and acceleration of a moving vehicle.

LiPo: Lithium polymer battery: rechargeable batteries.

LQR - Linear Quadratic Regulator control: A linear control method based on optimizing a certain quantity.

OpenGL – Open Graphics Library: Multiplatform graphics application programming interface. It

allows for visualization of 3D spaces in virtual reality applications, visualization, flight

simulation and video games.

PD - Proportional Derivative control: A linear control method with control outputs based on the error between the desired control inputs and actual feedback and the derivative of this error.

Receiver line: The line from the USART that received binary data.

Transmitter line: The line from the USART that transmits binary data.

Ultrasonic sensor: A sensor that sends an ultrasonic sound wave and waits for the reflected wave to return in order to measure proximity.

USART - Universal Serial Asynchronous Receiver/Transmitter: A protocol used for wired serial communication between two devices.

USB – Universal Serial Bus: A type of connection (both physical and logical) between an

external electronic device and a computer. This can be used to exchange data and power the

external device.

3D – Three dimensional space: Geometric representation of an object using a three-parameter

model of the physical universe. The parameters are typically either [x, y, z] (Cartesian space) or

[width, length, height].

9. References

[1] Y. K. Johann Borenstein, "Obstacle Avoidance with Ultrasonic Sensors," IEEE Journal of Robotics and Automation Vol 4, pp. 213-218, 1988.

[2] G. Raffo, "An Integral Predictive/Nonlinear H-infinity control Structure for Quadrotor," Universidad de Sevilla, Sevilla, 2010.

Introduction - teamquadrotor.files.wordpress.com · Web viewThe vehicle must also be able to...

Documents

Transcript of Introduction - teamquadrotor.files.wordpress.com · Web viewThe vehicle must also be able to...