Gyros

With Dr. Rogers' technique for deriving angle of attack from coefficient of pressure data, conventional flight test techniques are used--what we tend to think of as "GPS speed runs" in the EAB world. I've described this "hard tuning" method of calibration in past blogs, but the reader's digest version is to fly GPS triangles or horseshoes at varying power settings to determine coefficient of lift real-time, and then apply the math to derive absolute angle of attack. This method does not require pitch; but does require accurate flight test performance, data download and post-flight computation to develop a good aircraft curve. This amount of flight test and and analysis work is likely more than the average pilot wants to undertake just to have an accurate airspeed and/or AOA indication. Pilots want a system they can bolt in, turn on, adjust the volume and go.

We've developed an alternative technique for deriving geometric AOA from pitch during 1G, level, unacellerated flight and validated this technique with flight test. The technique for deriving the alpha curve is very similar to that used to derive upwash error. My last blog post about upwash error and our miscalibrated air data vanes spells some of that out. But the technique is fairly intuitive: if the airplane is in level flight (i.e., flight path angle is zero) and at a steady speed, geometric angle of attack is equal to pitch. Now, Dr Rogers would be all over me if I was to say pitch is a surrogate for angle of attack; but under this singular condition, it is. We can also stretch things a bit further if we know flight path angle. If you have an EFIS, it may have a flight path maker. At 1G, the angular difference between the flight path marker and pitch is, wait for it, angle of attack. As a matter of fact, in the Boeing that I fly at work, that's the only way I can estimate AOA in the right seat (we don't have the optional AOA display on the primary flight display, we also didn't order the electric windows ;). We are currently working on developing a "calibration wizard" that the pilot will use in flight to utilize this capability to generate an accurate curve. Set points for actual tones will still have to be manually input--there is no free lunch.

So far in our project, we have been calculating AOA from the pressure difference between two sensors. There is another way to calculate AOA from inertial data that uses the concept I described in the previous paragraph: AOA is (part) of the difference between where the airplane is pointed (pitch) and where it's going (flight path angle). When AOA is computed in this manner it is referred to as "derived" alpha (i.e., derived from inertial data). There is lots of good USAF and NASA math that can be applied in software to derive AOA from IRU data.

The V3 has an IRU in addition to pressure sensors, thus there is the potential to measure AOA from coefficient of pressure AND IRU data simultaneously. In certain flight regimes (say high alpha just prior to the stall when there is significant separation on the upper surface of the wing and stream lines under the wing are more compressed), IRU data may be more accurate than coefficient of pressure data. And, of course, the opposite may be true as well. We won't know until we test it. Figure 3 shows an example of why we want to take a look at combining the two capabilities. This is a plot of a level, 1G stall. Note the delta between the pressure derived solution and the corrected boom. The concept is to use derived AOA to help marry up the plots with even more precision:

Figure 1. Pressure derived alpha vs corrected boom plot.

We also have one additional challenge: our self-imposed (OK, Van's idea, not ours) requirement to NOT use GPS with the system in an effort to keep it simple. This means that we need to milk some pretty significant performance from the 10 Buck Chuck, as we affectionately call our 10 dollar inertial reference chip. As I said, the USAF has done the math and we can incorporate it into our Arduino software: AFwdCorr=9.80665 * getAccelForAxis(forwardGloadAxis) * cos(installPitchRad) * cos(installYawRad) + 9.80665 * getAccelForAxis(lateralGloadAxis) * (sin(installRollRad) * sin(installPitchRad) * cos(installYawRad) - sin(installYawRad) * cos(installRollRad)) + 9.80665 * getAccelForAxis(verticalGloadAxis) * ( cos(installYawRad) * cos(installRollRad) * sin(installPitchRad)+sin(installYaw).* sin(installRoll)) + ((pow(YawRateRad,2) + pow(PitchRateRad,2) * installX - (RollRateRad * PitchRateRad-yawRateDiff) * installY) - (RollRateRad * YawRateRad + pitchRateDiff) * installZ. Piece of cake (insert perplexed stick monkey emoji here), right?

Up until now, we've been using the Dynon AHRS solution for all of our flight test work with the RV-4. Being new to the avionics development world, we naively assumed that an electronic flight instrumentation system has to be tight, right? All we needed to do was tap into the serial data stream and integrate those data with our V3 indigenous data and voila, instant flight test solution, no? Turns out the answer is "no." Modern flight electronics are a godsend for those of us that recall using a vacuum driven attitude indicator and a fixed card ADF to fly an instrument approach at night in the weather. I don't ever want to repeat that experience. Current systems (that only get better with each iteration) do a remarkable job when combined with the 1/2 Hz brain capacity of the human aircraft operator. Where they fall short is a reference gyro source at 50Hz. Definitely good enough to drive an autopilot at that speed (that's why auto pilots work so well--they think a lot faster than the primate manipulating the stick (or yoke) and throttles); but Figures 2 and 3 show the problem. Figure 2 is a plot of the Dynon AHRS pitch solution and the 10 Buck Chuck solution with the airplane in the hangar, on jacks with the fuselage reference line set to zero degrees (+/- 0.05 deg). Figure 3 is a similar plot for roll.

Figure 2. AHRS pitch error.

Figure 3. AHRS roll error.

Figures 2 and 3 make it evident that if our objective is to measure AOA within a 1/10th of a degree, we'll need a more accurate AHRS solution than provided by the Dynon EFIS. The good news is the stability of the 10 Buck Chuck. The difference between zero and the V3 IRU is installation error and is compensated for during the sensor calibration sequence. The 10 Buck Chuck appears to have the capability to allow our 1/10th degree resolution.

Flight Test Solution

It's pretty obvious that what we need is an AHRS solution that's accurate to less than .05 degree in all axis so we can try to baseline to our desired .1 performance goal. The good news is that there is such a beast, designed for this very purpose. VectorNav systems makes an outstanding accurate, temperature compensated reference gyro that is really small and relatively easy to integrate with the V3 for flight test work. We chose the most accurate, rugged system, the VN-300. This is an expensive piece of kit; but we were fortunate to acquire a used one from a group of European experimenters we met up at Oshkosh. The tiny gyro is accurate to within .03 degrees in all axis. By incorporating the VN-300 data with V3 data we will have an extremely accurate AHRS solution for flight test as well as a reference source to "train" the 10 Buck Chuck for auto calibration utility as well as derived . Once we've integrated it into the RV-4, we'll have an excellent capacity to compare V3 performance to a (now) properly calibrated air data test boom and reference gyro solution. Figure 4 is picture of the VN-100. This version is the little brother of the -300, not quite as capable or accurate; but an excellent AHRS. Lenny is installing one in his Zlin to help with V3 integration in that airplane.

Figure 4. VN-100 Reference Gyro.