Autonomous Quadrotor Project Anzhelka User manual

Autonomous Quadrotor Project
Cody Lewis
[email protected]
Luke De Ruyter
[email protected]
May 29, 2012
And when he [Herod] had apprehended him [Peter], he put him in
prison, and delivered him to four quaternions of soldiers to keep
him; intending after Easter to bring him forth to the people.
–Acts 12:14, King James Bible, Cambridge Edition
1

Abstract
This project discusses the design of a four rotor autonomous aerial vehicle
platform called the Anzhelka Project. The system is based on the open source
Elev-8 quadrotor mechanical hardware platform and the Parallax P8X32A mi-
crocontroller. In this paper we discuss the preparation that we have done in
order to create a stable, autonomous vehicle. We then propose an implementa-
tion sequence that will result in a stable, autonomous hover. This paper focuses
on the practical aspects of quadrotor flight. For a theoretical treatment see the
Anzhelka project mathematics document [3].
Revisions
Current project status and files can be found at
blog.anzhelka.com
code.anzhelka.com
Version Changes Commiter
v0.01 All of the spelling was checked
and fixed for the first 2 sections.
Luke
v0.02 Needs to be proof read in some
areas. Needs tables, conclu-
sions, High level, references, ap-
pendices, acknowledgements
Luke
v0.03 Cleaned up the document some,
added images and tables.
Cody
v0.04 Added conclusion, estimated
control loop speed, small sec-
tions, figures.
Cody
v0.05 Fixed some gramtical errors,
added weights, cleaned up.
Luke
2

TABLE OF CONTENTS TABLE OF CONTENTS
Table of Contents
Abstract 2
Revisions 2
Table of Contents 4
1 Introduction 5
1.1 Quadrotor Mathematics . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 ExecutiveSummary ......................... 6
1.3 Design Objectives and System Overview . . . . . . . . . . . . . . 7
1.4 Current Project Status . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Background and Prior Art . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Development Environment and Tools . . . . . . . . . . . . . . . . 8
1.6.1 Directory Structure . . . . . . . . . . . . . . . . . . . . . 8
1.6.2 Development Cycle . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . 11
2 Requirements Specifications 11
2.1 GuidingVision ............................ 11
2.2 Assumptions ............................. 12
2.3 Realistic Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 System Environment and External Interfaces . . . . . . . . . . . 12
2.5 Budget and Cost Analysis . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Safety ................................. 13
2.7 Importance of Team Work . . . . . . . . . . . . . . . . . . . . . . 13
3 System Design 14
4 Software Introduction 14
4.1 Propeller ............................... 14
4.1.1 Architecture ......................... 14
4.1.2 Programming......................... 16
4.2 Control Loop Frequency . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Other Software Notes . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Quadrotor Prototype Construction 18
5.1 Hardware ............................... 18
5.1.1 Frame............................. 19
5.1.2 Motors/Propellers . . . . . . . . . . . . . . . . . . . . . . 19
5.1.3 Power Board PCB . . . . . . . . . . . . . . . . . . . . . . 20
5.1.4 Thrust/Torque Test Stand Construction . . . . . . . . . . 22
5.2 Software................................ 22
5.2.1 RotationSpeed........................ 23
5.2.2 Pulse Width Modulation . . . . . . . . . . . . . . . . . . . 24
5.2.3 UART Serial Communication . . . . . . . . . . . . . . . . 25
3

