Sunday, February 11, 2018

Yaw bias due to asymmetric mounting

One of the things we noticed when we flew yesterday is that the ball was consistently deflected left (i.e. showing the airplane yawed to the right) throughout the flight.

The probe was mounted on the right hand side of the plane. We can imagine the airflow probably looks something like this:



It's not surprising, therefore, that the probe "sees" an airflow that tends to come from the left.

The problem, though, is whether this "yaw bias" is consistent across flight conditions. If it is consistent, then for a given probe mounting position, on a given airplane, all we need do is add an offset in the display software, and we're done. If it's not consistent, then we need to do something more fancy.

We do have fancy tricks we can pull out, where we "fake out" a good-enough yaw reading using an accelerometer and scaling to the current IAS, but we'd rather not play these games. The closer we are to a simple glider yaw string, the better.

Now a word about estimating angle of yaw. It turns out (we describe this in our original 2016 paper) that the ratio of pressure difference between left and right holes and the pressure difference between center hole and static is a nondimensional quantity that, according to potential flow theory, is a predictor of yaw. (The same is true for upper and lower holes, and AoA.) It also turns out that the relationship to angle is very nearly linear, with a scaling factor of about 11.5 degrees for each unit of ratio difference. With that, we can do a very rough computation of angle of yaw based on our pressures, and this is what we'll be using here.

Our intention is to get a general clue as to whether we have a project, given our current setup, or whether we need to seriously go back to the drawing board.

My conclusion at the moment is that we still have a project. Let me show you the data. First, here is the center hole dynamic pressure plotted at the top, and rough-calculated angle of yaw below, for the entire test:


What a mess, right? When we're sitting on the ground, the data is all over the place. Notice though that, halfway into the first flight, we do some maneuvers, including slowing down (this is when we tried stalls). Zooming into this maneuvering period, we have:


This looks more like data, and you can see the near-constant offset of the yaw signal. If I had to guess, I'd say it's about negative 2.5 degrees or so. The question is how this yaw signal varied with conditions. We can zoom into the area near the left of the plot where we are slowing down graduallyin preparation for the stall to see more:


There is a trend towards the right-yaw signal correcting to the left towards the low end of the speed region -- but is that real yaw that happened as we slowed down?

Finally, for this section of the data, we can plot center hole dynamic pressure versus yaw to see if there's a correlation:
Clearly there is some sort of correlation. It seems to go from a rough average of about -3.2 degrees at high speed to -2 degrees at low speed, a difference of 1.2 degrees. Again, I have no idea if this is a variation in actual yaw or the "fake" yaw due to our mounting.


In the big picture, we are building an operational instrument for pilots, not a flight test instrument. The gold standard for a flight-test-worthy airdata probe is a large boom that sticks out in front of the airplane. We can't tell every pilot to install one of those. So what's good enough for piloting?

While this question remains open, we certainly can do more data acquisition to study this issue. There are various avenues, at least a few of which are:

  • Trying out various installation locations on the same airplane;
  • Trying maneuvers with an experienced pilot remaining coordinated, and looking for correlations in that data; and
  • Acquiring data from an accelerometer and correlating with our yaw signal.
One more thing that's worth mentioning is that the standard inclinometer ball is already "wrong". For  a given angle of yaw, the ball is less sensitive at lower airspeeds (in fact its sensitivity should follow the square of the airspeed, so the difference is not trivial). Our yaw signal should be scaled properly at all airspeeds -- and it does not lose sensitivity at the low speeds when you need it most.

We hope to figure out what is the "best" yaw estimation method given convenient mounting on everyday airplanes. It might be our current aero-derived yaw, or it may be something else. Stay tuned!

Saturday, February 10, 2018

Successful first test flight

Well we did it! Thanks to my friend KC Budd who flew our hardware on his Cessna 172, N2720L, we have a successful first flight!

We flew KPAO KHAF, stopped for lunch, then returned KHAF KPAO. The air was pretty bumpy in places, over the hills and near the ground at KHAF. We did enough maneuvering to calibrate the fiducials on the Airball display, and observed how it performed in stalls.

Now the main goal of this test was to see if we have a project, or if we're barking up the wrong tree. I had no idea what the actual data would look like -- the AoA and yaw may be so bunched up on one end of the scale or the other that it would be useless. The airspeed feedback due to the ball size may be bogus. The whole concept may be bogus. Who knows until you've tried it, right? I have done some testing on the old Android app with my other friend's RV-9A, getting data from his Dynon avionics, but this was the first time with an actual probe -- and a homemade one at that. Would this be a complete dud and should we pursue something else, like quilting?

Well so KC's initial feedback is that, to a first approximation, we have a project. I concur, but then I'm obviously highly motivated. :) The AoA varied enough in all phases of flight to give useful feedback, and the airspeed feedback from the ball size helped situate us. Climbing at Vy with the AoA pegged on the Vy symbol was pretty cool. Cruise looked like cruise. Stalling looked like you'd expect.

There is still some human factors work to be done to determine if applying some nonlinear transform to the vertical scale a little bit would make it more information-dense, but for now, this thing looks like data rather than nonsense. May it continue to be so.

There are videos, which I'll link to as soon as they are uploaded from my phone.

This is our route (outbound and return). You can see the wiggling we did outbound, which was when we were testing stalls and calibrating the display:


This is what the data for the whole flight looks like. About 2/3 of the way through you can see a sudden vertical drop in temperature; this is when we switched the system off at KHAF and went to eat lunch, then came back, switched it on, and flew home:


I will be analyzing this data and posting updates as I go. One thing that was interesting is that there was a yaw "bias" in the instrument, which caused us to always be off-center. My assumption is that this was due to a combination of the flow field around the fuselage, and the mounting of the probe. It was therefore hard to try out the slip indication. One important question will be whether a constant offset can indeed correct for this bias, or if it's nontrivially related to airspeed, power setting and other factors.

