Documente Academic
Documente Profesional
Documente Cultură
Report #1
Team Information
Team number
23
Team name
Team UFO
Team leader
Mila Gorobets
2nd Member
Michael Himmelfarb
3rd Member
Thomas Beulah
4th Member
Patrick Beasley
Customer Information
Customer
Website
http://www.microlynxsystems.com/
Contact person
Bill Durtler
billd@microlynxsystems.com
107 - 1925 - 18 Ave NE
CALGARY, Alberta
T2E 7T8
Contact address
No
No
Table of Contents
1. Introduction ...........................................................................................................................................................4
1.1 Summary of the project .............................................................................................................................4
1.2 Motivations .....................................................................................................................................................4
1.3 Economical aspects......................................................................................................................................5
2. Product Design Specifications ........................................................................................................................6
2.1 Expected performances .............................................................................................................................6
2.2 Specifications related to performance .................................................................................................6
3. Low Level Design .................................................................................................................................................6
3.1 Microcontroller .............................................................................................................................................6
3.2 Graphical User Interface ............................................................................................................................7
3.2.1 Main Thread (Thread 1) ...................................................................................................................8
3.2.2 Sending/Transmitting Thread (Thread 2) ............................................................................ 11
3.2.3 Receiving Thread (Thread 3) ...................................................................................................... 12
3.2.4 GUI Design and Functions ............................................................................................................ 13
3.3 Wireless Communication Link ............................................................................................................. 14
3.4 Flight Control System .............................................................................................................................. 16
3.4.1 Overview.............................................................................................................................................. 16
3.4.2 PID Controller .................................................................................................................................... 18
3.4.3 Implementation ................................................................................................................................ 20
3.5 Avoidance Control System ..................................................................................................................... 20
3.5.1 Overview.............................................................................................................................................. 20
3.5.2 Implementation ................................................................................................................................ 20
4. Test Plan ............................................................................................................................................................... 21
4.1 Graphical User Interface ......................................................................................................................... 21
4.1.1 Testing successful transmission of commands.................................................................... 21
4.2 Wireless Communication Link ............................................................................................................. 22
4.2.1 Bluetooth Transmission Distance ............................................................................................. 22
4.2.2 Successful Command Transmission Rate............................................................................... 23
4.3 Flight Control System .............................................................................................................................. 23
4.3.1 Roll Stability Test ............................................................................................................................. 23
4.3.2 Pitch Stability Test ........................................................................................................................... 24
4.3.3 Yaw Stability Test............................................................................................................................. 24
2
1. Introduction
1.1 Summary of the project
The project to be carried out involves design and testing of an autonomously stable, but
controllable quadcopter. A quadcopter (also known as a quadrotor helicopter, or a
quadrotor) is a multicopter flying vehicle, whose lift is generated by four equally spaced
rotors. Many implementations of quadrotor systems exist; however, the vast majority of
them are remote-controlled (RC) hobbyist projects. The sizes of these systems also vary
greatly from palm-sized to large ones (built in an attempt to be able to lift humans [1]).
The main goal of this project is to produce a portable 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. Greater size essentially allows us to use larger propellers and higher-torque
motors to generate greater lift.
The quadrotor must be battery operated, removing the necessity for cables and tethering of
the vehicle to a certain location. However, for our purposes the quadrotor will be tethered
during all testing to avoid damage. Battery operation allows for our project to be usable in
other applications upon development, where the distance between the operator and the
quadrotor is greater than it is reasonable to have wires for. For our project, however, the
operator-quadrotor range is limited to 5 meters.
The vehicle must be able to hover in a stable configuration (staying within 50 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).
Another goal is to be able to detect and avoid obstacles. This feature is not often
implemented on commercially available hobby RC aircraft due to the assumption that the
controller will provide adequate directions to the vehicle, and the considerably simpler
design. Adding this ability to our project will increase its versatility in confined
environments.
Finally, on the side of the operator, our goal is to develop a real-time graphical user
interface (GUI) to serve as a controller. The interface should be able to send proper
commands to the quadrotor, display critical data (such as position and motor speed), as
well as allow for path planning.
1.2 Motivations
The purpose of this project is to develop 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. The final
product is to be used by Microlynx Systems Ltd for trade-show purposes.
The benefits and motivations for the project fall into several categories. First of all, the final
product will provide our sponsor with an adequate demo model to display to potential
customers, in order to present some of the possibilities available in systems design.
Secondly, the area of quadrotor design is fairly new and is developing rapidly; thus, our
project will have the chance to benefit future designs and related research. The addition of
sensory networks (for detecting obstacles) is not common, and investigating control
techniques in this area is important. Developing a communication link that does not rely on
the conventional remote control also provides additional support for other projects in this
area.
The final product will also suit a variety of applications, as described in the previous section.
Small controllable stable aerial vehicles are capable of supplementing military operations,
search and rescue, crop spraying, power line inspections and investigations of confined
spaces, such as caves or collapsed buildings. Developing an affordable vehicle would allow
us to reach into several industries and improve existing technologies.
Lastly, this project is a great opportunity for us to develop design and project management
skills. We are focusing on many areas, which will allow us to apply knowledge earned in
class to practical problems and solutions.
Model
Price
Features available
Parrot AR Drone
$250
$220
Remote controlled
Advanced stabilization system
AeroSky Quadcopter
$220
Remote controlled
$80
$220
To keep our final product competitive, the goal is to keep our project costs near those of the
competitors at least for the prototyping stage, however due to economies of scale this is not
realistic. The ultimate goal is, of course, to provide a competitive product at a lower price.
For initial development, we will use a development kit with a microcontroller that fits our
specifications.
User commands sent to the quadrotor from GUI must have a success rate of 60 %
Wireless communication must operate within a 5 m radius of the operator
Communication system must have a success transmission rate of 400 bytes/second
Stably hover while tethered in one spot with a 50 cm tolerance for 5 seconds
The desired roll, pitch and yaw angles should be achieved with a steady state error
of less than 10 %
The desired height should be achieved with a steady state error of less than 15 %
Disturbances up to 0.34 N should be managed while still meeting the roll and pitch
steady state error specifications
Detect obstacles within a 50 cm radius with a success rate of 60 %
Microcontroller Requirements
4 GPIO (General Purpose Input/Output) pins GPIO 60+ (far more than required)
for PWM controllers to output to each motor
controller on the quadrotor
1 TWI (Two Wire Interface) for the
accelerometer, gyroscope, and
magnetometer
2 TWI ports
4 USART ports
8 ADC channels
The IDE (Integrated Development Environment) for this family of microcontroller is Atmels
AVR Studio 6. This program includes a C compiler for this microcontroller and has many
precompiled libraries. This IDE also supports debugging with the AVR Dragon which will be
our external programmer/debugger for this project. See the schematic attached in
Appendix 1 for details of how the microcontroller is connected to the rest of the quadrotor.
The graphical user interface runs on three separate threads for the majority of its execution.
This separation of processes allows for smoother control. The initialization of these threads
is shown in Figure 1.
Main Thread
Thread to receive information
End
Initialize
Communication
initialized
Initialize
Communication link
broken
End
Separation of threads to receive and transmit information allows the threads to queue up
commands at the COM port without interfering with each others operation or excessive
waiting. Furthermore, the sending/transmitting thread (thread 2 as explained below)
spends a large portion of time in suspension.
3.2.1 Main Thread (Thread 1)
The main thread maintains control over the form elements, capturing user inputs from
keyboard, performing calculations, initializing the other two threads and closing them when
the program is over. This thread is the original program thread started when QUI.exe is run.
The main thread spans over several namespaces and a collection of functions, as outlined
briefly below using their class diagrams.
Modelspace::Model
Model
-^ triangles : array<Triangle>
-^ normals : array<Normal>
-^ vertices : array<Vertex>
-triangleCount : int
-verticesCount : int
-normalCount : int
+<<constructor>> Model() : void
+<<destructor>> ~Model() : void
+loadModel(char *mFilename)() : int
+draw() : void
+Model_init() : void
OpenGLForm::COpenGL
COpenGL
+f_one : QUI::Form1^
+quadrotor : ModelSpace::Model^
+prop : ModelSpace::Model^
-m_hDC : HDC
-m_hglrc : HGLRC
+<<constructor>> COpenGL() : void
#<<destructor>> ~COpenGL()
+COpenGL_one(iWidth, iHeight)() : int
+DrawGLScene() : int
+SwapOpenGLBuffers() : void
+KILLGLWindow() : GLvoid
#MySetPixelFormat(HDC hdc)() : GLint
#InitGL() : bool
#ReSizeGLScene(width, height)() : GLvoid
QUI::Form1
Form1
There is also a set of calculation functions which use the QUI namespace, but are not part of
any specific class.
The main thread does not run on a superloop, instead allowing other processes to take time
executing, and performing UI updates at specific timer intervals. Keyboard input and form
button presses are responded to using event functions. The processes on this thread are
shown in Figure 5 through Figure 10.
Communication
link started
Clearing all
sending flags
Start threads 2
and 3
Communication
link terminated
Turn
communication
indicator red
Turn
communication
indicator green
The communication link resources reside on two separate threads (as described further on)
for the majority of the time the information exchange between the main thread and the
others is done using pointers to specific character arrays for outgoing and incoming data.
The accelerometer data is used differently from motor speeds and ultrasonic sensor
readings. The accelerometer data can be used to determine how far the quadrotor has
travelled using a series of mathematical manipulations and is shown in Figure 6.
Accelerometer
data has arrived
Use calculation
functions to produce
quadrotor tilt and
distance traveled
Update position of
model in rendering
space
Motor speed data is used for updating the plots and this data is stored in text files in a
default directory. This process is shown in Figure 7.
Motor speed data
has arrived
Update graphs on
GUI
Ultrasonic data allows for rendering of obstacles around the quadrotor in the OpenGL panel
as is described in Figure 8. Obstacles are rendered as blocks since no distinction can be
made in terms of size using our sensors. Obstacles above and below the quadrotor are not
rendered because the view will not permit them to be viewed properly; instead, a note will
be displayed in the Messages window in the GUI to tell the operator about the distance to
ceiling and floor.
Ultrasonic data
has arrived
Update obstacles in
rendering
Two different methods can be used by the user to enter directional information. The first is
to enter the values of roll, pitch, yaw and z by hand, and simply transmitting those values as
is shown in Figure 9. This is the method of choice when debugging. A more advanced
method can be utilized that requires more computing as is shown in Figure 10. In that case,
the user will be able to press buttons on the keyboard and move the quadrotor accordingly.
Conversion from directions to proper roll/pitch/yaw/z values will be required.
User has entered
directions
Convert to proper
command (string)
10
Update
DIR_TO_SEND
flag
Convert direction to
roll/pitch/yaw/z
Convert to proper
command (string)
Update
DIR_TO_SEND
flag
Set roll/pitch/yaw/z to
hover configuration
Convert to proper
command (string)
Update
DIR_TO_SEND
flag
comm_CPPThread
+hPort : HANDLE
+^ req : int<array>
+DIR_TO_SEND : bool
-bw_timerAccRequest : BackgroundWorker
-bw_timerMotorsRequest : BackgroundWorker
-bw_timerUltrasonicRequest : BackgroundWorker
+<<constructor>> comm_CPPThread() : void
+<<destructor>> ~comm_CPPThread() : void
+comm_threadProc() : void
+comm_threadAddArguments (HANDLE *pArg1)() : void
+comm_sendDirections() : void
+comm_requestAcc() : void
+comm_requestUltrasonic() : void
+comm_requestMotors() : void
-bw_timerAccRequest_DoWork(^ sender, ^ e)() : void
-bw_timerAccRequest_RunWorkerCompleted(^ sender, ^ e)() : void
-bw_timerUltrasonicRequest_DoWork(^ sender, ^ e)() : void
-bw_timerUltrasonicRequest_RunWorkerCompleted(^ sender, ^ e)() : void
-bw_timerMotorsRequest_DoWork(^ sender, ^ e)() : void
-bw_timerMotorsRequest_RunWorkerCompleted(^ sender, ^ e)() : void
11
amount of system resources used. This also allows other applications running at the same
time as the GUI to use the available resources.
Each of the background workers has two associated functions _DoWork and
_RunWorkerCompleted, which receive sender information and parameters through the
function arguments.
comm_requestAcc, comm_requestUltrasonic, comm_requestMotors
These functions are associated with the req array. The sole purpose of the functions is to
queue up appropriate commands to be sent at the COM port.
comm_threadProc()
This function defines the operation of this thread. It is responsible for checking request flags
and the flag to send user directions out.
comm_threadAddArguments(HANDLE *pArg1)
This function receives pointers to data from the main process thread. It copies pointer
information into class variables.
comm_sendDirections()
This function is called when DIR_TO_SEND is set to true. The function then queues up a
command at the COM port with roll, pitch and yaw information for the quadrotor.
3.2.3 Receiving Thread (Thread 3)
The purpose of this thread is to poll the receiving flag of the COM port to check if any new
data has arrived. Its operation is completely independent from the transmitting thread. As
such, it will not know when to anticipate data returning even if a request for data
(accelerometer readings, ultrasonic data, motor speeds) was made in the transmission
thread.
comm_pollRX
+comm_port : HANDLE
+<<constructor>> comm_pollRX()
+<<destructor>> ~comm_pollRX()
+comm_pollRXProc() : void
+comm_pollRXAddArguments(HANDLE kPort)() : void
comm_port (HANDLE)
This handle is passed from the main thread to
allow the processes to use the available COM
port for reading values.
comm_pollRXProc()
This is a function that defines the operation of this thread. It remains in a loop and waits
until new data arrives at the COM port. If new data is available, it is read, stored, and a flag is
set to signal that it can be processed by the main thread.
12
comm_pollRXAddArguments(HANDLE *kPort)
This is a function that receives pointers to data from the main process thread. It copies
pointer information into class variables.
3.2.4 GUI Design and Functions
The current GUI design shown in Figure 13 offers the user several inputs and outputs
described below.
The motor speeds are displayed in the plots on the left hand side (on the left of the
3D rendering of the quadrotor in space).
The rendering will display quadrotor tilt at a given time (at intervals of 500ms). The
red arrow displayed in the figure below is a result of pressing a button on the
keyboard. The view of the rendering cannot be changed. Obstacles are to be
rendered around the quadrotor as rectangular blocks.
The roll, pitch, yaw and z fields at the top right of the form can be filled in by the
user. Pressing the Send button will signal the quadrotor to realize that
configuration. Another way to make the quadrotor move is to use the arrow keys on
the keyboard. This will convert the motion commands to roll, pitch, yaw and z
values.
The Messages window will display relevant information, error messages, warnings
and distances to floor and ceiling.
The Distance from Home indicator will tell the operator how far the quadrotor has
moved away from its origin in space. The operator has an option to return home by
following the shortest path available. Similarly, there is an ability to leave waypoints
at the quadrotors current location. The user can return to them using the shortest
possible path.
The Communication Link indicator is red when the communication has not been
established, and green otherwise. The connection and termination is done using the
buttons below it.
13
Using the Windows operating system, a standard COM port for RS232 communication will
be emulated. This COM port will be configured with the communication specifications
outlined in Table 4.
Table 4: COM port communication specifications
Baud Rate
9600
Parity
None
Flow Control
Off
14
The microcontroller USART port will be configured to the same settings as the USART
configuration with the RS232 Mini Wireless Bluetooth Module. AVR Studio 6 has a USART
library which includes functions for configuring the port to the required settings, sending
ASCII characters, sending strings, and reading ASCII characters. These functions will be
utilized to implement our quadrotor command list as shown in Table 5. The command list
will be a switch statement in C code that converts commands sent/read into movement or
graphical information.
Table 5: ASCII character commands
ASCII
Function
Character
Command
A
Set Roll
Set Pitch
Set Yaw
Set Z
Get Acceleration
Get Proximity
Get Data
After the ASCII character command, data can be transmitted as is shown in Figure 14. After
data is finished being sent for any command then a # character will be sent (# is a
termination character). After the # is received the system will wait for another valid ASCII
character command to continue the communication. If an invalid command is read then it
will ignore the transmitted information and wait for a valid command.
15
Yes
ASCII
character
command
Sent
Is a valid
command?
Yes
Is a data
character a
# ?
Send data
No
No
The purpose of the control system is to realize these inputs. The system will be based upon
proportional-integral-derivative (PID) control loops due to the ease of implementation of
this control method. The control loops will be running on the main microcontroller.
Control loops require feedback which will be provided by an Inertial Measurement Unit
housing an onboard gyroscope and accelerometer. These devices provide data from which
roll, pitch and yaw angles can be calculated. An ultrasonic rangefinder will provide height
feedback. The feedback values will be denoted as follows:
Using sensor feedback, the PID controller can then calculate motor speeds required to
realize the desired control inputs. The motor speeds will be denoted as M1, M2, M3, and M4.
They correspond to the four motors on the quadrotor as shown in Figure 15. A block
diagram of the control system inputs and outputs is shown in Figure 16.
16
FLIGHT CONTROL
SYSTEM
INPUTS
des_roll
OUTPUTS
M1
PID Controller
des_pitch
des_yaw
M2
M3
Feedback
zdes
M4
Height Data
Ultrasonic
Rangefinder
Inertial
Measurement
Sensor
Calculate feedback:
roll, pitch, yaw, z
Calculate acceleration
values
17
Acceleration values
The PID control loop equations to calculate the state space variables are as follows:
The K values are control gains which can be adjusted to provide various responses. These
will be tuned to achieve a fast, underdamped response. Cg is a constant which counteracts
the force of gravity.
The control loops can be expressed in graphical form. An example is shown in Figure 17 for
the pitch angle. Each loop is similar to the one shown in Figure 17, with an exception for the
height loop, which includes a constant to cancel out the constant pull of gravity on the
quadrotor.
18
The individual motor speeds (M1, M2, M3, and M4) must be calculated from the state space
variables. To do this, the state space variables are related to the motor speeds using the
following equations:
Taking the inverse of matrix A, the motor speeds can be found from [M]=[A]-1[U].
To help design the control system, a Simulink model was created using the control system
outlined above and the following physical model of the quadrotor:
Where:
The Simulink model is provided in Appendix 2. The values of Jyy, Jxx, Jzz, m and C are not
accurate because the quadrotor is not yet fully assembled with all the parts. Therefore, the
control gains will require tuning later on when the design is implemented. Using
approximate values for the physical model, the control gains of Kpi=10, Kdi=4, KIi=4 were
found to give a stable, fast, underdamped response.
19
3.4.3 Implementation
The control system designed in the Simulink model will be implemented using C code on the
microcontroller. The Inertial Measurement Unit used will be the MinIMU-9 v2 available
from Pololu Robotics and Electronics. This unit interfaces with the microcontroller using I2C
protocol.
Figure 18: Four directional ultrasonic sensor detection spectrum 35 cm from an obstacle
The obstacle avoidance system input and output diagram is shown in Figure 19. The analog
output signal of the ultrasonic sensors is analyzed using an Analog-to-Digital Converter
(ADC) to determine the distance to the nearest obstacle for each sensor.
20
The distance to the obstacle is calculated using the following formula supplied with the
ultrasonic sensors:
As a 3.3 V source is hard-wired to the ADC voltage supply it is used as the upper bound of
the ADC conversion. This represents a distance of 13 m as measured by the sensors, which
is a distance much greater than needed. However, as there is a 10-bit output from the ADC,
the resolution is still sufficient to accurately determine if the distance to the nearest
obstacle is within 50 cm.
If an obstacle is detected, data will be sent to the GUI to provide the user with updated
information on the surrounding environment as well as the current altitude of the
quadrotor. If the distance is within the 50 cm range, pre-determined roll, pitch, yaw and
altitude commands will be sent to the flight control system to maneuver away from the
obstacle.
4. Test Plan
4.1 Graphical User Interface
4.1.1 Testing successful transmission of commands
The purpose of this test is to measure the success rate of receiving and transmitting
commands. This is important in order to make sure that directional commands will be
properly sent to the quadrotor, and that information important for the user will be shown in
the GUI.
21
3. Start the AVR controller and the Bluetooth transmitter 1 meter away from the USB
Bluetooth receiver. Separate the AVR controller from the USB Bluetooth receiver by
increments of 1 meter until the terminal program indicates that data has stopped
transmitting. This will provide the furthest distance the quadrotor can operate in
meters.
4.2.2 Successful Command Transmission Rate
The purpose of this test is to determine if the effective rate of successful transmission of
bytes over the Bluetooth channel and to test if near-real time control of the quadrotor is
feasible.
Procedure:
1. Place the quadrotor and the receiver at exactly 5m away from the computer and
Bluetooth dongle (5m is the minimum required specification for this project).
2. The AVR controller will continuously transmit 1000 character commands (1 Byte
each) from the command list without pause.
3. Before the AVR controller starts transmitting, an internal timer on the
microcontroller will be initialized and will keep track of the time taken to send the
1000 character commands.
4. 1000 commands will be divided by the time taken to transmit them producing a
command rate in Bytes/second.
5.
6.
7.
8.
9.
10.
11.
24
directions. A circle with a 0.5m radius will be marked on the floor with tape. A timer will be
used to keep track of time.
Procedure:
1.
2.
3.
4.
5.
Place the quadrotor in the center of the circle marked on the floor
Command the quadrotor to hover at a height of 20 cm.
Start the timer
Stop the timer when the quadrotor moves outside the marked circle.
Compare the time with the specification of 5 seconds.
25
Table 6: Ultrasonic sensor combinations for the obstacle avoidance system testing
Sensor(s) with
Detection
LED On
1,2
1,2
1,3
1,3
1,4
1,4
1,2,3
1,2,3
1,2,4
1,2,4
2,3
2,3
2,4
2,4
2,3,4
2,3,4
3,4
3,4
1,2,3,4
1,2,3,4 SOLID
26
5. Budget
Budget outline
Budget request
Materials and supplies
$500
Software
Small equipment
Travel
Subscription to resources
Consultant fee
$50
Others; specify:
Others; specify:
Total
$550
B) Budget justification: The materials needed for this project are quite sophisticated and
therefore are expensive. As there will only be one quadrotor produced it is not feasible to
buy materials in bulk and lower the costs.
C) Source of funding: Microlynx Systems Ltd.
CARs 602.45: General Operating and Flight Rules from Canadian Aviation
Regulations (2012-1), Model Aircraft, Kites and Model Rockets
FCC Part 15 American standards for EMC (electromagnetic compatibility) of
devices.
Bluetooth Wireless Communication Standard
7. Work plan
Tasks
Deadline
Mar 1, 2013
Report #2 is ready
Apr 7, 2013
28
8. References
1. G. Mortimer, German multicopter makes first manned flight, (sUAS News),
[online] 2011, http://www.suasnews.com/2011/11/9691/german-multicoptermakes-first-manned-flight/ (Accessed: 5 November 2012).
9. Glossary
CLI-Command Line Interface: A type of interaction between a user and a computer program
where the user enters in lines of text to be executed.
C++: A common object oriented computer programming language.
I2C - 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.
PID Proportional-Integral-Derivative control: A linear control method with control
outputs based on the error between the desired control inputs and actual feedback and the
derivative and integral of this error.
29
10. Appendices
10.1 Appendix 1
30
10.2 Appendix 2
The Simulink model of the control system is shown in this appendix.
31