+ heli-sim
+ Roadmap
+ Scenarios
+ Download
+ Credits
+ Links
Mailing list:
+ Archives
+ Subscribe
+ Admin
+ PCB v2
+ PCB v1
+ Systems
+ Sensors
+ Field support
+ Prototypes
+ Summary
+ Bugs
+ Tasks
+ Stats
+ Non-SSL
<Blurry image of the first prototype in flight>


The realtime system has to process data from the many sensors on the UAV. These are grouped into four major classes of sensors, with multiple input methods.


Input types:

Of these, the attitude is the most important. I would rank the priorities for the realtime and nav systems as:

  • Keep it under control
  • Ensure the systems are safe
  • Go where we want
  • Perform the mission

So far, all of the effort has been on the attitude output. Once we have that working, progressing through the other groups should be quite easy.


Internally, the realtime system is reading the acceleration rates from the gyros (or the attitude reference) and performing rate integration to produce the attitude. The three (roll, pitch and heading) values are output for use by the nav system or EFIS. With the Gyration MG100 we sample the Vg1, Vg2 analog inputs compute the acceleration values. With the ADXL202 accelerometer, we can either sample voltages or use the PWM inputs similar to the hobby-gyros. We receive the heading information from the GPS, but it only works if we are moving and has a low sampling rate. A compass or yaw gyro would help here.

Full source code for the two-axis strapdown IMU is available. The algorithms implemented right now are very simple; we need expertise in Kalman filters and avionics to better process the available data.

Frequency Type Range Units
MG100 pitch rate 60 Hz Analog -128 .. 127 K deg/sec^2
MG100 roll rate 60 Hz Analog -128 .. 127 K deg/sec^2
ADXL202 pitch angle 50 Hz Duty cycle -2048 .. 2048 mg
ADXL202 roll angle 50 Hz Duty cycle -2048 .. 2048 mg
Heading 1 Hz RS-232 0 .. 359 deg

Output every 1/8th of a second: R=xxxx P=xxxx H=xxxx

Engine stats

N1 and N2 are easily sensed from magnets planted in the engine cooling fan and rotor main gear. The HAL effect sensor feeds into the realtime system's interrupt which counts the pulses and computes the RPM. If these numbers are desired, INT0 and INT1 should be enabled by calling pulse_init() in pulse.c.

N1 refers to the engine RPM, while N2 is the rotor RPM. For a two-stroke .60 sized engine, N1 will max out at 28,000 RPM, while for a model helicopter N2 maxes 2,000 RPM.

The real-time system can adjust the throttle to maintain a constant N1, regardless of pitch changes due to collective inputs. This makes for smooth controls, even though the 2-stroke engine has "instant" power available, unlike a turbine. This software governor should update once per second.

The accuracy requirements are fairly limited. At high N1 RPM we can miss 5 pulses a second and still be within 1%. N2 is more important since it is so much slower (1:12), but we can still miss a few and be within 5%. At low RPM we're probably on the ground anyway. Additionally, by maintaining a weighted average we can filter out a few pulses misses.

It would also be good to have a "low rotor RPM" alarm if the rotor drops below 1,000 RPM. If the engine is turning at less than 8,000 RPM we want to indicate an alternator failure. At less than 1,000 RPM we should indicate engine failure.

We have pictures of the construction and installation of the N1 tach.

CHT (Cylinder head temp) and EGT (exhaust gas temp) thermocouples are read with the onboard A->D. These are not necessary for flight, but can help with tuning the mixture adjustments. Expected values are unknown at this time, but below 150 C we do not care.

We will need a fuel tank sender to read the fuel level; this will have to wait. The need is obvious...

Frequency Type Range Units
N1 tach 500 Hz Pulse counting 0 .. 30,000 RPM
N2 tach 50 Hz Pulse counting 0 .. 3,000 RPM
CHT 1 Hz Analog 40 .. 300 C
EGT 1 Hz Analog 40 .. 300 C
Fuel 1 Hz Analog 0 .. 100 %
Volts 1 Hz Analog 0 .. 4.8 V

