Wednesday, May 23, 2018

Airball takes a 30-hour trip to Houston and back

In addition to working on Airball, I also volunteer with FIRST as a mentor for an FTC middle-school robotics team. Although our team did not make it to the World Championship this year, I decided to go anyway to watch, learn, and meet people. I live in Reno, and the event was in Houston – what better reason to fly my DA40 cross-country?

It's about 15 hours of flying time each way, and I planned to do it over two days each way – with Airball attached, of course!

Attaching an Airball probe to a DA40 tiedown point

The first problem to tackle was how to attach an Airball probe to my DA40 reliably and have it be easily removed, easily reinstalled, and not in the way of anything important. My previous flight with Airball used the tiedown point, but required replacing the tiedown eye bolt with a RAM ball mount. For the cross-country, I wanted to ensure the tiedown eye bolt was still usable even with Airball installed, so I redesigned the mounting system.

I decided on an Aluminum plate (3/8" 6061) shaped in an aesthetically-pleasing way with two holes drilled and tapped 1/4"-20 threads for RAM ball mounts, and a third through hole for the tiedown eye bolt:

A custom mount for DA40 wing tip tiedown bolts.

This mount allows up to two RAM ball mounted devices per wing tip tiedown, so Airball and a GoPro can co-exist as well.

Waterproofing my Airball probe

In building and collecting data from the Airball probe designs up to this point we had not been terribly concerned with waterproofing the probe, because our data collection flights were generally on really nice days. I put some thought into how to (at least nominally) waterproof my probe so that I would not have to worry about whether or not to attach the probe on any given flight, and wouldn't have to worry about it if I ended up IFR in some clouds.

There were a few things I could identify and pretty easily fix or modify on the probe to ensure it didn't get any substantial amount of water in it:
  • The nose and the part that attaches it to the acrylic tube (which are 3D printed in two separate parts due to their geometry) are attached to each other with small screws, but I also glued them together with CA glue.
  • I added rubber gaskets for the RAM quick attachment mounting hardware between the "saddle" part and the tube and between the "saddle" and the RAM mount.
  • I 3D printed custom hexagonal-shaped plugs for RAM bracket's screw/nut holes to limit any water ingress which could then get around the screw. (These could be glued in for more permanency and perfect waterproofing of that path, but I opted just to press-fit them into the holes as I don't expect any forced water ingress anyway and a drop or two of water won't hurt anything.)
  • I glued the static probe into its hole with CA glue, and plugged its set screw hole with foam which was also CA-glued in.
  • I sealed the gaps between the tube and the 3D-printed mount parts with kapton tape, so that they could still be disassembled if needed.
  • Finally, the tail part has a slot which allows charging the probe and turning it on and off so it could not be permanently or even semi-permanently sealed, but I opted to just cover it with electrical tape and see how it did in flight. It was fine!
These are the rubber gaskets on the RAM mount parts:

The Airball probe's mount "saddle" got some gaskets.

The full probe, ready for flight (I also added a nice information card inside the clear tube, with contact information in case the probe was lost for any reason):

A ready-to-fly Airball probe (after returning from the trip).

It worked well! We didn't get to fully test the waterproofing of the probe as there wasn't really any significant rain anywhere on our flight legs, but we went through a few clouds and got the probe misted pretty good, and it was rock solid.

A portable data logger

In order to collect data from about 30 hours of flying, I needed to get the Airball display into some sort of shape to be taken along in the plane without getting in the way. Unfortunately I ran out of time to get the actual Airball software up and running nicely, and given some recent software changes my probe wasn't talking to the Airball display software. However, I could run some logging software so that I could collect and log all of the flight data (which I can then compare to the data my Garmin G1000 logs, for comparison and validation purposes).

I needed to do a few things:

  • Get everything to fit in a small package. I made some 3D printed parts to hold the display and all the guts into a "sandwich" form factor that could be compact and sturdy enough to survive the plane trip intact.
  • The Raspberry Pi doesn't have a typical PC's battery-backed real-time clock, so I added a Maxim DS3231 added RTC module so that it could keep time between flights without internet access to do an NTP sync at every boot.
  • I added a radio antenna and mount which would, I hoped, maintain constant signal from the probe.

This is the prototype display that I ended up with (missing the antenna and RTC module, but otherwise complete and totally functional):

The prototype display's "sandwich" form factor.


I didn't have sufficient hardware or space to mount the display on the panel anywhere, so instead I tossed it into the back seat on top of my flight bag:

My prototype Airball display "lovingly" placed in the back seat.

The flight went well overall, and I look forward to sharing some of the data I collected!

We made a fuel and lunch stop in Sedona, where I captured this shot of the plane parked on the ramp – Airball is so small you can barely even see that it's attached, but there it is on the left wing:

My DA40 parked on the ramp at Sedona (KSEZ).

Monday, April 23, 2018

It happened, the moment...

As I blogged previously, last weekend, I did a couple of test flights with CFIs. On the last one, we were returning to the airport when the following happened --
  • I am not used to the C172's glide (I usually fly an Evektor SportStar) so I was too high on approach and had to cut power and burn altitude to get to pattern altitude.
  • The pattern was very busy.
  • The controller told us to make right traffic for runway 31 right, which seemed ok.
  • He also told us we were #3 behind a Citabria on 3 mile final.
  • And finally, to extend downwind, and he would call our base.
  • The CFI pointed out to me a water tower that was a 3 mile landmark out at our airport.
  • I squinted desperately wondering, which of these is the bloody water tower?
  • And I squinted some more wondering, where in the heck is the bloody Citabria?
  • We flew on and on, and I started wondering if the controller had forgotten about us.
  • I transmitted "Tower, Cessna 123, sequence" and hoped for the best.
  • I was (if I recall correctly) asked to remain on downwind.
  • I continued wondering where in the heck the bloody Citabria was.
  • Now we were approaching rather uncomfortably close to some hills, and the CFI pointed out that maybe it would be best not to fly straight into them, so perhaps I'd better turn base.
  • I started my turn right as the controller asked me to turn base.
  • And in so doing, the controller asked me to switch to runway 31 left.
  • I puttered along trying to make the turn, expecting the kind of performance I get from my usual Evektor SportStar.
  • I overshot base to final.
  • I had plenty of distance (I extended downwind halfway to the next county, if you recall), but I still needed to be careful to do it right.
Within all this commotion -- I think during my downwind to base turn -- I asked myself the quintessential question:

How am I flying the airplane?

And I glanced at the Airball on the panel and right there was my answer. Indicated airspeed where I expect it to be, AoA where I need it, and coordinated. One glance.

A couple of test flights

Over the past week, I did two test flights with two different CFI friends in Cessna 172s. The goal was to use the Airball system (V3 board, Raspberry Pi display) in a "real" flight setting and see what the CFIs reaction was, and how they thought it would help them teach.

CFI #1

This CFI was like, ok, this is great but what does it do? :) He noted that he usually teaches attitude flying. I replied, well, think of all the times when your attitude is not a good indication of your AoA. This lit a fire in his brain.....