Here is the back of my car as I got all my stuff together:


Eventually I got the probe mounted. You might recognize the mount from the renderings I posted yesterday. This mount worked really well and was very rigid. I'm going to make a couple of improvements to it then post the design here, and the 3D printed parts on Thingiverse, since it might be useful to some people in its own right:






We mounted the display on the windshield with a Ram suction mount:


And here we are flying (note the yaw bias):


Here is the probe flying over the ocean:


It also works over mountains:


And it can even work near the coastline, in between ocean and mountains:


which surely you must agree makes it a very versatile probe indeed! :)

More soon; stay tuned!

Friday, February 9, 2018

New Cessna mount, and a flight test hopefully

Tomorrow I'm hoping to try our first flight test of Airball on a friend's C172. All is in order; the display unit is logging data properly; I am hopeful.

I am going to use the Cloudbase Engineering Cessna 172 mount as my primary solution, but as a backup / stretch goal, I am fabricating a new clamp-style mount that's made with two 3D printed plastic parts, a RAM ball base, and a couple of 1/2" diameter fiberglass rods. The idea is to use a pair of bungees to clamp it onto the strut. If I can get it finished, we'll see if it works....

Wish us luck tomorrow!



Monday, February 5, 2018

New Open Source Arduino libraries to support Airball

As part of my efforts to clean up the Airball probe hardware and software, I rewrote the (Arduino-based) code. The probe is using three bits of hardware, which were each poorly supported or not supported on Arduino:

  1. AllSensors DLHR-series I²C/SPI pressure sensors – to sense the pressure from the various pressure ports on the probe, 3 DLHR sensors are used. There was no library available, but Ihab wrote some code to work with them.
  2. Texas Instruments TMP102 I²C temperature sensor – to read the (approximate) outside air temperature, this sensor is mounted near the edge of the board, almost outside the probe. SparkFun provides an Arduino library to support their breakout board, however, the library is not licensed properly ("beerware"), is not listed in the Arduino IDE, and is actually wrong. (It reads each of the two bytes from the TMP102 temperature register in two separate I²C transactions!)
  3. Texas Instruments TCA9548A I²C bus multiplexer – in order to support the AllSensors DLHR sensors, which have fixed I²C addresses, a multiplexer is required. No library was available in the Arduino IDE, but Ihab had written some code to work with it.
I wrote three relatively clean 3-clause BSD-licensed libraries to support these components, and as of today, they are all now listed in the Arduino IDE's library manager and available for anyone to easily install and use! You can find them in Arduino IDE (Sketch → Include Library → Manage Libraries...), for example:



You can also find them all on GitHub:

We hope that providing better support for these components in Arduino will help a few others!

Sunday, February 4, 2018

Probe nose progress

A major disadvantage of our current probe design is that it's hard to put together. To get an idea of the messiness, see this video (sorry about the expletive but the process is frustrating).

So I'm now working on a new probe nose that will integrate all the plumbing and the static probe mount into one unit. To make it easy to 3D print (and with an eye towards future injection molding or machining), it's in several layers, with the plumbing routed as a series of grooves. The layers will get bonded together and sealed. The 1/8" OD vinyl hoses will get bonded directly into the manifold.

This is the stackup looking from the front:



and this is what it looks like from the rear:


the parts need to be cleaned up in some cases -- some holes need to be chased to exactly 1/8"; the mounting holes in the nose need to be tapped to 6-32; and the exterior holes in the nose need to be drilled out carefully so they have a nice clean edge rather than the 3D printed blobby shape.

Since this is a bit of a mockup, I'm using a fairly large nozzle (0.3mm) and layer thickness (0.2mm); the nose, in particular, could probably do with a far more fine printing resolution.

The static probe attaches into the bottom of one of the layers, with a groove in the tube to pass the pressure through:



The longer term plan is to secure it with a 1/16" diameter by 1/4" long dowel pin through the whole subassembly before mating to the other layers.

This then is what you end up with, with all the tubes coming out in nice convenient locations:



and the slot secures the PCB so the whole thing can go into the housing as a unit:


Now note that instead of the temporary machine screws you see here, the plan is to use four 6-32 threaded rods that go the full length of the probe and clamp everything together axially.

I've also ordered some (expensive!) 1/16" wall thickness, 2" OD polycarbonate tubing for the housing, as the 1/8" wall thickness stuff I've been using so far is just way too heavy and clunky.

This design is fully compatible with our current board using the Fio V3 (though it may require some creativity in mounting the Fio lower down, to clear the threaded rods). Our longer-term plans include an integrated electronics unit, without the Fio as a daughterboard, which should be even easier to work around. I'm hoping that the switch to the newer-style board can happen with simply a shorter housing, by keeping the same basic form factor (1.5" wide PCB).

Friday, February 2, 2018

Road test data from Jeremy's board

Today was my first road test with Jeremy's new board. As expected, it was reliable as a rock. Here is all the data:


Notice that the speed seems a bit measly, and there's a reason: It was rush hour and most of it was stop-and-go traffic! Zooming in on the small region of speed (about 59 mph peak), we have this:


Finally, data! Without glitches, transients, hangups, freezes, weird numbers, or any of that other stuff. Just wonderful yummy data!

Here is the probe on top of the car, glowing eerily in the evening twilight:


and here is what it looks like to have Airball on your instrument panel. One day, soon, coming to your airplane, folks:



Updated Citabria mount

I did a mega-print job last night and this morning, and the result is a new and improved Citabria mount. I'm keeping this one un-glued for now while I think it over so I don't have to trash the entire thing if I find a problem with one of the parts!