I'm going to lead off with our biggest achievement yet--achieving initial operating capability using automatic system calibration. It's tough just to write about it without getting stoked up, since we've been chasing this for the past three years or so. Insert excited happy face emoji here. If you've hit the end of the internet and run out of other worthwhile things to do, you can watch me get excited real time as I figure out Lenny scored a touchdown with this logic and interface: https://youtu.be/r6ZUBvn_b3w
We learned early in the project that most pilots have difficulty achieving an accurate calibration of an angle of attack system. Accuracy is important if the system is going to be used as a primary energy reference. We want to measure AOA to within 1/4 to 1/2 degree or better across the entire speed band of the airplane, even at high G onset rates; so it has to be calibrated properly.
To understand calibration, it's necessary to understand what AOA is. The basic relationships are shown in Figure 1 in simplified form. In level flight, flight path angle is zero, and pitch equals AOA. Thus, if we can achieve perfectly level, unaccelerated flight in still air, we can derive AOA from pitch. The operative words in the last sentence are "perfectly level, unaccelerated flight." Turns out, that's not easy to do precisely. Professional test pilots spend lots of time chasing those stable data points. Enter the Inertial Measurement Unit (IMU).
If we know the pitch and the flight path angle, we can derive AOA. Technically, the "AOA" depicted in Figure 1 is difference between fuselage body angle and the relative wind, which is sufficient for our purposes. To know pitch and flight path angle, we need an IMU. For the past couple of years, we have been trying to tame the inexpensive IMU we have been using. It's nicknamed the "ten buck chuck." Like the cheap wine, it's supposed to do the trick; but it turns out you get what you pay for. Unfortunately, this inexpensive MEMS based platform is highly temperature sensitive. Our first inclination was to write code with a correction factor, but easier said than done.
After much hand-wringing, gnashing of teeth, foul language and beer (the standard engineering process), we decided to pursue auto cal in two phases. The first phase bypasses the on-board IMU and uses an EFIS AHRS solution via serial input. Obviously, this means that our current auto cal logic will only work in EFIS equipped airplanes, and the EFIS must be connected to the ONSPEED system via a serial wire. The second phase is to bite the bullet and replace the ten-buck chuck. Our current candidate isn't too expensive. As a matter of fact, it's about double the price, so it's already been dubbed the "twenty buck chuck." It remains to be seen if A) this will work sufficiently well; and B) can be retrofit to existing hardware. Early heat testing is promising; but we still have lots of homework to do.
Previous Practice
Until now, we have been flying a series of "trim shots" to develop an aircraft curve. This involves some fairly precise flying in smooth air to achieve a stable condition at various angles of attack. The basic principle of changing AOA is shown in Figure 2. Each element in that figure represents a different stable AOA condition. The greek letter theta is pitch. A series of trim shots from speeds just above stall to Vmax are required to develop an accurate aircraft curve. Figure 3 shows an example of trim shots plotted vs coefficient of pressure. The aircraft "curve" is a regression of the data that the system uses as an algorithm to convert the difference in pressures into AOA. In this example, a linear equation results. The computer multiplies the measured coefficient of pressure (P45 divided by Pfwd) by 23.672 and adds 4.1089 to determine AOA in degrees. The "r squared" value is a statistical test to determine how well the equation fits the data. An R2 of 1.0 is a perfect fit, thus a high R2 is desired.
This calibration technique results in an accurate calibration, but places significant demands on the pilot and requires post-flight data reduction and subsequent programing of the ONSPEED system via the WiFi interface. Doable, certainly, but not necessarily "easy." Oh, and there are some undefined engine power effects associated with stabilizing at high AOA that likely skew the results of this type of calibration.
A curve is required for each flap setting, so in the case of my RV-4, three curves are required (Flaps 0, Flaps 20 and Flaps 40). After test flights to develop the curves, the curves are programmed and another test flight is required to dial in "set points." There are four set points: L/Dmax, ONSPEED Fast, ONSPEED Slow and stall warning. The 400 Hz slow beeps start at L/Dmax and transition to solid tone at the ONSPEED Fast AOA. The tone remains solid until ONSPEED Slow AOA is reached, where it transitions to the 1600 Hz slow speed beeps which increase in pulse rate until stall warning AOA. To program the set points, it's necessary to fly each one of these speeds and program the set points using WiFi. It typically takes me two or three dedicated flights in the RV-4 to fly all of the trim shots required and get the tone set points correctly dialed in. There are also a few hours of homework inputing data into Excel or MatLab to develop the curves required. We call this long, onerous process "hard tuning" the system.
A Better Option
The tactical problem was to develop the graph in Figure 3, eliminate possible engine power effects, compute an aircraft curve for each flap configuration and develop set points automatically. Preferably in two minutes or less with one button push for each flap configuration. In other words, make the process as pilot-proof as practical.
We worked out the physics of the technique using what we called "dynamic" calibration. This involved decelerating from Vmax to stall, and then developing a scatter plot of the data for the linear portion of the lift curve using 50Hz data. This resulted in a plot similar to Figure 3, but with a few thousand data points due to the high frequency logging. Since the computer is just as happy running a regression whether there are a dozen or few thousand points, the math isn't any more difficult from a pilot perspective. AutoCal logic uses this basic principle. Figure 4 shows 10Hz data for a 1Kt/Sec deceleration from Vmax to stall.
As can be seen in the plot in Figure 4, there is some divergence from the trend line around 10 degrees AOA and again at higher AOA. Although the R2 value is pretty good, using this algorithm would result in some error in these two AOA regions. A polynomial regression is a better option and shown in Figure 5. In this case, the parabolic curve does a better job of capturing the slight curve in the data, resulting in a higher R2 value and more accurate AOA computation across the aircraft speed band. Being excellent at math, the computer can run this second order polynomial without breaking a sweat, even at high speed.
Enter the Auto Cal Wizard
A "wizard" is a piece of software that helps you set up, well, software. In this case, Lenny has developed a WiFi based program that walks you through the automatic calibration. It can run on any smart phone, tablet or lap top. I have an iPhone 12, and that's what I'm using in the video to run the wizard.
You access the wizard by connecting the phone/tablet/laptop to the ONSPEED WiFi network, cleverly named "ONSPEED." After connecting, the browser is opened (Safari in the case of my iPhone) and you type onspeed.local in the address line. This works for any IOS device or Mac. For an Android device or PC, you type 192.168.0.1. This opens the ONSPEED Home Screen, which is the user interface. The wizard is at the bottom of the Settings Menu. When you click on the menu, the calibration wizard opens. This shown in Figure 6.
You can see that four inputs are required: maximum gross weight, test weight, best glide speed at gross weight and aircraft G limit. After entering these parameters and hitting the continue button, the next screen opens (Figure 7):
Hitting the continue button brings up the deceleration display. In a perfect world, we'd like to decelerate at a steady pace with a constant pitch increase smoothly into the stall. The pitch rate increase is more important than the deceleration rate; but we've added a display that shows deceleration in knots per second. The idea is to target the green band, while smoothly increasing back pressure. Frankly, more testing is required to develop the technique; but if you watched the video, you can see that I tried multiple different techniques and they all resulted in a usable calibration. More analysis and testing is required to determine how much "slop" a good calibration will tolerate and still be considered "good."
The system automatically detects stall, and then outputs a calibration (Figure 9). This is shown in Figure 9. The pilot can assess the quality of the calibration by looking at the graph and the R2 value and decided if it should be programmed (by hitting the Save Calibration button) or another run should be flown. The Save Data To File saves the data to the phone/tablet/laptop but does not program the calibration. Data is recorded at 10Hz and is saved in .csv format so it can be opened with any spreadsheet.
Lots more testing to do, and these screens are still preliminary; but we are really encouraged by initial results.
The Dirt Cheap AOA Probe
Tron has been working on an inexpensive pitot/static/AOA probe using some low-tech bent tubing. About as simple as it gets. The top tube provides pitot, the middle static (the end is capped and the sides drilled) and the bottom is bent 45 degrees for a differential AOA pressure. These prototypes were fabricated by our newest team member, Ben Bell. Thanks, Ben! We hope to start testing this probe in May.
