After much reading and re-reading, I think that I’m finally starting to understand what’s necessary in order to build a UAV.
First, let’s talk about a regular RC airplane.
You have a transmitter in your hands that has some number of channels (for a regular ol’ airplane, this number is usually 4; throttle, elevator, ailerons, rudder; or power, pitch, roll, and yaw).
The plane has a receiver, which consists of a black box with an antenna coming out one end, and a bunch of 3-wire connectors coming out the other; these correspond to each of the channels coming from the transmitter (and you can sometimes buy them together, so they have matching numbers of channels).
Of the 4 main channels, 3 of them are “control surfaces”, meaning that they’re low-power, to-and-fro movements, and are controlled by servos. The other one (throttle) is a high-power, fast-motor-spinning sort of thing, and connects instead to an ESC (electronic speed control).
The ESC is another black box, and you’ll have one per motor. Its connections are a 3-wire connector (which are all power/gnd/signal, including the servo ones), 2 high-voltage wires that go to the battery, and 3 high-voltage wires that go to the motor (which is apparently because it runs on AC, which the ESC manufactures).
There’s a motor which spins real fast, and a propeller, which is either a “push” type (for props on the rear of the plane), or a “standard” type (for props on the front of the plane. If you were building a quadcopter, you would want a pair of each type, and one pair would run CW while the other ran CCW. You would also have 4 motors and 4 ESCs but probably no servos.
If you have a gas plane, then you end up with a servo for the throttle, too, and probably a lot of other complication that I’m not going into because frankly I could care less. Ditto helicopters with either fixed blade pitch or collective pitch, which requires 5 channels, but I haven’t deciphered what they are, and probably won’t, for now.
OK, so you have 4 channels that need to be controlled if you are going to drive the thing, whether you’re driving it via transmitter or computer.
So, the “computer”, or IMU (inertial management unit), has to, at the very least, perform the control functions for these 4 channels. You will not be surprised to learn that, on the ArduPilot, for instance, there are 2 sets of 3×8 pin headers, one for “input” (which you hook to the transmitter), and one for “output” (which you hook to the motor or servos). This allows you to either “pass through” signals from the ground, or to modify (or override) them based on “the stuff in between”. Oh, and of course, you want to be able to switch from IMU to ground control, so you need a 5th channel, which is hooked to a toggle switch on the transmitter (big, red, and marked “Human Override”).
What’s “in between”? Well, at the very least, some sort of CPU that can take inputs and push outputs (eg an Arduino), and in order for it to intelligently make decisions about what to do with the outputs in order to achieve its goal (level flight, waypoint navigation, whatever), it needs some kind of telemetry, which it gets in the form of a sensor array. Among useful sensors:
– accelerometer – which measures attitude angle in X, Y, and Z
– gyro – which measures rate of change of attitude in X, Y, and Z
– magnetometer (optional) – which measures compass heading (in multiple dimensions? why?)
– GPS (optional) – which measures position over ground, and can also measure altitude sometimes, and also provides a stable time base, should one need it
– pressure sensor (optional) – airspeed; only useful in airplanes
– sonar (optional) – height above ground; mostly useful in quadcopters
Everything except the accelerometer and gyro are “nice to have”, although I believe that an accelerometer can get confused when banking and pulling G’s, which makes a magnetometer a good early upgrade.
So, you grab input from all the sensors, parse it into position/attitude/velocity, then adjust the control surfaces and motors to suit the mission. I can imagine at least 3 modes:
– all human: pass through all flight control signals from the ground, unmolested
– power assist: maintain level flight if possible, but allow input from the ground
– all computer: ignore flight control signals from the ground (other than the Human Override channel)
One imagines being able to make the thing take off and land by itself, or return to sender if something goes wrong, or… that’s all just different missions.
If you want a peek into the IMU’s thought process, then in addition to simply reading the sensor data and making flight control decisions with it, the IMU also needs to transmit this telemetry data to the ground station (which, at this point, needs to consist of more than just a transmitter.. right? I assume there are xmitters that have so many channels and such cool screens that they can show the data onboard, but let’s assume a laptop for now). There are ways to do this, but let’s assume that XBee will be used. So, an XBee onboard the IMU, and one connected to the laptop, with a constant stream of serial telemetry data coming from the plane. This can either be used to monitor what the IMU is doing, or it can be used for the human to drive the plane “FPV” (first-person-view), using the telemetry as a HUD.
The plane can also have onboard some kind of payload, like a camera. If the camera is fixed to the heading of the plane, it can be used for FPV. Then it just needs to wirelessly transmit its output. That’s probably on a different channel than XBee, which would quickly saturate a 115200 baud connection with video. Alternately, the camera can be attached to a PTZ (pan-tilt-zoom) mount, consisting of at least 2 servos (and one zoom control, however that’s done), which would require 2 or 3 more RC channels. One could imagine a transmitter whose sticks do flight control if in human mode, or camera control if in UAV mode. Hmm.
Once a laptop is added to the equation, one assumes that you could ditch the transmitter, and provide flight control input via a gamepad/joystick. Then you’d be all-XBee on the ground transmission side, and you could even ditch the receiver and all the “input” side stuff on the plane; you’d just have an Arduino with an XBee that was controlling a bunch of servos. Wonder if the datastream is fast enough to just fly an RC plane around like that. Probably how the “drive with your iPhone” planes do it. Hmm. That’s a pretty easy project to breadboard; just hook up some servos to the Arduino, and hook up an XBee, and create a protocol for uplink (flight control) and downlink (telemetry)…
You would still need:
– ESC
– motor
– prop
– servos
– battery
but you would eliminate:
– transmitter
– receiver
and you would additionally need:
– laptop
– XBees
– Arduino
– gamepad
hmm…
Vendors:
Sparkfun – sells 6DOF (just gyros and accelerometers) and 9DOF (+magnetometer) boards
DIY Drones – sells APM (ArduPilotMega) v1 (which requires 2 boards, a APM and a Oilpan IMU) and v2 (all on one board)
uDrones – sells APM v1’s and has some nice “standard sets” for both planes and quads.