TABLE OF CONTENTS TABLE OF CONTENTS
6 Constant Identification 25
6.1 Thrust/Torque Test Stand Theory . . . . . . . . . . . . . . . . . 25
7 Implementation Details 26
7.1 Anzhelka Data and Command Exchange Protocol . . . . . . . . . 26
7.1.1 Protocol Implementation Details . . . . . . . . . . . . . . 27
7.1.2 ExampleUsages ....................... 27
7.1.3 Protocol String Table . . . . . . . . . . . . . . . . . . . . 27
8 User Interface 28
8.1 AnzhelkaTerminal .......................... 28
9 Testing 29
9.1 HardwareTesting........................... 29
9.1.1 Frame............................. 29
9.1.2 Motors/Propellers . . . . . . . . . . . . . . . . . . . . . . 30
9.1.3 PCBs ............................. 30
10 Maintenance Plan 31
10.1 For the next ten weeks . . . . . . . . . . . . . . . . . . . . . . . . 31
10.2Forthenextyear........................... 32
11 Engineering Effort and Societal Impacts 32
11.1 Realistic Constraints on Time and Money . . . . . . . . . . . . . 32
11.2 Safety and Reliability . . . . . . . . . . . . . . . . . . . . . . . . 32
11.3Aesthetics............................... 32
11.4 Anzhelka Marketing . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.5Ethics ................................. 34
12 Conclusions 34
13 References 34
14 Acknowledgements 35
15 Appendices 36
4

1 INTRODUCTION
1 Introduction
A quadrotor, also known as a quadrotor helicopter or quadcopter, is a
mutltirotor aerial vehicle that has four rotors mounted on a rigid frame to
provide lift. Quadrotor designs first appeared in the 1920s, but were abandoned
because of bad performance and high pilot work load.
In order to keep a quadrotor from spinning on its own axis, it must be built
with counter rotating blades. Without counter rotating blades the quadrotor
would create enough torque to spin in a constant direction around its’ own axis.
Figure 1: Orientation of the body axis with respect to the motor numbers and
rotations.
Quadrotors are highly manoeuvrable. A quadrotor can take off and land
vertically. They can translate horizontally through the air, and they can also
hold altitude. With a suitable pilot(or software) behind the controls one can do
amzing aerial acrobatics with the quadrotor.
Quadrotors are very similar to helicopters, so what advantages do quadrotors
have? Quadrotors have no mechanical gears between the motors and propellers.
Each motor is directly driving its propeller. Having four propellers allows you
to have a much smaller propeller than what is on the typical helicopter. This
means that the propellers possess less kinetic energy while spinning allowing for
a safer platform.
1.1 Quadrotor Mathematics
A quadrotor is a very complex vehicle that is difficult to control. It is
an under-actuated system with only one direction of force and three moment
directions. The treatment of the math is too complex to include here. Instead,
we have a separate document that discusses the math and theory of quadrotor
flight in great detail. See citation [3]. The rest of this paper will focus on
everything else related to the quadrotor.
5

1.2 Executive Summary 1 INTRODUCTION
1.2 Executive Summary
Figure 2: Rendering of the Open Source Elev-8 quadrotor platform used in the
Anzhelka project (image courtesy of Parallax).
This senior design project’s goal is to create an autonomous quadrotor that
can be used to film outdoor sports such as mountain biking, snowboarding, and
skiing. The quadrotor will have a video camera mounted on a gimbal that will
always point at a subject/object to which the tracking device is attached. The
tracking device will have its own GPS and IMU in order to be able to determine
the location and heading of the subject/object. The quadrotor is intended to
fly autonomously, ie without a human controller. The quadrotor should be able
to maintain attitude (orientation) and position without human intervention.
Our quadrotor has many features including:
* 3-axis gyro
* 3-axis accelerometer
* 3-axis compass
* voltage and current monitoring of each motor
* a separate battery for logic operations
* the ability to control up to 8 servos
* the ability to track the exact speed of each motor
* 8 unallocated analog inputs
* mounting holes for all components and future upgrades
6

