autopilot: Do it yourself UAV

1.2: Can I use it with my model helicopter?
Sort of. With the latest release you can use the Rev 2.2 PCB with a Linux iPAQ and 802.11 card for data logging.

1.3: Will it work with my airplane?
The IMU boards will work in just about anything, but flying a fixed wing aircraft on a tether might be difficult.

1.4: It just crashed my helicopter!
Sorry, but the software and hardware have no warranties. If it breaks, you get to keep both pieces. Please submit a bug report and a description of what went wrong so that we can fix the problem. Better yet, patch the code and send us a diff.

1.5: I'm a helicopter pilot. Can I help?
Yes! We need competent pilots to help fly the prototypes while the software is debugged and tuned. This involves being able to let the computer handle individual axes of control, while maintaining a stable hover in the other axes. It also requires the ability to recover from potentially bad attitudes quickly.

1.6: I'm a math geek. How can I help?
We need help with Kalman filters, INS mechanization and software control laws.

1.7: I'm a GUI designer. Anything for me to do?
Does it look like I know anything about user interfaces? Please help out with the ground station interface, the website and documentation.

1.8: Won't this just help the terrorists?
No. Please stop asking. They could go buy complete autopilots and UAVs. Why would they bother building their own?

2: Inertial sensing in general

2.1: Why gyros + accelerometers + GPS + magnetometer + sonar?
It is possible to do a stability augmentation system with just the two gyros and two accelerometers (as we have done), but for control of all axes (attitude, altitude and position), more sensors are required. The error in a pure inertial position estimate is huge over time, but fairly good for short term (less than one second) solutions. The GPS position is reasonable and DGPS is fairly good, but the update frequency is very slow (1 Hz) and high-latency (> 1 second). Using both of these together allows for a better solution than either alone.

2.2: Do I need three axes for the accelerometers?
It depends what you want to do. For small angles, you can estimate attitude with the simple equation:

	Pitch angle =  asin( -accel_y / g )
	Roll angle  = -asin( -accel_x / g )

However, this will introduce significant errors for angles larger than a few degrees and can not distinguish upside down from right side up. Aggressive aerobatics would not work here.

2.3: Do I need three axes for the magnetometers?
Again, it depends. The magnetic deviation caused by dip errors grows very rapidly. The exact amount depends on the latitude as well, so it can not easily be compensated. A three axis magnetometer can work in any orientation.

2.4: How do the accelerometers work?
The ADXL202 units that we're using are like minature pendulums. There is probably an app-note.

2.5: How do angular rate gyros work?
The Tokin gyros are a Piezo capacitive thingy. There is probably a better description somewhere else.

2.6: What about magnetometers?
The traditional magnetometer is a coil and has an induced charge from the earth's magnetic field. I'm not really sure.

2.7: Can I deduce attitude from magnetometers?
No. Aaron wrote a better answer in the autopilot-devel archives that should be included here.

2.8: Why the rate limitations?
The angular rate sensors that we're using are limited to +/- 90 degrees per second. We've amplified them so that we can sense +/- 30 degrees per second very accurately, which should be fine for the pitch and roll axes during a stable hover. Forward flight should also not experience dynamics much faster than that. The yaw gyro may, so it should have its own scale factor.

3: Kalman filtering

3.1: What does the Kalman filter do?
The Kalman filter produces an optimal (H2) estimate of the system state based on the different sensor inputs. It uses a user-defined noise estimate matrix that allows tuning for different sensor process noise levels, as well as a "trust factor" that defines how much faith the estimate should place in each of the sensors. It also builds a run-time covariance matrix that does something (help!).

3.2: How does it compare to the complimentary filter?
Aaron wrote something about this in the autopilot-devel archives that should be included here.

3.3: What is the computational complexity of the filter?
It depends on the size of the system being estimated. For an N state system with M inputs, the filter requires:

	NxM transpose
	MxN * NxN * NxM multiplication
	MxM addition
	MxM inverse
	NxN * NxM * M*M
	M additions
	NxM * MxN * NxN multiplication
	NxN addition