Output every 1/2 second: N=xxxx T=xxxx C=xxxx E=xxxx V=xxxx F=xxxx


Lattitude and Longitude are read from the NMEA data stream from the GPS chipset. We can also get altitude and heading, but both of these are fairly useless for hovering. At low altitude AGL hovers, we use a sonar altimeter (such as the Polaroid range finder) to maintain a stable altitude. This unit feeds pulses into the realtime system in a manner similar to the engine tachs. For high altitude hovers we can use the GPS altitude since a few meter error won't be as obvious.

Should we output the velocity or allow the nav system to compute it from the values? I'm not sure who should do this.

Frequency Type Range Units
Lat/Long 1 Hz RS-232 -180.000 .. 180.000 deg
Altitude (AGL) 1 Hz Pulse counting 0 .. 10 m
Altitude (MSL) 1 Hz RS-232 0 ... 8,000 m

Output every 1 second: X=xxxx Y=xxxx Z=xxxx


This will vary with the payload, obviously. Cameras might report the number of frames remaining, the focal depth, etc. Crop seeding operations would report the remining quantity in the hoppers, etc.

Output every 1 second: ???

Output summary

C=xxxx		CHT
E=xxxx		EGT
F=xxxx		Fuel level
H=xxxx		Heading
P=xxxx		Pitch
N=xxxx		Engine RPM (N1)
R=xxxx		Roll
T=xxxx		Rotor RPM (N2)
V=xxxx		Voltage
X=xxxx		Longitude
Y=xxxx		Lattitude
Z=xxxx		Altitude

Other possibilities:

x=xxxx		Longitude velocity
y=xxxx		Lattitude velocity
z=xxxx		Rate-of-climb

x,y,z acceleration?
r,p,h velocity?
r,p,h acceleration?

Input types

Analog voltage

These inputs use the onboard A->D feature of the AVR microcontrollers. It has eight analog inputs, but can only sample one at a time. A three-bit mux selects which one is currently being sampled. The chip can generate an interrupt when the sampling is complete, or set a flag in the ISR.

adc.c version 1.7 demonstrates the interrupt driven method. The current version of adc.c uses a polled method due to interrupt overhead disrupting the PWM sampling results.

Currently, the rate gyro and fuel/volts sensors use the analog inputs.

Pulse Width Modulated

The safety pilot receiver, the hobby gyros and the ADXL202 all output data in a pulse width modulated format. The width of the pulse indicates the receiver command or the force on the gyro, while the ratio of pulse width to frame rate measures the forces on the accelerometer. Accurate measurement of these values is essential to maintaining attitude or sampling receiver command without jitter.

The accelerometer code is currently the only PWM input in use. It produces output every 10 ms or so, determined by an RC timer on the evaluation board. More details on the ADXL202 are available. The hobby gyros have been replaced with the MG100 two-axis rate gyro.

Pulse Counting

Pulse counting uses the edge-triggered interrupts on the AVR. The rate of interrupts varies between 500 Hz for N1 and 10 Hz for N2. The N1/N2 tachs are the only pulse counting instrumentation currently installed. The Polaroid range finder that we might use for altitude (AGL) will also use pulse counting, but we have not acquired one yet.


The AVR Mega103 microcontroller has one hardware UART. It is currently used for communication with the NAV system in an interrupt driven fashion. Source code is available. We would like to have two serial ports, one for the NAV computer and one for the GPS, but that does not appear to be easy to do right now.

Digital inputs

Unfortunately we have filled all the IO ports on the smaller Mega AVR and do not have room for any multi-bit digital IO. It would be nice to have the engine tachs feed into a counter and just sample the counter periodically, but there are not enough lines to make that happen.

Autopilot Logo SourceForge HTML 4.0!
$Id: sensors.html,v 1.27 2002/08/05 03:44:39 tramm Exp $