|
|
Overview:
FAQ
heli-sim
Roadmap
Scenarios
Download
Credits
Links
|
|
Mailing list:
Archives
Subscribe
Admin
|
|
Design:
PCB v2
PCB v1
AHRS
Systems
Sensors
Field support
Prototypes
|
|
SourceForge:
Summary
Bugs
Tasks
Stats
Non-SSL
|
Sensors
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.
Groups:
- Attitude (roll, pitch, heading)
- Engine stats (N1, N2, CHT, EGT, Fuel, Voltage)
- Position (lat, long, alt)
- Payload stats
- Analog voltage
- Pulse width modulated (PWM or Duty cycle)
- Pulse counting
- RS-232
- Digital
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.
Attitude
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
Position
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
Payload
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.
RS-232
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.