1.3 Design Objectives and System Overview 1 INTRODUCTION
This senior design project was built around being Open. How Open? Both
Open Source and Open Hardware. The open source frame that was used for the
quadrotor was designed by Ken Gracey, an employee at Parallax, and is called
the ”Elev-8”. Our project is hosted hosted by Google Code in the form of a Git
repository ([1]). Here you can find all the information used and created during
this senior design project. There is also a blog which goes into some of the
extensive detail that was put into this project ([2]). The main processing board
for this quad rotor features a Parallax Propeller 1, overclocked to 100Mhz, and
a fully custom board that measures in at 4 inches by 3 inches.
Testing the quadrotor is a challenge in and of itself. But before that, one of
the tests that has to be done is to calculate some of the constants for the control
algorithms (motor torque and thrust). This means that there must be a test
stand that tests and can calculate both of these constants. A slightly different
kind of test is testing the functionality of the control board that was designed
for the quadrotor.
The project was started without any expertise or experience with autonomous
flying or quadrotors, but with a will to learn, create and develop a system that
could even be understood by anyone. Software is our group expertise. Both
team members have years of experience in multiple programming languages.
Hardware on the other hand is a bit more difficult. Only one team member
has any experience with designing PCBs and circuits, but not nothing to the
extent of this project. We believe that, based on the work we have put into
the project, that we have earned the class credits that we are receiving. Ap-
proximately 30 hours per person per week were devoted to this project(terminal
program).
1.3 Design Objectives and System Overview
This project was designed to be continuously improved upon and to be used
in an many different ways. After watching countless videos from Go Pro cameras
from a single perspectives and partial views of the subject, project Anzhelka
was created. Anzhelka will allow users to be able to capture video angles that
were once unattainable without costing thousands of dollars. Anzhelka will
allow users to capture video with the same ease as using a Go Pro camera, but
without the single perspective and jitter from traditional methods.
The quadrotor will have at least a 15 minute run time, with the ability to
carry a 2 pound payload. It will also be optionally controllable by a human
from up to a mile away with line of sight. The control loop to keep the platform
stable will run at least 100Hz, enabling stable control.
On this project both team members share the same responsibility for all
components of the system. This follows in the Agile philosophy. Each team
member understands all aspects of the system, and has worked on all aspects.
1The coincidence between Propeller and propeller is unfortunate and can be a source of
confusion. If Propeller is capitalized then the text is referring to the Parallax microcontroller.
If propeller is not capitalized then the text is referring to a fixed pitch airplane ”air screw”
7

1.4 Current Project Status 1 INTRODUCTION
This creates a universal understanding a commitment to the project while re-
moving territorial hoarding. There is no ”my work”, only ”our work”.
1.4 Current Project Status
As of this writing, we still have work to do in order to achieve stable au-
tonomous hover. We are in the process of testing the thrust torque test stand,
and verifying all electrical circuits on the quadrotor. Once that is complete we
will be able to write the three control loop blocks, as described in detail in the
Anzhelka mathematics document [3]. It is estimated that these blocks will be
able to run at up to 300Hz (section 4.2). For the project schedule, see subsection
10.1.
1.5 Background and Prior Art
There are many different quadrotor designs available, but relatively few open
source quadrotors. The most noticeable are the AeroQuad ([16]) and the Ar-
ducopter ([17]). Most quadrotor theory seems to be the product of research labs
such as [4]. This project is different in that it uses the Parallax propeller as it’s
processor and it is very well documented from the beginning.
1.6 Development Environment and Tools
The Anzhelka project software was developed for the most part using a Linux
system. All code and other project files are hosted on the project Git repository
([1]). The code was written in Gedit, compiled and downloaded with the BSTC
compiler, and interfaced with using picocom.
1.6.1 Directory Structure
The project uses the following directory structure:
/hardware
/ frame
/ pcb
/software
/spin
/ src
/ lib
/test
/tool
/config
/java
/ src
/ lib
/test
/tool
8