The covariance update portion requires:

	Two NxN * NxN multiplications
	NxN transpose
	NxN addition

This is in addition to the system specific setup required to produce the state vectors and matrices for the filter. In the case of the AHRS, this involves trigonometric operations on the accelerometer readings and matrix rotations of the compass heading.

With some amount of optimization techniques, it is possible to do this at 25 Hz on an 8 bit microcontroller running at 8 Mhz. Incredibly, this was also running a PPM radio decoder, ten servo drivers and a dual axis PID controller at the same time. Believe it or not, here is the source code.

4: Helicopter flying

4.1: Are they hard to fly?
Yes. While an autopilot might eventually make it possible to fly without any of the skills required, the testing effort requires very talented pilots. You can learn much of the technique with our simulator or any of the comercial ones.

4.2: What are the controls?
In a traditional helicopter, the pilot uses both hands and both feet to control the aircraft. The models substitute two sticks for the controls, but they function the same. One stick controls the cyclic, which tilts the main rotor disk by changing the blade pitch of individual blades as they rotate and thereby changes the thrust angle of the main rotor. One axis on the other stick controls the anti-torque rotor (commonly called the "tail rotor"). This rotor counteracts the torque generated by the engine and main rotor; without it the helicopter body would rotate opposite the direction of the main rotor. This function is served by the anti-torque pedals in a full-size aircraft. The other axis of that stick controls the blade pitch of all of the blades in the main rotor together, as well as the engine throttle. This is called the collective, since it operates on the main rotor blades collectively.

4.3: Gas vs glow vs electric
On the plus side, gas engines are very fuel efficient and don't produce any exhaust smoke. Glow engines are more powerful per cc and cheaper. Electric doesn't have any messy exhaust and are typically very smooth.

On the negative side, gas engines are more expensive to buy and difficult to tune smoothly. Glow engines produce massive amounts of smoke and require expensive fuel. Electrics can't carry any payload and have very short flight times between recharges.

4.4: Noise reduction
Better exhaust, slower head speed, more blades. Other ideas?

4.5: Payload improvement
Larger engine, higher head speed, more blades, flat bottomed blades.

5: Servos

5.1: Servo overview
This is not a review of any particular servo make or model. Instead it is about the technical interfacing details.

5.2: Parallel driver
Our Rev 1.0 board used eight digital output lines from the microcontroller to drive eight servos. A timer interrupt switched the lines on and off as needed. This worked fairly well, as long as the interrupt was serviced promptly and as long as no more servos were required. Any latency in servicing the interrupt would cause servo jitter. It also used an entire eight bit port, which was "expensive" in MCU resources.

5.3: Decade counter driver
The 2.x boards use a 4017 decade counter to drive the servos instead. The clock signal for the 4017 is generated by the timer output compare hardware, so the interupt servicing is no longer "real time". The MCU clocks the 4017 and eventually we get around to updating the timer for the next pulse. We always have at least 1 ms to do this, so this constraint is easily met. Additionally, it only uses two IO lines for the ten servos -- one for the clock and one for reset.

5.4: How many bits of resolution?
The servo pulse width is between 1 ms and 2 ms. The data portion of the pulse is therefor 1 ms, so an 8 Mhz clock gives 8000 possible positions. That is roughly 13 bits of resolution. Obviously, it will scale with the clock speed.

5.5: Driving digital servos
I don't know yet.

6: Radios

6.1: Radio overview
This is not a review of any particular radio make or model. Instead it is about the technical interfacing details for different radio formats. There is some info on hacking specific receivers, but this is not necesarily an endorsement of those products.

6.2: PPM or PCM?

6.3: Decoding PPM

6.4: Decoding PCM

6.5: Hacking the Hitec RCD5000