Pandaboard Quadcopter

William Hahne

Abstract

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.

Hardware

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

controller.

Frame

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.

Motors/Propellers/Battery

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.

Software

Linux

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

memory.

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 quadcopter-

firmware 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.

Conclusion

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

itself.

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

range.

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.