1.6 Development Environment and Tools 1 INTRODUCTION
/config
/ doc
/ da tasheet
/reports
/figures
/ notes
/ tests
/ extra
/ extra
hardware: Subfolders will store the major components of the project. For
example, the frame has several .dxf files that are sent to the laser cutter, so that
will all go into a subfolder called frame. The project may have several PCBs
made as well, and so each should go into a subfolder under pcb.
software: The software is separated by language into separate folders. This
makes sense because each processor in the project will have only one language
running, but separate processors that are running the same language may share
components (library files, for example). Each language has a number of sub-
folders:
*src is where the source code for the project is stored. Subfolders as
appropriate.
*lib stores all general purpose library files (code) such as Propeller Obex
objects.
*test stores the test harnesses such as unit tests and Spin code to test a
particular module (the latter case would have a ’main’ type method and
would be self supporting when running on the Propeller).
*tool holds all the relevant development tools for that language (BSTC for
Spin, for example).
*config stores any sort of relevant compile time or testing configuration
files.
The files that are in the software folder should be used only for what runs
onboard the quadrotor. Test programs or desktop PC client programs should
instead go into the extra folder. Note that these programs may still access the
lib and tool subfolders in the software directory.
documentation: This folder stores all the relevant datasheets in the datasheet
subdirectory, and any other project documentation that is deemed to fit. Note
that most documentation probably belongs in the Anzhelka wiki on [1].
The datasheet and reports folders contain the reference datasheets for each
component and the various generated reports of the project, respectively. The
figures folder holds an images that is used in the documentation. The notes
folders holds papers that are interesting and relevant to the project, such as
the cited research papers. The tests folder holds the test results data, and any
9

1.6 Development Environment and Tools 1 INTRODUCTION
associated data processing scripts. The extra folder holds other documentation
material such as project logos and fonts.
extra: This folder contains other associated programs for the project. Since
the software folder is dedicated exclusively to software that is intended to fly
the quadrotor other programs need to be stored in the extra folder. This folder
stores the Anzhelka Terminal files and the Thrust/Torque test stand files for
example.
1.6.2 Development Cycle
Figure 3: A screenshot of an open Spin file in Gedit showing syntax highlighting.
To facilitate the development cycle a simple compilation script was devel-
oped. A template form of this script can be found in
/software/spin/tool/bst−template.sh. This script will compile the Spin pro-
gram, and if no errors are found it will attempt to download to the Propeller.
If successful it will open picocom (terminal program) on the USB port to lis-
ten for data. Using this script while programming dramatically decreases the
write-compile-test debug cycle.
All code was written in Gedit. Gedit is a simple text editor with a few
features built in, including syntax highlighting. For most of the languages in
this project, Gedit has provided suitable syntax highlighting. Propeller Spin,
however, is not available by default. Syntax highlighting was accomplished by
writing a language definition file (/software/spin/tool/spin.lang) and placing
10

1.7 Definitions and Acronyms 2 REQUIREMENTS SPECIFICATIONS
it in /usr/share/gtksourceview −3.0/language −specs. Gedit will then auto-
matically highlight the Spin files.
All code is compiled with the BSTC compiler. This is available in [5]. This
compiler was selected because it is Linux compatible and it has several optimiza-
tions over the Parallax provided compiler. In addition, it has a command line
interface which makes it easy to integrate into a compilation cycle script. BSTC
will also download the compiled code via the USB COM port to the Propeller.
All project files are hosted on the project Git repository, hosted by Google
Code at [1]. A Git repository was selected so that all developers would have
equal access to the source files, changes would be logged and trackable, issues
would be trackable, and so that concurrent work on files could be easily merged.
All project files are open source under the MIT license and can be downloaded
freely.
1.7 Definitions and Acronyms
AT Anzhelka Terminal
$ATxxx Anzhelka Terminal Communication String
BSTC Brad’s Spin Tool Compiler
EEPROM Electrically Erasable Programmable Read-Only Memory
ESC Electronics Speed Controller
GUI Graphical User Interface
IMU Inertial Measurement Unit
OOP Object Oriented Programming
PASM Propeller Assembly
PCB Printed Circuit Board
PID Proportional-Integral-Derivative
PWM Pulse Width Modulation
RAM Random Access Memory
RISC Reduced Instruction Set Computer
UART Universal Asynchronous Receiver /Transmitter (serial)
UAV Unmanned Aerial Vehicle
WYSIWYG What You See Is What You Get
2 Requirements Specifications
In this section we define the various requirements of the quadrotor platform.
The quadrotor must be able to achieve various goals, and since it is a hard real
time system the goals must be achieved by a specified deadline.
2.1 Guiding Vision
Have you ever mounted a camera on to your helmet and rode down a moun-
tainous trail? What about trying to capture yourself while water skiing? Watch-
ing the video usually turns out shaky and in one perspective. Would it be nice
to be able to see what you did wrong that caused you to fall of your bike? Most
11

