Why Do I Care About Performance under G?
Great question! I want a system that will work well right up to aircraft limits and beyond. I want to know where the aerodynamic limit is, where the G limit is, where the airspeed limit is, and whether my energy is negative or positive without having to look in the cockpit (or look through a fixed HUD—it’s in the wrong place if I’m looking over my shoulder). This is why our baseline system uses audio cuing, not visual. My ears are an under-utilized resource in the cockpit. We engineered Gen 2 to do this, so the obvious question is: how well does it work when maneuvering aggressively?
In McDonnell-Douglas (now Boeing) fighters, the AOA and OWS worked well, even when the airplane was maneuvered agressively during a dog fight. It’s neat to turn landing into a no-brainer using ONSPEED logic, but it is even more important in a 1 v 1 for an airplane with manual flight controls to help manage energy and maintain control. As with any manual flight control system, it’s always possible for the pilot to make an input so abrupt (“high gain”), that he or she can “beat the system” (or ask more than the airplane can give). We hit this limit at about 2G’s per second with our first-generation demonstration AOA system, although we never formally measured this with anything more calibrated than a G meter and a Mark One Eyeball flying 3-4G accelerated stalls. If I was aggressive enough with the pull, I could force a stall before the warning tone caught up. Thus, we figured we’d shoot for 4G per second or better capability with Gen 2.
Realistically, the pilot isn’t going to make a 4G per second control input unless you’re fighting, flying aggressive aerobatics, conducting flight test or ham-fisting the airplane with an unnecessary high-gain control input. And, depending on how big and effective the elevators or stabs are; there is a realistic limit to how fast you want to pull, if you want the airplane to keep up with you. But there is a reason to chase that performance capability: good performance during gusty and turbulent conditions. 4G’s per second translates to a gust load of 128 feet per second; which is pretty significant. If we can handle 4G’s per second in maneuvering flight, we can also handle gusty, turbulent conditions in the traffic pattern.
How do we generate objective data to quantify performance under G? Well, we can get a quick “QC” by flying some 4G stalls. Under those conditions, we can see if we get good stall warning before the nose stops tracking. It’s mostly practical to set up at maneuvering speed, roll to 110-120 of bank, and aggressively applying back stick within a second or so until stall. Between the G meter and some high-tech “thousand one, thousand two” cockpit math, I can at least determine if the system kept up with the pull. Another technique is to see how well the system performs during a 4, 5 or 6G break turn. Additionally, we can fly the airplane in the landing pattern under challenging conditions and see how well things work, and we may even accidentally stumble into wind shear as I wrote about in a previous blog. Ultimately, however, all of these various techniques are still difficult to quantify, so for that we are going to need some instrumentation…
Boom, IRU or Both?
As we pointed out in our last blog, we are currently working on integrating the IRU and it turns out when you step out of the “normal” flight regime, you are moving into mostly virgin territory…at least for us amateur types that don’t have access to any code that does the accelerometer math required. We’ve got to start that from scratch, using USAF and NASA homework; and we’re still working on it! And by “we” I mean folks on the team that can do math.
What we do have to work with at present is a calibrated air data boom. At 1G, things are pretty straight forward—you can compare the boom alpha vane reading to a known pitch source, and compute upwash error. As you may have noted in my previous post, the jury is still out on “known pitch source,” and I’m anxious to compare Lenny’s IMU algorithm when that’s ready to the recorded Dynon performance; so there we are not yet 100% confident in our upwash numbers, but we figure we are 98% there at 1G.
I arrived at the 98% confidence factor by the back door: I compared our pitch-derived performance with our physics-based curve during some single axis maneuvering flight. In the previous blog, I published two workbooks. One uses Dr. Rogers’ aero math to derive aircraft curves, and the other uses stick monkey math to derive pitch-based curves. I figure if we apply both algorithms to the same data set, and correct absolute alpha for zero lift using NACA wind tunnel data, if the numbers are close, our pitch-derived curve must be pretty tight, even though it’s based on the Dynon attitude reference. This “warm fuzzy” is plotted in Figure 1.
Figure 1 shows a series of two 3G pitch transients. Maneuvering is confined to a single axis. Note that the two V3 calculated solutions essentially overlay each other; so now we know the pitch-derived curve is accurately computing geometric AOA. We also know, anecdotally, that our Dynon pitch reference is sufficient to calculate alpha, so we’ve likely got usable upwash numbers as well; but again, we still need to confirm that with further test.
Figure 2 shows performance under sustained G. In this case, a 2G wind-up turn. The boom measured alpha is corrected for G, upwash and pitch-rate. We’re using an old NACA technique for correcting boom measured alpha for the dynamics of the turn; but, frankly, we’re not sure if we’ve actually cracked that code yet. I’ve plotted trendlines, so it’s easy to ascertain performance over time—a flat trend line is good and means parameters are fairly steady and the stick monkey is doing a reasonable job flying the maneuver. Figures 3 and 4 show similar tests at higher G.
In Figure 3, I added pitch rate to the plot. Since I’ve rotated my plane of motion to stabilize G, my recorded pitch rate effectively equals turn rate in degrees per second. In this case the airplane is maintaining 16 deg/sec in a “neutral” energy condition (thrust and drag are balanced). In Figures 2-5, note that there is some delta between V3 computed geometric alpha and corrected boom alpha. Overall, it appears we are within about a ½ degree, which isn’t bad; but the rub is we don’t have total confidence in the boom correction algorithm; so, we are still experimenting and aren’t ready to publish accuracy numbers under G. Yet. We’ll get there at our normal pace of two steps forward, one back.
Gyros Suck: Or, “what constitutes a reference pitch source?”
Back in the day when gyros did, in fact, suck (at least the vacuum pump did), they weren’t incredibly accurate. Turns out FAA requirements for attitude reference performance hasn’t actually changed, but we figured any EFIS solution has to be tight, right? If we are going to use pitch as a surrogate for AOA during 1G flight it has to be reasonably accurate. Since Dynon doesn’t publish accuracy numbers for the DY-10A EFIS that equips the RV-4, we decided to jack the airplane up to a level position longitudinally and laterally. The fuselage reference line is defined by the canopy rails, so jacking the airplane is fairly straight forward using an electronic level for reference. The level has an accuracy of + or – 0.1 degree when properly calibrated; so not perfect but the best we can do with equipment at hand.
Once the airplane was leveled in an enclosed hangar, we turned on the EFIS and recorded data on the V2 at 50Hz for 45-60 minutes. We conducted a total of four tests and the results are tabulated in Figure 5. Figure 6 shows a plot of EFIS pitch over time during test 4. Installation error is the difference between recorded EFIS pitch and the fuselage reference line. As you can see in Figure 6, the gyro tends to drift over time, so the best we can do is apply an average or median correction factor. For pure test purposes, it would be nice to have a more accurate pitch reference; but there may be some benefit to working with a more “real world” solution. What’s interesting in Figure 6 is how well the IRU chip in the V2 does. It’s accurate to within 1/10 of a degree and measures to the 1/100th of a degree. ‘Course, that’s at 1G, zero knots, on jacks with zero point zero vibration. Add vibration and things get more challenging. I'm not sure what it's called, so in standard stick monkey fashion I've dubbed it the "shake and bake" machine, but Figure 7 shows it vibrating a V3 box for bench testing. Apparently, whatever it does, it does it with gusto, says so right on the label. Probably makes a wicked up of espresso too.
Ultimately, that little IRU chip has to work well enough in pitch and roll to allow us to automate the calibration process. Turns out to have a tight AHRS solution, either a GPS or magnometer signal (or both) are required. This provides a 9 or 12 degree of freedom solution. Unfortunately, we ain’t got that kinda’ hardware in the V3 (and we are already at our self-imposed 250 dollar cheap shit total parts cost limit); so, we have to accommodate vibration effects and use equations of motion with the six degrees of freedom the IRU measures. It's going to take a bit more than high school math and some good coding to pull this off. Currently, we are sorting out the Kalman filtering required to help deal with vibration. The top of the radio stack where the V2 box is bolted (industrial velcro'd actually) into the RV-4 is anything but smooth when the Lycoming O-320 is thrashing the two-blade Catto prop. We had to bring in the big guns: the HAL 9000 unit (essentially a small Linux super-computer shown in Figure 8) to help us out with the ginormous CPU we need to drive MatLab to work a solution.
Conceptually, I can follow along, but that’s about it. I'm counting on the smart folks on the team to sort this out. Here's the 30K' summary as I currently understand it in my simple stick actuator brain: The CPU is now talking to the IRU (“polling”) at 253Hz. This increased load on the computer along with the requirement to drive the energy display meant we had to run a stress test with the V2/3 box processing the pressure sensors (basic ONSPEED audio functionality), boom and EFIS data and driving the energy display. The good news is the high data rate code works AND no issues locking up the box; so now we’re down to filtering, 6-DOF trig and supercomputing. What could go wrong? Hope Lenny’s neighbors don’t mind when the power grid browns out…
We Promise Not to Fight off the Rescuers
As always, we welcome discussion, questions, bullshit flags and any help from the community! If it's not apparent reading through some of our blogs, we are work in progress and we are venturing into areas that require some original solutions (or at least application of a solid existing solution that we're not aware of); so we always welcome input and participation. We wish some of the big avionics manufacturers that have forgotten more about this stuff than we know would show an interest, but the phone ain't ringing off the hook. So, on we press. This stuff worked in fighters and it'll work just as well in a light plane. It's the most caveman simple way I know to convey energy info to the pilot.
There is a lot we don't know and a lot we still need to learn. Hopefully by working in a fish bowl and demonstrating what's in the art of the doable, we can stimulate collective input. There are a lot of smart folks in the EAB community and we need to tap into the brain trust. If you've got experience with anything we are working on, don't hesitate to get in touch if you'd like to help out. And we are always short of folks to help with analysis, so if you are a bored engineer and tired of drilling through your finger or bucking rivets and want a cross-word puzzle substitute, drop a line. We are also happy to help with any academic work--if you are in search of the thesis (or are an academic advisor) and need a flight test department, we can help. And, lastly, we run on donations. 99.5% of our donation intake goes to hardware acquisition (and a small portion maintains this web site); most of which we re-distribute to the community at no cost to help with test.