Saturday, March 28, 2020

ESP32 probe ongoing programming

After some digging around, I decided to change the ESP32 probe's protocol to TCP rather than UDP, at least for this initial stage, to ensure that we got a reliable stream of messages, and any unreliability would be more correlated with something in the probe itself. As usual, check out our code in the airball_probe_es32 directory in our repo.

The innards of the probe are now on a piece of plywood, and they look like the below. Given that what you see is all we need, this should all be quite easy to integrate into the 1-inch diameter new probe form factor.

The Wi-Fi RF performance seems excellent. I put this stuff all the way across my yard and behind the house, covered with a large metal garden dustpan, and I still got really good quality reception from my computer's Wi-Fi. That's very encouraging.

In other good news, if the battery monitor is to be believed, we draw about 170 mA when operating normally. With a 3400 mAH battery, that's about 20 hours of life. If we de-rate this to protect the battery, we still can expect a safe 12 hour battery life, which is my metric for, basically, "all day long". This means that a pilot or CFI can plop the probe onto their plane in the morning, fly around without paying any attention to it, and pull it out and put it on the charger in the evening.

Less encouraging is that, for some reason, I now seem to be having power supply issues, which cause flakey performance of the sensors and the Wi-Fi. Now it worked previously just fine, so I assume my wiring is crappy or I need decoupling caps, or some combination. But in any case, before we call the circuit done, I need to make sure these gremlins are no longer there, and learn what mitigations, if any, I need.

Sunday, March 22, 2020

ESP32 probe code complete

Yesterday, I got the ESP32 version of the probe up and running with the following setup:

The code is in the firmware/airball_probe_esp32/ directory of our repo. This verifies that we can connect to our SPI and I2C sensors and get battery statistics over I2C, and broadcast the results by establishing a WiFi base station and broadcasting UDP packets on a well-known port.

The ESP32-DevKitC bundles a lot of the USB and power regulation machinery together, and uses an obsolete USB part, so I am hoping to bench-test a more stripped-down setup before spinning up a custom PCB. To that end, I need access to the individual pinouts of a raw ESP32-WROOM-32U module, and so this is what I made:

I will be reporting more on the following --
  1. Verifying data rates and reliability with the UDP transport.
  2. Battery charge time and battery life with the new battery.
  3. Results of trying out the more stripped-down ESP32 setup.

If this all checks out, then we are well on our way to a really compact, and relatively low-cost, version of our probe electronics. Stay tuned!

Sunday, March 15, 2020

Calibration curves in the ESP32

Given that I'm planning a transition to the ESP32-WROOM-32U, I'm going to have way more memory to play with than I had before. That means I can embed calibration surfaces (see the last blog post...) directly into the probe, without having to come up with a fancy curve-fit to save memory!

This weekend, holed up in the house due to COVID-19 and grounded due to rainy and cloudy weather, I have been doing just that. The results (ongoing) live in the airball-probe-esp32 directory of our Github repo. Just one function call that does 3 table interpolations is enough to turn the three pressures, (dp0, dpa, dpb), into the three airdata parameters, (α, β, q).

The calibration tables are currently generated based on potential flow formulae, in Python. Of course a future, and better, implementation would be to derive these from wind-tunnel data. But the beauty of this is that we will have verified the entire stack, execution speed, memory usage, etc., and will just swap in some numbers in place of others.

Stay tuned for some hardware prototyping with the ESP32-WROOM-32U next!

Saturday, March 7, 2020

Quick flow math for new probe nose

Per my previous post, I have been thinking about getting rid of the static pressure tube just using an extra hole in the front "ball" nose. The following is some simple back-of-the-envelope math to see if that is likely to work.

First let's describe our setting. We plan to add a 6th hole 90 degrees from the centerline, at the bottom of the probe, as follows:

You can see that we measure pressures dpα and dpβ as usual, but dp0 is now between the center hole and our new 6th hole in the 90-degree position.

Using the standard potential flow formula for a sphere, we came up with the expected pressure ratios, to see if we are likely to get good data or if we'll have nasty singularities. The good news is that all seems promising.

We will plot various values for a range of α and β of ± 25 degrees. The color in the following plots is a measure of total angular distance from the centerline, to help with visualizing the surfaces.

First, let us plot the actual pressure differences measured by the sensors, in relation to the free stream dynamic pressure q. We plot (dp0 / q), (dpα / q) and (dpβ / q):

The ratios are all reasonable and there are no surprises. (dp0 / q) is around [1.0, 2.5], and (dpα / q) and (dpβ / q) are both in the range [-1.5, 1.5]. In particular, (dp0 / q) is a reasonably solid value and will not be close to a divide-by-zero