2.2 Assumptions 2 REQUIREMENTS SPECIFICATIONS
of the time you can’t see what went wrong. What if you could do all of that
while still capturing amazing views? All this can be accomplished while being
as simple as powering on a couple of devices. Simply launch your quadrotor
with the press of a button, and get amazing video. This is our vision for the
project.
2.2 Assumptions
For this project, we assume that the quadrotor frame is rigid and that the
propellers are rigid. We assume that the IMU orientation information is correct
and without error. We expect the quadrotor to operate in still air, and that it
moves slowly through the air.
2.3 Realistic Constraints
Every system has constraints and Anzhelka is no exception. The most im-
portant constraint is the life of the battery. If each motor consumes 15 amps
on average then that is a current drain of 60 amps from the motor battery.
Assuming that the battery has 6Ah of energy, then it would be able to power
the quadrotor for 10 minutes. Typical flight times for this platform are around
15 minutes, so average current drain is likely less.
The system is also constrained by the maximum acceleration and maximum
rotation speed of the propellers. Typically the propeller will not rotate faster
than 1200 rpm. This in turn constrains the maximum thrust and torque gener-
ated by the motor.
Finally, the system is also constrained by the mass of the vehicle. Since the
quadrotor has inertia, to change it’s motion requires a greater force from the
motors. The motors might not have the power or orientation to change the
quadrotor momentum.
2.4 System Environment and External Interfaces
To be able to accomplish all of these tasks there are many of interfacing
between many different devices. Our main control board must control all 4
ESC’s, communicate with the IMU via a serial UART, control servos via PWM
signals, monitor the voltage and current of each motor via A2D circuits, and
compute the control loop.
2.5 Budget and Cost Analysis
Unfortunately there was no money that was given to the team in order
to support the project. All of the funding has been from the team members’
personal accounts. As of this writing, $3156.24 has been spent on parts for the
project. Below is the estimated cost per quadrotor vehicle:
12

2.6 Safety 2 REQUIREMENTS SPECIFICATIONS
Supplier Name Unit Qty Total
Parallax Altimeter $29.99 1 $29.99
Parallax Propeller Chip QFP $7.99 1 $7.99
Parallax 64KB EEPROM $1.99 1 $1.99
Parallax 5 MHz Crystal $1.10 1 $1.10
Sparkfun Radio Modem UM96 $44.95 2 $89.90
Hobby King 450 Outrunner Motor - Trinigy $14.04 4 $56.16
Hobby King 30A ESC $5.99 4 $23.96
Hobby King 3S 30C 1000mAh Battery $8.99 1 $8.99
Hobby King 3S 30C 8000mAh Battery $44.11 1 $44.11
Hobby King Deans XT Plugs (10 pairs) $3.08 2 $6.16
Hobby King 12 AWG 1 meter wire Black $2.49 3 $7.47
Hobby King 12 AWG 1 meter wire Red $2.49 3 $7.47
McMaster-Carr 5/8” Aluminum Tubing 6’ $16.38 1 $16.38
McMaster-Carr 3/32” Delrin 24”x48” $70.67 1 $70.67
McMaster-Carr 1/4” Delrin 12”x12” $27.87 1 $27.87
McMaster-Carr 4-40 5/8” Standoff $0.46 12 $5.52
DIY Drones Propellers 10x4.5 1 push 1 pull $6.00 2 $12.00
Pololu CHR-UM6-LT IMU Sensor $149.99 1 $149.99
Anzhelka Power control board $166.60 1 $166.60
Tower Hobbies Eagle Tree RPM sensor $13.79 4 $55.16
Total $789.48
2.6 Safety
When dealing with any robotic system one must take extreme cautions in
order to ensure the safety of everyone. Autonomous systems are particularly
dangerous because there is human behind the controls of the system and can
become unpredictable in the event of a system failure.
Several precautions are enacted to decrease the likelyhood of accidents. Dur-
ing frame construction the team uses fasteners, washers, and nuts that are of
suitable specification. All threaded components are secured using blue Loctite
to ensure that nothing will loosen on its own. Whenever motors are spinning
safety glasses are required. This provides protection in the event that a propeller
has a failure and is detached/released from the motor.
2.7 Importance of Team Work
Being able to work in a team is both a skill and a challenge. Working on
a project in a group helps you split up the work load and possibly get more
work done in less time, however being able to work together with others on the
project could present a greater challenge than the project itself.
This was a foreseen challenge and the team set up a Git repository for all
code, data, images, and presentations. There was also an official blog set up
where we could go in great detail on what we were working on and what we
13

