Вы находитесь на странице: 1из 8

Pandaboard Quadcopter

William Hahne

The purpose of this project was to create a quadcopter based around the Pandaboard, which is a TI
OMAP4 based computer. The project included building a frame, choosing motors, propellers, and speed
controllers, as well as creating a PCB to interface the sensors with the Pandaboard. Since the
Pandaboard is an unusual platform to base a quadcopter around this project also included writing all the
necessary software to stabilize and control the quadcopter.


Development Board
I chose to use a Pandaboard to handle all the control for the quadcopter. The Pandaboard is a
development board for the TI OMAP4 SoC. It has five cores, two of which are Cortex-A9 processors, two
are Cortex-M3 processors and there is one DSP. On my quadcopter the Cortex-A9 processors are
dedicated to running Linux. One of the M3 processors runs the real-time code for stabilization and
control. The other M3 and DSP are unused.
The Pandaboard was chosen since it provided considerably more power and flexibility than most
controllers used for quadcopters. Most quadcopters simply use a microcontroller such as an AVR or PIC.
The more powerful processor allows the quadcopter to run Linux which means attaching an off-the-shelf
USB camera is a possibility. It also means running computer vision software such as OpenCV is possible
on-board. Even so, it is also easy to transmit video back to a computer over the built in wi-fi.
There are still a few disadvantages to using a system such as the Pandaboard. The most obvious is that it
is considerably more complicated and difficult to write the software for the Pandaboard rather than a
simpler controller. The Pandaboard does also use more power but the power used by the Pandaboard is
still dwarfed by the power consumed by the motors. Another issue is that the Pandaboard dictates a
minimum size for the quadcopter since the Pandaboard is very large and heavy compared to a simpler

The frame was made out of aluminum due to aluminum being fairly lightweight and strong as well as
easy to work with and cheap. The arms are 5/8 square tubing which was sold as towel bar at Home
Depot. The rest of the aluminum parts were made from 1/16 aluminum sheeting. The mounts for the
motors were made from 1/8 acetal plastic Landing gear used swimming pool noodle connectors since
they are lightweight and provide some protection against a hard landing.
The quadcopter arms are 11 and are attached together by two 5 x 5 plates. The bottom plate is not a
square to save weight and allow the battery straps to attach. The motor mounts are 1 square pieces
of plastic with holes drilled for motors. Having plastic squares on both the top and bottom is probably
overkill and makes the motors quite hard to attach, although they are held very securely. All the screws
are type 4-40.

The motors are RCTimer 2830/14 and the Propellers are APC 10x4.7. The motors were picked because
they were approximately the right size for the propellers and the propellers were picked for similar
reasons. A more ideal quadcopter would probably have motors and propellers more precisely chosen
with calculations to back up the choice, but as I am not an aerospace engineer I decided that I would just

pick motors and propellers that were used by others successfully for similar sized quadcopters. The
battery is a Zippy 4000 mAh battery which was chosen since it was a reasonable weight to expect the
quadcopter to carry and has enough capacity to provide a typical flight time of around 10-15 minutes.

Electronic Speed Controllers (ESCs)

The ESCs chosen were RCTimer 30A speed controllers which are rebranded Hobbywing speed
controllers. These were recommended speed controllers for use with the quadcopter. The problem with
these speed controllers is that they were made for use with RC airplanes and not helicopters. With stock
firmware they can only accept a PWM signal at 50 Hz. This is problematic since in order to stabilize well
a quadcopter should update the motor speed much faster. The good news with these controllers is they
can be flashed with new firmware allowing them to accept a 400 Hz PWM signal which is much more
suited to quadcopter use. This allows the quadcopter to stabilize much more easily.
These speed controllers were very cheap, costing around $10 each. The issue with this is there are some
quality concerns. One of my ESCs will sporadically refuse to spin the motor, and this issue means that
the quadcopter has yet to have a test flight since I need to replace the problematic controller first.

Sensors and Interface Board

The sensors chosen were

Sparkfun 9DOF sensor stick

o ADXL345 (accelerometer)
o HMC5843 (compass, currently unused)
o ITG-3200 (gyroscope)
Sparkfun BMP085 barometer board

The accelerometer, compass, and gyroscope are for detecting orientation and the barometer is for
detecting altitude. All the sensors communicate using I2C at 3.3V and the Pandaboard has 1.8V I2C. The
motor controllers want a 5V logic signal for PWM.
The interface board is fairly simple, it just has connectors for the Pandaboard and the ESC cables, logic
level converters for the sensors and ESCs, a linear regulator to supply power to the sensors and the
sensors themselves, of course. Despite this I ran into a few issues, the logic converter was unable to
drive the PWM signals over the cables. Also there were some problems with higher speed I2C being
unreliable. The first problem was fixed by soldering in sparkfun level converters rather than the TI
converters I used. The second one was fixed for the moment by lowering the speed of the I2C, the
problem with this being that it slows down the control loop.