Now we plot our pressure ratios that we will use to calculate α and β, (dpα / dp0) and (dpβ / dp0), to see if there is a clear signal:

The range in both cases is about [-1.5, 1.5] and approximately linear. That is very good.

We conclude that this probe nose design is well worth pursuing. The pesky static pressure rod is a pain in the neck to mount, and it makes our probes a lot more bulky. It would be awesome to get rid of it!

Sunday, February 16, 2020

Ideas for a next-generation probe

Losing the static probe

I have a friend who is an aeronautical engineer at nearby NASA Ames, at Moffett Field. He's been a great resource in helping me think about my probe. He has designed 5-hole and 9-hole alpha/beta probes for the NASA Orion spacecraft, so this sort of thing is not new to him.

Based on his feedback and my flight test data, it's clear I'll likely need to do some sort of calibration of the probe, based either on CFD simulations or wind-tunnel data, or a combination of both. Luckily, my Reynolds number range is not huge, so I should be able to get some pressure ratio calibration that will work for my entire range of dynamic pressures.

He has pointed out to me that, since I'm all in on calibration anyway, I don't technically need this bulky static pressure probe sticking out. I could measure any additional pressure between any of the holes on the ball nose. All I need is 3 pressures, to determine 3 unknowns (α, β, q). Once I determine q, I can subtract that from whatever the barometer reading is, from whichever probe hole I choose to connect it to, and get a "true" barometric reading.

Discovering the ESP32-WROOM-32U

While I was living under a rock, the world has gone all in on ESP8266 processors and Wi-Fi "Internet of Things" modules. The next step from there on is the ESP32-WROOM-32U which has lots of memory, can be programmed via the Arduino IDE, and comes with all the Wi-Fi I need. And it costs $4.50 per part. Yes, you read that right.

With all that memory, I can afford to embed the calibration tables in the probe itself, meaning that anyone can grab the probe, connect to Wi-Fi, and receive data sentences at 20 Hz in the form:



α = angle of attack
β = angle of yaw
q = dynamic pressure
p = barometric pressure
T = temperature

This means that people don't need to use "my" host Raspberry Pi software to get immediate, useable airdata.

A smaller form factor

Given all the above, it should be possible to fit the whole thing into a 1 inch diameter by about 8+ inch long housing, still with the transparent polycarbonate tube that is our trademark. :) If we add a USB interface, it should be possible for someone to get a probe, put it together, and then program it with the Arduino IDE themselves without having to take it back apart!

Recall we got ~ 12 hours of battery life with a 1 Ah LiPo battery. With a 3.2 Ah 18650 battery, regardless of how much power the ESP32 consumes to transmit on WiFi, it is very likely we could get similar if not better battery life.

The installation flexibility of such a small package would be awesome! You could simply zip-tie it to any sort of "curved" mounting ... we would not need to add any screw holes.

Wired installation

To install this in a wired fashion, we have an ongoing to-do item to prototype an RS-485 driver. With that and a standard R/C airplane "battery eliminator circuit" to step down the ship 12VDC to something near 5V, which we could then down-regulate to 3.3V, we'd have a wired system with the comms going over a single twisted pair. More on our experiments with that soon.

Of course you might ask: But the wired probe will not need Wi-Fi. Will you use a different microprocessor so that you don't waste all that Wi-Fi functionality? To which I answer: $4.50. I can afford to standardize on the part with the integrated Wi-Fi and just ignore the Wi-Fi, and it's still cheaper than most of my alternatives.

New "V block" mount in progress

One of the contributions of the Airballs to the universe is ways of mounting reasonably lightweight, compact junk to your plane in a secure but "tool free" manner. Our mounts so far have been 3D printed to the exact contours of the struts. We have versions for a Citabria, Super Decathlon, C172, and RANS S-6S.

This arrangement is very secure, but leads to a rather bulky 3D printed chunk though, and may not be universally applicable. This has led us to consider a more generic "V block" shape, where we augment the 3D printed parts with a piece of aluminum angle and add some padding. This is what we have so far. It seems just as secure as the custom-contoured version. Stay tuned for more details.

The "pitch string"

Yesterday I tried out this idea I've had for a while -- the "pitch string":

I attached a piece of fishing line vertically down the airplane's centerline, with tiny beads on it every 2 inches. Now this may not be the case for everyone, but for me, if I focus on the horizon, I see two equally clear images of the string (due to parallax). My aiming point is halfway in between them. So I can use these to watch the movement of the nose as I bank into turns, and keep track of the pitch of the airplane relative to the horizon.

My contention is that something like the pitch string, plus Airball, is the ideal setup for VFR flight instruction.