4 SOFTWARE INTRODUCTION
had yet to complete. With these two resources set up and with the help of
keeping an open schedule the team has been able to successfully coordinate and
maximize productivity.
3 System Design
The system is fairly simple. The general system architecture consists of the
central Propeller microcontroller interfacing with a number of different devices.
Both hardware and software mimic this layout, which is shown below.
Figure 4: The layout of the devices in the system at a hardware level.
4 Software Introduction
This section describes the quadrotor software environment.
4.1 Propeller
For this project we selected the Parallax Propeller as our main embedded
processor. This chip has several unique features that make it well suited to the
real time requirments of quadrotoor flight. The Propeller is relatively inexpen-
sive as well: $8 per chip, plus approximately $2 for support components.
4.1.1 Architecture
The Propeller microcontroller has a unique architecture. The Propeller is a
microcontroller is a 8 core 32 bit RISC processor. For this project the Propeller
has been overclocked from the default 80MHz to 100MHz. This additional
speed facilitates more complex computations without sacrificing output rate.
14

4.1 Propeller 4 SOFTWARE INTRODUCTION
Each core, called a COG, is identical with equal access to all chip resources.
The Propeller has a central RAM area called the HUB which is COG accessible
in a round robin fashion.
Figure 5: The functional architecture of the Parallax Propeller (courtesy of
Parallax).
The Propeller is distinctly different from most other microcontrollers by it’s
lack of built in hardware. The Propeller does not have any hardware level
serial ports, analog to digital or digital to analog ports, or any pulse width
modulation ports. Instead, the Propeller is designed to be able to use software
for these common interfaces. This is typically done through what is known as
bit banging. The only exception is the built in video generation hardware that
assists in creating NSTC, PAL, or VGA signals. To make development easier
for the programmer, Parallax hosts a source code website that provides code for
common tasks such as serial or PWM.
The Propeller has two built in languages: a high level language called Spin
and the assembly language called PASM. PASM is executed directly by a COG.
Spin is executed by a built in PASM Spin interpreter that can be dynamically
loaded into one or more COGs. Other high level languages available for the
Propeller generally operate in a similar manner to Spin. This project uses Spin
and PASM exclusively.
The Propeller has three different memory locations: 2KB of COG RAM,
32KB of HUB RAM, and external 64KB of I2C EEPROM. Upon startup, the
Propeller copies the contents of the EEPROM to HUB RAM, loads a Spin
interpreter into COG 0, and begins execution. Any PASM code, including
15