The quadcopter currently runs Arch Linux. I chose this Linux distribution since it is well supported and up
to date. Ideally, though, the quadcopter would use a much more stripped down version of Linux as there
are plenty of unnecessary startup services that make booting take longer.
The purpose of Linux on the quadcopter is to handle communication with the control computer. Linux
runs a program called hostapd which allows it to act as a wireless access point that the control computer
can connect to. There is a server written in Python that accepts connections from the client running on
the control computer. Python was chosen for this part since it allowed the communication software to
be written much more rapidly and having Linux running on the quadcopter allowed for this flexibility.
I compiled my own kernel as I needed to write a kernel module and having a self-compiled kernel made
this much easier. This also allowed me to disable access from linux to the peripherals used by the
control program running on the M3.
A final note about the configuration for my Linux configuration is that I set aside 32MB of memory for
use by the M3 core. This is configured in the u-boot script which is included with the source code. While
it is possible to dynamically set aside memory in Linux it would be more complicated and any memory

savings from allocating dynamically would be insignificant given that the Pandaboard has 1 GB of

Kernel Module
A kernel module was needed to allow the server program running in userspace to talk to the real-time
stabilization/control program running directly on the M3 core. The userspace interface used two device
nodes. The first, /dev/quadcopter-firmware was for loading the firmware for the M3 core into the
proper location in memory. This is accomplished by writing to the device just like you would a regular
file (except you cant seek.) Reading from this device returned debugging information from the M3 core.
The second device is /dev/quadcopter-ctrl which is used for actually controlling the quadcopter. It can
be read and written to like a regular file as well. Ioctls can be used to enable and disable the M3 core.
Actual communication was implemented using three ring buffers. Ring buffers were chosen because
they provide simple lockless communication between the M3 and Linux running on the A9 cores. One
ring buffer is for sending control data to the M3 core, a second is for receiving control data. The third
buffer is for receiving debugging data from the M3 core which is outputted from the quadcopterfirmware device.
To start the M3 cores the MMU for the M3 cores is first enabled and programmed. Then the M3 core is
brought out of reset where it starts executing the program that was previously loaded.

Control Program
The heart of the quadcopter software is the control program which runs directly on the M3 core. This
program handles receiving data from the sensors. Processing the sensor data into an orientation and
then using that for PID. The value from the PID, as well as the desired throttle, is then sent out to the
motors as a PWM signal.
It then uses a quaternion based filter to fuse the sensor data from the accelerometer, gyroscope, and
magnetometer into an orientation quaternion. This algorithm was found in a paper which is listed in the
references section. There was an issue with getting the magnetometer readings to work which is why
the magnetometer is currently unused until the bug is fixed. The current implementation uses floating
point which is quite slow given the lack of a floating point unit on the M3 core. A future optimization
might be to use fixed point which would allow for a faster control loop.
PID is a simple control algorithm which is used to stabilize the quadcopter based on the calculated
orientation, details of how PID works can be found on Wikipedia. Currently the PID implementation is
fairly basic and doesnt currently account for integral windup. Integral control has so far been
unnecessary so that limitation hasnt been a problem.
The Pandaboard has built-in PWM but it is not accessible from the expansion port. This was not a
problem as PWM was easily implemented using several of the Pandaboards general purpose timers. In
the interrupt service routine the code toggles a GPIO output to provide PWM. This provides

approximately 16bit PWM. There are only four general purpose timers hooked up to interrupt lines on
the M3. This is not a problem for a quadcopter but could pose an issue with a Pandaboard based
helicopter with more than four rotors. There is a fifth time which is used for systick but this timer is not
suitable for PWM and is also used to time the control loop.

Control Server/Client
The client and server framework code was kindly provided by George Karavaev. The client and server
communicate over the network using TCP. The specifics of the protocol used to communicate are
outside the bounds of this report. On the client side the program takes input using pygame from a game
controller and scales the value to be appropriate to control the quadcopter. The client also reads from a
file called constants.txt, this file contains values for tuning the quadcopter in the following order:
Beta (lower value means gyroscope data favored more, higher value gyroscope values more)
Zeta (currently unused, used to control how much magnetometer data influences orientation)
Pitch Kp (pitch proportional constant)
Pitch Ki (pitch integral constant)
Pitch Kd (pitch derivative constant)
Roll Kp
Roll Ki
Roll Kd
Yaw Kp
Yaw Ki
Yaw Kd
The server basically just passes along the commands it receives to the control program running on the
M3 core.

The quadcopter currently doesnt fly due to the aforementioned issue with a broken ESC. Otherwise,
other than a few more bugs that likely exist and maybe some tweaks to the values, the quadcopter
should be capable of flight. Tests have been done to make sure it can generate enough thrust to lift
The next step I will take will be, of course, making sure the quadcopter can actually fly. I will then look
into mounting a camera to the quadcopter and transmitting back video. I would also like to look into
being able to control the quadcopter from a longer range, as wi-fi will likely be somewhat limited in
Another feature that would be very useful is a battery monitor, since Lithium Polymer batteries are
easily damaged if they are drained too far. This was in my original design for the sensor board but was
removed due to lack of time.

Despite the current inability to fly I would still call the project largely a success. Most of the difficult
parts work and theoretically the only reason it doesnt fly lies with a part that I didnt make myself.