UAV / Quadcopter roundup

This post is intended to be a living document containing the information that I have about RC, planes, helicopters, quadcopters, and UAV/IMU/FPV.

Discussion on LinkedIn group about UAV

Arduino PID library

IMU tutorial

HobbyKing quadcopter frame has a good set of accessories.

Actual parts list for a tricopter! Looks like the DT750 motors are really the right stuff, along with the 18A plush ESCs.

homebrew quadcopter controller (USB Joystick and Xbee)

Cheap quadcopter from Australia. Does not UAV out of the box, but has a ‘328 brain.

A whole blog about RC and Arduino. Aimed at cars, but I assume you can
pull the relevant info out.

UPenn quads are doing some crazy stuff.

Plastic framed quad

cheap quad

Arduino to RC bridge

Very Small Form Factor Arduino

cam + helicopter

Olympia Quadcopter

Good documentation on yet another DIY IMU
Below are some notes I culled from an email thread with a person who was building a quadcopter using USB joystick/XBee/Arduino and a 6DOF IMU.

I’m decent with a soldering iron, but I’m mostly a hack when it comes
to EE. I put stuff together based on a “try it and if it doesn’t
smoke, keep going” methodology, and am usually surprised when my
circuits do what I wanted (although my major problem at the moment is
battery life — I make circuits that need wall warts).

The good news about coding is this: If you can write Arduino code, you
can write C++, Python, or Java. They’re all variations on a theme.

The software architecture that the servo guy used in the article you
sent is a good one; think about having one small program to deal with
the XBee communications, one small program to deal with the joystick,
and then one to tie them together, turning inputs from the stick into
serial communication.

Is the video being transmitted over Xbee also, or is there a separate
wireless transmission for that?

You have some code written already — is that running on the onboard
IMU on the quad (written “in Arduino” or some such), or on the PC? Is
it in C++?

I’m no PID expert, but my understanding is as follows:
Proportional = “present” error
Integral = “accumulated” error
Derivative = “rate of change” of error

so. Let’s use an example. Say that you were trying to do cruise
control for a car. So you desire a particular speed. That’s the set
point. Every loop, you check the current speed. That’s the input.

To get “proportional” (or “current”), you just subtract current speed
from desired speed.
To get “integral”, you then add the “current” to the last integral reading.
To get “derivative”, you need to divide “current” by the amount of
time since the last reading

So “P” lets you know how far off you are.
“I” gives pressure to suppress overshooting.
“D” helps you to tune the amount of correction.

You then take these 3 inputs and add them together (probably scaling
each by a certain amount — that’s the “PID tuning” that people talk
about), and use the result to determine:

1) whether you’re above your target speed or below, and
2) how far you’re above or below.

You then adjust whatever needs to be adjusted to minimize the error,
and then you retake all your sensor readings (perhaps after some small
delay, to allow the change to take effect).

Keep doing this, and eventually, the P should tend towards desired, I
should tend towards 0, and D should tend towards 0. This is the
“balanced” point (about which you may oscillate, depending on tuning
and other factors), and anything that pushes you out of the balanced
state (going up or down a hill, for instance) should cause the P,I,
and D to apply negative feedback, to get back in balance.

For your purpose, you will probably use the output of a
gyro/accelerometer to determine whether you’re flat and level or not,
then apply more or less power to one or more of the motors in response
to the PID calculation.

I hope that’s enough to get you started on that part — despite it
being called “integral” and “derivative”, there’s no real calculus
involved, just addition, subtraction, and division. The “over time”
(“dt”) part is gained by keeping the variables from reading to
reading.

You were asking about pyserial in the other thread. The example you
found is written in Python (a very nice programming language for quick
prototyping). The basic idea is that Python has many libraries that
make your life easier. In this case, pyserial is a serial UART
library, which allows you to connect to a serial port and send/receive
data from it. Since the XBee acts like a serial port, this is how
you’d connect to the XBee. The author also talks about a pygame
module, that knows how to read joysticks, and he even has joystick
event code in one of the other blog posts. Between these two, it
sounds like you’ve got a nice basic joystick-to-XBee converter, and
then you just have to decide how the copter should respond (which
motors do what) based on which joystick inputs.

If you spend a little time with the guy’s code samples, you can
probably find one that you can just hack into place to get your XBee /
stick working together, and then you just need to figure out what to
send to the onboard IMU (which I assume is driven by an Arduino?)
based on that. Keep your protocol lightweight; something as simple as
4 bytes, each one representing a 256-step percentage of motor power
for that motor, is probably enough. If you find that you’re dropping
packets, you might want some kind of CRC or challenge-response
protocol, but to start, I think you can just send the command and deal
with lost packets “in post”.

This entry was posted in Electronics, Knowledge, Making, Technology and tagged , , . Bookmark the permalink.