4.2 Control Loop Frequency 4 SOFTWARE INTRODUCTION
the Spin interpreter, must fit in 496 instructions or less in order to fit into
the COG RAM. The Propeller does not have provisions for fetching PASM
instructions from other locations besides COG RAM. For Spin code the compiled
interpretable bytes are stored in the HUB RAM, and are fetched and decoded
by the Spin interpreter.
4.1.2 Programming
The Propeller is programmed in PASM and a high level language called Spin.
In general, PASM is used when speed is required. At 100MHz, the Propeller
can execute 25,000,000 assembly instructions each second (each instruction takes
40ns). By contrast, the interpreted Spin language is about 100x slower. Because
of this contrast Spin is used where ease of programming is important, and PASM
is used where speed is important.
Spin is officially called an object oriented programming language, but there
are some subtle differences compared to mainstream object oriented terminol-
ogy. Spin OOP is used to organize code into logical blocks much like an import
statement in C++ or Python. Spin objects do not use techniques such as class
instances, inheritance, or subtype polymorphism. A Spin object is used to
group related functions together into a unit that can be included in multiple
Spin programs.
Typically, Spin objects are used for interfacing with external devices. For
example, a typical Spin program might have an object for serial communication,
an object for VGA signal generation, and an object for I2C communication. The
Parallax Object Exchange ([18]) hosts Parallax written objects and community
written objects under the open source MIT licence.
Spin syntax is very similar to Python. To denote a new scope Spin uses in-
dentation instead of curly braces (familiar to C/C++ and Java programmers).
Spin code is divided into blocks: CON (constant), VAR (variable), OBJ (ob-
ject), DAT (data), PUB (public function), and PRI (private function). Most
typical programming constructs are a part of the Spin language: conditional IF
statements, FOR loops (called REPEAT), boolean conditions, and so on.
All variables in the Propeller are integers. Variables are typically 32 bit
signed integers called longs, but in Spin it is possible to create 16 bit or 8 bit
sized variables as well (called words and bytes, respectively). Global variables
are declared in the VAR block, and global constants are declared in the CON
block. PRI and PUB functions can declare local variables, along with function
parameters.
4.2 Control Loop Frequency
For our software, the critical portion is the main control loop that keeps the
quadrotor flying at the desired attitude (roll, pitch, yaw) and altitude. It is
essential that this control loop operates fast enough to respond to disturbances.
From our research into what other quadrotor groups have done we have found
16

4.2 Control Loop Frequency 4 SOFTWARE INTRODUCTION
that 50Hz to 75Hz is sufficient for flying. So for our project we need to analyze
our system and determine if we can achieve the desired rate.
The first component to consider is the inertial measurement unit (IMU). The
IMU that we have selected is the CHR-UM6-LT IMU. From the datasheet, it
can output at up to 300 Hz. On the output we have the ESCs that control the
motors. These expect a control pulse every 20ms, so that is on update rate of
50Hz. Most stock components can run with a slightly faster update rate, and
we can select ESCs that are designed for a faster rate. In any case, we have
guaranteed support for 50Hz updates with the hardware we have.
Now we need to consider the software control loop. We’ve broken the math
into three blocks: attitude control, altitude control, and motor control. The
equations can be found in the Anzhelka mathematics document [3]. The attitude
control block and altitude control block can be done in parallel, and their output
fed into the motor control block. We will be writing the code in Propeller
Assembly using the Float32 floating point library ([15]).
The Float32 documentation includes timings and space requirements for
each of the mathematical functions. If we count the operations required for
each block we can then calculate an estimate of running time and space.
First, we have to count up all of the operations so we know how much math
we have to do:
Quantity + - * / cos sin asin acos atan2 sqrt quat* Sum
Moment 1 6 20 11 3 4 0 2 2 0 3 52
Altitude 3 1 4 1 0 0 0 0 0 0 2 11
Motor Speed 14 10 18 10 0 0 0 0 0 4 0 56
Sum 18 17 42 22 3 4 0 2 2 4 5 119
Our control loop has 119 mathematical operations. The number sounds
small, but it is slightly misleading. In the next table we see that the time to
execute an addition or multiplication is much less than it is to calculate arcsin or
arccos. For quaternion multiplication we assume that one multiply has 6 floating
point additions, 6 floating point subtractions, and 16 floating point multiplies.
This follows from the quaternion multiplication formula. In summary, since we
have the number of each operation, we can calculate the total times:
Operator + - * / cos sin asin acos atan2 sqrt quat* Sum (µs)
Unit Time 3.7 3.8 8.4 10 78 74 261 265 117 173 225
Moment 3 23 168 116 234 298 0 530 234 0 675 2283
Altitude 11 3 33 10 0 0 0 0 0 0 450 509
Motor 52 38 151 105 0 0 0 0 0 694 0 1042
Sum 67 65 352 232 234 298 0 530 234 694 1125 3325
17