The first thing he did was to completely botch a stall recovery, where he pointed the nose down at the ground, "panicked" that he ground was coming up at him, then pulled up again. And there we were, with the nose pointed down towards terra firma yet the AoA was right down in the stall region. Hah!

Next he proceeded to do a steep turn. And this was definitely within utility category limits and non-aerobatic, but it was steep. My jowls felt like they were going to sag down into my lap. And lo and behold, a "fat" airball that "sagged" down to a high AoA, which if we were not careful could lead to an accelerated stall. Hah!

He also tried some more commercial maneuvers including wingovers (half of a lazy-8) and noted that it was interesting to see the yaw in the maneuver very clearly displayed, without having to look down at the laggy, slow inclinometer ball.

We also did some more regular things like slow flight and stalls, and observed how the ball changed position.

CFI #2

This CFI is all about teaching AoA, and was quite happy to finally have an instrument that visualizes it. Thus enthused, we launched for a jaunt.

We spent a long time trying stuff out with the AoA monitor. He came up with the idea of using the ╬▒REF marker (the split circle) to mark a given flight condition, then try variations from that. This was brilliant and allowed us to figure out, for example, how the AoA changed when flaps were deployed, or observe the phugoid oscillation of the airplane if we pulled up flaps without trimming. We spent a long time messing around with the flaps and observing their effect on AoA and theorizing about what was going on.

Overall, he was excited about the possibilities and planned to try it out with some of his students.

On our return from this flight, something happened that is worthy of its own blog posting. Stay tuned....

Tuesday, April 3, 2018

Airball Probe v4 is alive – and flying!

A new version of the Airball Sensor Board

In Oopsie – but it's alive! back in January, I described the process of producing the Airball Sensor Board v3 (and the "oopsie" in the short-lived v2), which made a number of improvements from Ihab's initial design (retroactively named v1).

While Ihab has been busy testing the v3 boards, I've now produced Airball Sensor Board v4, which made a handful of important improvements and made the boards a LOT better:

  1. Integrated all necessary components from the Sparkfun Fio v3 which we were carrying on the previous boards in a socket. This allows us to reduce the size of the overall board stackup quite a bit and allows us to fix a number of issues with the Fio, and gives us more flexibility in laying out the board as well.
  2. Relocated the pressure sensors and re-arranged them.
  3. Replaced the (very tiny) TI TMP102 outside air temperature sensor with a bigger and more manageable TI TMP275.
  4. Integrated all battery charging and voltage regulation on the board (instead of the Fio) and added a new battery monitor chip to provide accurate voltage and charge/discharge rate from the LiPo battery, which I wrote about recently in Validating air data probe battery life – with data.
This is what the new boards look like when populated:


It takes a number of parts to assemble one:


When assembled with the new mechanical parts, it looks pretty nice! I hope you'll agree:


The internal plumbing is quite clean with the new design:

Flying my DA40 with my new Airball probe!

I took my DA40 up for a short flight to validate the probe (and the probe mount) that I built, to test radio reception, and to see if I couldn't collect some data to add to our growing data set and provide some new insights through analysis.

Here's a close up mounted to the plane:


And a glamor shot of the first Airball-equipped DA40 (at Carson City Airport):


Onwards and upwards!

Friday, March 23, 2018

Validating air data probe battery life – with data

Hello, world!

I've been hard at work on several aspects of Airball's air data sensor probe as well as the in-cockpit display unit. I recently received circuit boards for version 4 of the sensor probe. This new board fixes a lot of things, and adds several new bits of functionality... which I'll cover in another post. One of the things it adds, though, is a battery monitor chip (the Maxim DS2782), so we can now monitor the probe's battery status in real time.

Since I am now able to easily get high resolution battery voltage and current, it seemed like a good time to do a battery "rundown" test, and collect useful data. I wanted to validate a few things:
  1. The total useful runtime from a full charge. I had some ideas about what it ought to be, but I wanted to confirm that the math is not too far off base.
  2. How the probe behaves as the battery voltage drops.
  3. Whether the probe will safely cut off at any point, or just keep running and potentially damage the battery.
  4. Whether the battery monitor chip is working and sane.
The test went well, overall! For this test, I was using a 1 Ah LiPo battery from SparkFun and a XBee Pro 60 mW 802.15.4 radio. Here is the data collected:



Using this combination of battery and radio yielded at least 12 hours of usable runtime on a full charge – quite acceptable! And, the battery discharge curve looks exactly like it should for a LiPo battery. So I must be doing something right...

A few things still require follow-up, of course:

  • The runtime was actually longer than expected (we expected ~7.5h, but ran for about double that). The battery discharge rates (in both mA and mW) we saw aligned reasonably well with our predictions, but the battery capacity seemed to be much higher. I am not sure whether that is due to the battery cell having a higher capacity than advertised (maybe?!), or some other problem with the test setup, but more validation is needed.
  • Neither the battery itself nor any other component cut off the module at a safe low voltage level. (The battery should have a low voltage cutoff at 2.75V, but despite allowing it to discharge to 2.6V, it never cut off...) I will add some additional protection mechanisms (both software and hardware) to avoid over-discharge of the cell.
More to come soon about these air data probe improvements, and some brand new design work on the display unit!

Tuesday, March 13, 2018

Yaw consistency in flight test

Here we will analyze the yaw consistency of the flight test in this directory:

https://github.com/airball-aero/airball-embedded/tree/master/data/2018-03-09-01

Recall that we observed the positions of the Airball yaw indication, with the inclinometer centered, at the following locations:


The display is 480 px wide, so half of it is 240 px. We know the pixel sizes of the decorations -- they are laid out on a 20-pixel grid. And we know that full scale beta was +/- 15 degrees. So we can approximate the yaw angles that our probe computed at these conditions as:

cruise: (2.75 * 20) / 240 * 15 = 3.4 degrees
climb: (2.5 * 20) / 240 * 15 = 3.1 degrees
slow flight: (1 * 20) / 240 * 15 = 1.3 degrees

The total variation in yaw between cruise and slow flight is therefore (3.4 - 1.3) = 2.1 degrees.

Assuming that we did indeed center the ball properly in all conditions, this means we should expect, at that mounting location, to read about 2 degrees of yaw error as a result of speed variation.

Recall that this is with a "bad" mounting location that is really pretty close to the prop slipstream -- in fact, closer to the slipstream than the factory Pitot tube itself:


So for the Nth time, the question we're trying to answer here is: Is it a good idea for Airball to measure the angle of yaw directly, or is the flow near the airplane too disturbed, and should we instead settle for something like lateral acceleration normalized by our best guess of the free stream dynamic pressure?

My conclusion from this data is that we don't yet know. :) We should:

1. Try another test with the probe mounted farther outboard -- perhaps mounted a little distance vertically below the intersection of the strut and the wing.

2. In flight, play with the relative sensitivity of the Airball yaw measurement compared to the inclinometer ball, since theory says that, with reduced dynamic pressure, the inclinometer should get "mushy". Verify that the yaw deviation seen at slow flight is real.

3. Acquire some data where we correlate the probe inputs with a signal from an accelerometer. This should eliminate the pilot technique issues of trying to center the inclinometer then read the Airball location.

This should give us a bit more information to either validate our direct yaw measurement, or nudge us to do it indirectly instead.

Second flight test

We conducted a second flight test, in a Cessna 172M. The data folder is here, with lab notes included. We will be adding some blog posts about the interpretation of the data soon.

https://github.com/airball-aero/airball-embedded/tree/master/data/2018-03-09-01