Already, even after all these hours of flight (well -- I mean, 300 hours is not a lot, but it's something), it helped me notice how I need to raise the nose in turns, and be more aware of adverse yaw. My CFIs always told me to pick a point on the nose or windshield and use it as a reference. However, without specific instruction as to which point to pick, I think my eyes tend to wander and I become more heads-down. Something that gives me a specific thing to focus on is super helpful.

An improvement may be that, instead of equally spaced beads, it should have just one "bead" that the pilot can move up and down to act as a reference. For training airplanes used by many people, I can imagine a "ruler" aligned edgewise so it doesn't obscure the view, but with graduations on it so each pilot can reset the "bead" to their preferred location, might be a useful thing.

Saturday, February 15, 2020

New probe is very consistent with existing ones

Today I did a flight with one of our new probes. Compare the "new" one (top) with the "old" one (bottom) here:

You can see that the new one has a bit of a longer static tube, but is otherwise quite similar to the old one. The readings are super consistent with what we had before. This graph shows the data from the old probe in two separate experiments, versus the new probe:

So basically, anyone can build a probe according to our specs with their 3D printer and some electronic muckery, plop it on their plane, and without any additional messing around, get consistent results. This is HUGE. :)

The next step is calibration, of course. More on that soon.

Sunday, February 9, 2020

Sunday, February 2, 2020

Two more systems!

As of last night, after diverse trials and tribulations, we have two more Airball systems:

Apart from the various noodling around we've been doing with verifying the airdata on the plane, the problems with this particular build-up is that we seem to have gotten a bad batch of TCA9548A I2C mux chips, and messing with that issue wasted a bunch of time. But we're back on track, and newly confident that, if we assemble our things right, they actually do work properly. Yay.

The first system we hope to give to a friend who has a background in aeronautical human factors, and it looks something like this:

You can see the probe and display, obviously, and our current prototype for our "V block" shaped strut clamp that should be compatible with a large variety of airplanes.

Stay tuned for more news!

Monday, January 20, 2020

Integration test using water manometer

If you follow this blog, you know that we've done extensive water manometer testing of our system, especially the pressure sensors. However, in our quest to knock off hypotheses about the IAS discrepancy in N291DR (and as a way to, coincidentally, also build confidence in the components of our system), we decided to do a quick water manometer test of the whole system. Sort of like an integration test. Never hurts.

Sorry that we don't have pictures for this one ;) but what we did is apply pressure to the dp0 sensor of the probe, in inches of water, and read off the IAS from the cockpit display. This tests the whole thing -- end to end. If we convert applied pressure to IAS in knots, and compare to the reading on the instrument, we conclude that the full system is working correctly.

Probe position is not responsible for IAS problem

Continuing our experimentation, I decided to mount the probe on the end of a 3/4" fiberglass pole securely fastened to the struts of N291DR. Here are a few pictures of the mounting:

The result is that, while our AoA numbers near stall decreased (expected since the probe is relatively free from upwash effects), our IAS readings remained consistent. This is a graph of the results:

Note that, at low IAS, we report numbers higher than the N291DR instrument. This is to be expected. We are compensating for AoA and yaw angle, whereas N291DR's instrument is just a simple tube sticking out into the wind. At high angles, N291DR's instrument will read low.

The mystery continues. The next thing is to do a proper calibration using a quadrangle course with ground speeds and record the results. At this point we're just knocking hypotheses off the list, and some may argue we should have done that before doing the probe on the long pole experiment, but this yielded interesting results in and of itself. It taught us that, while the AoA values change, the IAS numbers remain pretty consistent regardless of where we stick our probe.

We did capture a video of the approach to a stall, which you might find interesting. Check it out here.

Saturday, January 11, 2020

Static source is not responsible for IAS problem

Today, I flew a short flight with an alternative static source made of a very long acrylic tube jury-rigged to the strut:

I wrote down the IAS from Airball and N291DR's ASI, and compared them with what I got when I was flying earlier (see this post) with the probe's original static source. This is what things look like (click on the photo to see it full size):

Airball reads lower than N291DR's ASI in all cases, and the alternate static source caused a tiny correction in the expected direction (Airball's reported IAS was higher, corresponding to a lower static pressure presumably unaffected by the mounting pylon), but ... it's not a significant change.

I jotted down some data from the flight:
GPS magnetic heading: 300°
GPS ground speed: 75 ktas
Airball IAS: 85 kias
N291DR IAS: 95 kias
GPS altitude: 3,271 feet
The flight was approximately 2200Z on January 11, 2020. My Foreflight wind briefing said:

So we can assume I had about a 20 knot headwind, traveling more or less straight into the wind, and low enough that my TAS and IAS were the same to a rough approximation. If my GPS ground speed is 75 ktas, then by these assumptions I would expect my IAS to be 95 kias.

And indeed the N291DR ASI showed 95 kias, whereas Airball read 10 knots lower.

   ~  ~  ~

At this point, given the validation I have done of the sensors and telemetry and everything else, I am very, very close to the simplicity of a water manometer attached to a piece of pipe sticking out in the wind. :) Therefore, the next thing to suspect is installation error -- i.e., that the airflow around that portion of the wing is sufficiently slowed that it reads 10 knots low.

I hope to design an experiment to suspend the Airball probe a couple feet in front of the wing using a boom securely attached to the struts. Stay tuned for more details.

Saturday, January 4, 2020

Debugging apparent IAS discrepancy

I am now full-on debugging the difference between our aircraft's ASI and the Airball display, to see who (if anyone) is "right".

First the obvious. Is the data shown on the Airball display the same as what I get by post-processing the logs? The answer is "yes". I looked at our recent flight video and compared it to the data when I post-process the logs and to direct cellphone footage of Airball taken by Melissa. Indeed, what I see on the Airball screen in flight is consistent with the entire chain of data manipulation and custody.

So, is the "fancy" math somehow wrong? I post-processed the data and calculated an indicated airspeed based on using the center hole pressure as a plain Pitot tube -- without any alpha/beta correction or anything. Just convert pascals to meters per second using the density of dry air, and then convert that to knots. Compared with the "fancy" equations, there is very good correspondence.

Zooming in on a region of the graph just to be sure, we further confirm that "the fancy math" is not our issue here:

So the math is reasonable, and it seems to match the physical pressure quite well, and we know our pressure sensors are good because we just tested them with a water manometer a few days ago.

The remaining hypotheses would be:

1. Aerodynamic errors caused by the design of the probe, or its placement on the aircraft.

2. The ASI in N291DR is wrong! :)

We don't yet know about #1. We would like to rig up a simple wind tunnel test. Meanwhile, we have a realization about N291DR:

N291DR does not have a static source

Correct. The altimeter and ASI in N291DR have a "static" source consisting merely of a stub of tubing that is open to the back of the panel. So this is definitely a place to start suspecting mischief. One would expect that the inside of the fuselage experiences suction, leading to an artificially low "static" pressure, which would cause both the altimeter and the ASI to read "high". Can we confirm this?

For that, let's look at this photo from last evening's flight:

Airball shows 76 kias, N291DR shows 87 kias. Both Airball and N291DR are set to the current barometric reading, 30.02 in Hg. Airball shows 5500 feet altitude, while N291DR shows about 5530 feet.

Could the altitude difference explain the IAS difference?

Using the international standard atmosphere:
5500' --> 82,742 Pascals
5530' --> 82,648 Pascals
So the reduction in pressure as measured by the altimeter is approximately 94 Pascals of "extra credit" that our ASI could be reading.

If we take 76 kias, convert it to a dynamic pressure (917 Pa), add 94 Pa, then convert that back to an IAS, we get 79 kias.

79 kias is clearly more than 76 kias, but it does not explain the "jump" in reading all the way to 87 kias.

We therefore do not yet have an explanation for the discrepancies. Our workup should include one or both of the following:

a) Fly a quadrangle course with N291DR, "calibrating" the Airball IAS as per the usual practice using GPS ground speed, and use that as a "source of truth" to find out what parts are in error.

b) Stick the Airball probe in a wind tunnel. We've shied away from that so far because we hoped to have a complete, well-instrumented experiment. But maybe it's worth 1 hour of wind tunnel time to just stick our existing probe, with our existing telemetry and everything, with the simplest possible setup to get a reality check.

Remember the Dynamixel servos from 2 years ago?  I just resurrected them. They are sort of shaky and wobbly but they would give us a reasonable way to position the thing. And they work, and they are ready today. Here they are mounted on a wooden pole, with the probe attached....

Stay tuned. We'll get to the bottom of this soon enough!

Test flight with leak-free probe

Using my Shapeways 3D printed leak-free probe nose and modifying a bunch of other parts, I made a leak-free test version of the probe. at the end of this post are a bunch of construction pictures.

A test flight in N291DR was delayed by the need to change out the spark plugs, but after that, I took off for a quick dusk jaunt. The IAS on Airball was still way under that displayed by the aircraft. This photo album contains the photos I took of both together.

Now my priority is to look for all the other sources of error. It may be a simple bug in my code :) but if that's the case, I need to make sure things are better tested. Stay tuned.