4.3 Other Software Notes5 QUADROTOR PROTOTYPE CONSTRUCTION
Our estimates show that we can have an inner control loop of 260Hz, and if
we parallelize the moment and altitude calculations as shown above then we can
get about 40Hz faster for a control loop frequency of 300 Hz. Also of interest
is that the quadrotor control loop has a response time of 3.3 milliseconds. For
reference, the average human reaction time is roughly 200 milliseconds ([14]).
Finally, we are interested in code size. The floating point library has a
number of required support functions that do things such as convert to and
from floating point, compare floats, and so on that require space. We also
assume that 4 longs on average are used to setup each operation. This gives
totals of
Block Longs
Moment 552
Altitude 275
Motors 468
So, if we were to do each instruction in sequence then it would take approxi-
mately 850 longs (sum without duplicates). Unfortunately, a Propeller cog only
has enough memory for 496 longs. If we break it into sections then the altitude
and motor calculations will fit into a single cog, but the moment block is too
big. Some optimizations will probably be able to reduce the size to fit.
All in all, the code performance estimates are looking very promising. We
should be able to achieve 100Hz update rates and the use of only two cogs
without too much trouble.
4.3 Other Software Notes
The other software in this project is standard. This project uses a Phython
GUI and a shell script for program compilation.
5 Quadrotor Prototype Construction
A quadrotor to the specifications is being constructed for this project.
5.1 Hardware
At this point in the project, we have developed four main areas of hardware:
the quadrotor frame, the motors and propellers used, the power board PCB,
and the thrust torque test stand. These components are, roughly, what will be
used for the rest of the project and are relatively static.
Frame Dimensions without rotors attached. (longways)
28 1/4 inches (718 mm) X 28 1/4 inches (718 mm) X 4 5/8 inches (117mm)
Frame Dimensions with rotors attached. (longways)
36 1/4 inches (921 mm) X 36 1/4 inches (921 mm) X 6 3/8 inches (161mm)
18

5.1 Hardware 5 QUADROTOR PROTOTYPE CONSTRUCTION
Item Mass(Grams)
Frame 450g
Each propeller 8g
Motor (black) 85g
Motor (red) 90g
ESC (black) 20g
ESC (red) 25g
5000MAH Battery 410g
8000MAH Battery 650g
5.1.1 Frame
The quadrotor frame that we are using for this project is the open source
Elev-8 frame from Parallax ([6])The resin plates are constructed out of a ma-
terial called Delin R [9] made by DuPontTM . We had this material laser cut for
us by a W9GFO from the Parallax forums. The booms of the Frame are made
out of 5/8” thin wall aluminium tubing.
For the screws we are using hex pan head and hex socket cap screws. These
screws are very common in the industrial supply industry. For all of the screws
we are using blue LocTite or a nylon locknut to ensure that the screws do
not loosen from their secured position. Lockwashers are not used due to being
completely ineffective and, in fact, worse than nothing at all ([11]).
Diagrams for the frame components have been included in the appendices,
and are also available at [1].
5.1.2 Motors/Propellers
Since neither one of the team members has any experience with quadrotors,
we have selected two different motors for the testing of our platform. To match
with these two motors we picked out two different brands of ESCs in order to
determine which would would be best with the platform.
We also decided on a 10 inch rotor with a 4.5 degree pitch. We decided on
10 inches because it gave us plenty of clearance between the rotors and should
not produce turbulences between each other. As for pitch, if you want a very
stable take off and landing of the quadrotor you would go with less of a pitch,
however if you want to be able to translate rather quickly you want more of
a pitch. Every fixed pitch propeller is designed for maximum efficiency at a
certain free air stream velocity through the blades. Hovering (ie, no free air
stream velocity) is most efficient at very small pitches ([12]).
19

5.1 Hardware 5 QUADROTOR PROTOTYPE CONSTRUCTION
Figure 6: PWM vs RPM under no load. They are nearly the same on the PWM
up and down.
Figure 7: Volts vs RPM under no load. As you can see that the current is linear
with the voltage.
5.1.3 Power Board PCB
For this project we developed a custom circuit board to power the quadrotor.
This PCB has all the hardware on it to facilitate a number of features:
* Propeller microcontroller, overclockable
20