Harrison's Aero Stuff

Well, it’s been one hell of a quarter, with structures, this class, and CPSS. First, I’ll wrap up the lab hack. As I said in the last post, construction is complete, and on Friday we were able to get the data as promised. 3 hours later than scheduled, but that was mostly the fault of a campus-wide power outage (The Scanivalve Gone Walkabout group was none too happy about it, though). I haven’t had the time to properly analyze the data yet, though, so I don’t yet know if our modifications made any difference. At a glance, though, our run did seem to have a higher dynamic pressure in the tunnel than before the modifications (1,360 over 1,260), which is at least promising (but inconclusive because of varying ambient conditions, etc). And hey, at the very least, it looks cool. 

Course Reflection

As before, I’m not inspired enough to do a free-form reflection, so I’ll settle for answering some (summarized versions of) reflection questions that Dr. Doig has thoughtfully provided.

What was your experince with the more open-ended style of project presented in this class, where you were given only a goal and not a procedure?

It’s pretty interesting, actually. I’m no stranger to the idea of an open ended project. After all, I’m heavily involved with CPSS, and that’s 90% of what we do - set out a goal and figure out how to get there. I actually found it more difficult in the 307 environment, though, mostly because of the lack of hierarchy. For comparison:      In CPSS, there’s a leadership structure. I dictate the design for the avionics systems, and then delegate labor to make them happen. The avionics are designed to meet the requirements laid out by the president, Adam, who has the final say in all matters. If there’s ever a design dispute, we discuss until it seems each side has made a complete argument, and if we hit an impasse, the president makes the decision. This setup is useful in a couple of ways. Most obviously, it provides an easy way to move design along - just ask Adam. But it also makes sure that everyone knows what they’re responsible for; I don’t sit around hoping someone will take care of the avionics, because I know it’s my job.      In 307, though, none of this structure exists. This means that design discussions are more difficult to conclude, and can result result in some sneaky politics if you’re not careful (we avoided this, thankfully). Also, if the group isn’t careful to assign jobs, some tasks just get left floating around until someone realizes they’re in the best position to get them done. For example, Eric wasn’t assigned to be our shopper, he just decided that, since he was commuting from off-campus anyway, he might as well hit up the hardware store. Similarly, on the night before our last lab day, I realized that we hadn’t coordinated a way to cut our foam inserts, so I reached out to a friend in DBF, who was willing to give up a couple hours on the morning before lab to help Kyle and I cut foam (Thanks Kurt!). Something that did end up falling through the cracks was a second tuft test. I didn’t mention the first one until now because no one shared the video with me, but we missed doing the second one entirely because  everyone either forgot or waited for someone else to do it.      Despite all that, I don’t think there should be a hierarchy established for teams next year, like having the TA’s and Dr. Doig choose a project lead. It’s good for us to get practice in creating organization from nothing.

Other than time constraints, what was the most challenging portion of this class?

Time constraints. I know other students will have a lot to say here, so I’ll keep things brief. This is supposed to be a two unit class, and yet it easily took as much time as other four unit major classes. I’m actually ok with that, though. I don’t think there would have been a way for me to get as much out of this course in less time. I would suggest, however, attempting to stagger the different groups that require heavy tunnel usage. Maybe have groups like PROVE and the PIV people do more work early in the quarter before 307 starts the open-ended projects, or prioritize the other way, and have 307 do their open-ended projects when groups like PROVE and the PIV people aren’t going to be as active.

What was the most memorable moment of the course?

The sexy water tunnel videos. C’etait vraiment magnifique. (Et je n’savais pas que Dr. Doig parle francais. C’est cool, ca.)

One last thought

It’s done! Both sets of plexiglass inserts have been installed, as have the foam spacers. This is what the upstream diffuser looked like just before it was slid back into place:

The blue foam inserts are clearly visible, and you can see one or two of the upstream plexiglass bits above the ladder. Speaking of the blue foam, HUGE thanks to Kurt from DBF for giving up two ours of his Thursday to run the CNC foam hot-wire cutter for us. Also thanks to the other lab groups in the tunnel at the time who helped us wrestle the diffuser out of the tunnel, and then force it back when we were done. More or less. When we put it back in place the first time, only half the bolt holes to connect it back to the test section were lined up. Even after shoving it around a bunch, we still couldn’t get the other side to fit. So we wheeled it all the way out (which takes between four and six people), then all the way back in, and the bolts on the control room side were still a good 3/8 of an inch off. No idea how any of that hardware ever fit before. Oh well. It’s not like the section is going to run away or anything, when it takes six college guys to make it move anywhere. And it’s still locked in place with C-clamps and the other half of the bolts.

After cutting all the plastic and drilling the holes in the downstream diffuser Friday, we were able to do a lot of assembly today. We split into two pairs to get more done, so Ryan and Eric screwed the downstream inserts into place, while Kyle and I crawled into the upstream diffuser to drill holes for the other set of inserts. Instead of sweeping out the tunnel after each set of holes like with the downstream section, we just drilled them all, then cleared out the mess in one go. Here’s what that looked like from inside the tunnel:

I’d forgotten about the screen in front of the fan until now, too. We had been thinking of using a thin ribbon of plexiglass all the way around the tunnel to extend the circular fan section out until it touches the screen, but now we’ll probably go with foam cutouts. I asked Kurt from DBF today if he’d be willing to let us use their CNC foam hotwire, and it seems like that could work out. 

Meanwhile, Eric and Ryan finished screwing in all the downstream inserts:

We started the lab hack project today! Well, started building it. We’ve actually been working on it for a little while now, spending last week on design, and this week on prototyping. I just haven’t remembered to take any pictures until now. So here’s where we’re at as of today:

Prototype installed! But hang on, I’m getting ahead of myself. 

The Project

The last 307 project is the Lab Hack, where groups of students take on a project, most of which are designed to improve the wind tunnel lab. My group’s task was to try and improve tunnel performance by smoothing out the wall transitions into and out of the fan cowling. If you’ve never seen our tunnel before, this picture might be a bit confusing, but it sort of shows the problem. It was taken from the tunnel outlet, looking into the downstream diffuser. Both the downstream and upstream diffuser portions form an octagon where they meet the fan cowling, which creates a bunch of two-inch high steps that could be disrupting the flow. 

The Solution

To smooth out these steps, our group decided to flex sheets of plexiglass into the corners of the octagonal sections so that they come up to meet the cowling. If I had written this post a few days ago, I’d go into more detail, but you can already see what we’re planning in the picture up above.

Going Forward

Once we got this first wedge installed, another group ran the tunnel for their project. I filmed the prototype wedge as the tunnel was running to see if the plastic would flap or vibrate at all. Fortunately, the video looked just like the image above - completely static. Our wedge design is rock solid. All 15 of the other triangles have been marked out on polycarbonate sheets, so we just need to find some time with a bandsaw to cut them out. ME senior projects are due soon, so hopefully there’ll be more room in the shops for us. We were shooed away when we showed up at the hangar the first time around since they were full of ME seniors. Once the wedges are cut, we’ll screw them into place, and try to quantify any tunnel performance improvements by measuring the relation between fan speed and tunnel velocity.

Full Circle

I’m actually really happy with how the flow viz project went, both for my group, and the other groups in my section. I’m not gonna cover my group’s entire presentation here, instead I’ll try to stick with stuff I did, then maybe sum up the presentation’s conclusions. I became my group’s image manipulator in chief, since I was the only one to have used GIMP (it’s basically open-source photoshop) before. My main task was the one I mentioned at the end of my last post -  to find smoke features that match in both perspectives on the flow. To do this, I started by using reference lengths in the images to figure out a scale for each perspective, which ended up being about .005 in/pixel for both. Then I made a composite image of all three wake slices taken at 14 inches from the trailing edge of the wing to make sure I had all possible flow features to measure to, giving me the best shot at finding one that appeared in both perspectives. Also because it looked cool:

Second lab slot was a success! Mostly. We didn’t get to do the test we were planning, since the force-balance system that supports the finite wing wasn’t working. We were stuck testing at 8.8 degrees angle of attack. That ended up being fine, though, and we just modified our test somewhat to work around that limitation. Instead of photographing one slice of wake at a bunch of angles of attack, we photographed a bunch of slices of wake at one angle of attack. Here’s what some of those images looked like, starting with a slice 2 inches from the trailing edge:

And one 14 inches from the trailing edge:

Flow viz assignment officially started this week! We’ve already been to the lab and gotten our first set of “data”, which looks something like this:

Most of the streaks don’t mean much, and are just the lines of smoke that we fed into the tunnel intake. That shaded, parabola-ish area directly behind the wing is what we’re interested in. It may not look like much here, but it’s actually the wing tip vortex. I can say this pretty confidently because of what we saw when playing around with different laser angles, but since we don’t have pictures of those other angles, you’ll just have to take my word for it. For now. The plan is to go back to the lab on Friday to get pictures from directly behind the wing, assuming we can find a way to trigger the camera inside the tunnel. My roommate has a fancy DSLR of his own that he’s able to remote trigger using an android app that takes advantage of an IR LED on the top of his phone. I’m hoping that:

1) That app works for the school’s Nikon and not just Cannon cameras, and

2) Someone in our group has an android with an IR LED.

The report is done! That means it’s time to do a bit of reflection.

I’m too exhausted to write an unstructured reflection - it’d just be a rambling mess. So I’m going to go ahead and answer the questions that were conveniently provided on the class news forum.

Q: How was your experience dealing with a lot of data from fairly straightforward tests?

A: For the pressure ports, it wasn’t that bad. I learned how to deal with structures from the cylinder lab, and having a constant naming convention throughout the weeks of testing made it easy to process all the data together. It was just a matter of getting used to a layer of separation between me and the results. In normal labs, like those in 304, I could just look at the data, feed it into an equation once or twice, and get some plots. For these data, I couldn’t look at them directly (at least, not meaningfully). Instead, I had to craft an interface of code to make sense of them for me. This code interface started off clean and streamlined, but quickly ballooned into a horrid, spaghettified web as more and more types of analysis were added. In the future, I’ll break things up a bit more: there’ll be a script that processes all the data into the workspace, and then each separate analysis will be contained in its own function. That way I don’t have to worry about them stepping on each other’s variables when I want to run more than one analysis at once.

For the force balance, I’d argue that that wasn’t a simple test. Mechanically, it’s easy to understand, but the data was a mess. Thankfully, Jake volunteered to process that for our group, so I don’t know just how bad it was. But processing that data would have involved factoring in the weight of the wing, the drift of the load cell, and the drag of the sting, along with all the normal processing. And we only got three days to do that. Yay.

Q: What was most interesting about these tests?

A: I’m really enjoying the chance to use professional quality equipment and automated data recording. It may seem weird at first, but reducing the measurement process to a mouse click actually reduces the tedium of labs, as compared with 304. It also takes away a lot of the excuses we used in that class to justify our poor results, which is probably also a good thing. We’ve had to turn a more critical eye to the actual experimental setup and the conditions in which tests were run to find sources of error, rather than just blaming the guy holding the anemometer and moving on.

Q: What’s the deal with Structures:

Spent yesterday out at the Mojave desert with CPSS testing our latest creation:

It’s a 13 foot rocket, designed to test our recovery system for the IREC competition. The flight went beautifully, and we got some cool data back from the IMU I built!

Acceleration in G’s/s, angular rate in G’s/s, and magnetic field strength in mystery units.

Forgot a plot! Altitude from the barometer (in meters):

Note that the time range at the bottom of this plot is longer than the others. All the other ones cut off shortly after the drogue deploys, while this one captures landing as well.

We’ve done a fair bit of analysis on these plots already, but it’s all about the dynamics of the rocket and not about fluid flow, so I’m leaving it out of this blog.

Force Balance

Force Balance!

After some mishaps earlier in the week, the force balance was working today! We ended up gathering data with another group, since they lost their testing time to troubleshooting. We only took data on the larger finite wing, and are going to share data with the group that took data on the smaller one. We mostly used their naming convention for the data files, but tacked on the time the data was taken to the end of the file. This was to help us compensate for the drift Doig warned us about in the load cell when we code up the data analysis later. Unfortunately, no one posted anything about the data the force balance generates on the forum, so I wasn’t able to program a force balance script before we went in to take data. We just had to hope we were getting good readings. For what it’s worth, though, the linear drive is pretty cool. It’d be neat if the linear drive and stepper motor could be matched in speed, though: that’d make it possible to continuously vary the pitch of the wing without it moving in the tunnel. That feature would only be good for flow viz, though, since the data from the load cell gets clouded as the drives move. 

Not Force Balance

Last post I briefly mentioned the wake rake, and how it had shifted from before. Well, now we’ve got results to show for it.

This plot compares a stalled wake profile (18 degrees) for the center and wall locations of the wake rake. Ignoring the region of the wake that has no probes, the plots are exactly the same. This means that there’s not much of an effect from the side walls of the tunnel on the flow field. At least, not an effect that extends out to four inches from the wall. 

I’ve also got some drag plots from the wake rake data. Here’s one of the rake drag plots and the pressure port drags to compare:

They follow the same general trend, but the bottom of the wake drag curve is a lot flatter than the one for the on board pressure ports. It also contains slightly larger error bars, since the pressures in the wake were more unsteady than those on the surface of the wing. What’s odd about the lower curve for the wake drag is that it’s supposed to represent the total drag of the system, whereas the pressure taps should only capture pressure drag. If you tried to back out friction drag by subtracting the upper from the lower plot, you’d find that friction drag is negative. It could be that the pressure drag plot should actually be more similar to the plot below, but is being thrown off by a couple wonky ports. I believe I mentioned this a while ago when we first got pressure data, but there are one or two suspicious ports on the bottom of the infinite wing that read higher than it seems they should. As the wing is tilted up, they’d contribute more to the drag calculation, creating an apparent rise in drag. The other features of these plots, like the location of negative and positive stall, as well as the large stall error bars, seem to match up nicely.

Vlow Viz Prep

After the lab, Jake and I did some testing with the fog machine for the flow viz project. I have a handful of purple lasers that we could potentially turn into sheets. Another bonus of the purple wavelength (405 nm for the nerds) is that it causes some organic compounds to fluoresce. We were thinking that we could get brighter smoke trails than the green laser sheet by adding fluorescent dye to the smoke. We found some interesting, but inconclusive results. The smoke fluid seems to be already vaguely fluorescent: shining the laser through very concentrated smoke results in a slightly bluer beam. However, adding the dye to the smoke doesn’t seem to boost this effect much. We didn’t add very much dye, since we were concerned about possible health hazards. To the eye, the laser beams still seemed dimmer than the green laser. But then, Jake and I pulled out our phones to document the experience and noticed something interesting in the pictures: the beam was much brighter!

Unfortunately the Force Balance wasn’t ready to test last week, so we’ve done some extra testing at the stall angle to flesh out our data a bit. We decided that, with the current angle measurement setup, we could get half-degree resolution. So we did. Speaking of the angle measurement setup, here’s the next installment in my continued documentation of that device:

Someone keeps removing my handiwork! Well, it probably keeps falling off. Either way, Isaac took a stab at it this time, and came up with this.

The plots we got at the half angle resolution look pretty good:

You can pretty cleanly see where separation happens in each case. Except, there’s something odd here. The plots are grouped in columns, such that the Cl and Cd plots on top of each other are from the same trials. But the jump from separation happens at different times in Cl and in Cd! This hasn’t shown up in any of our other trials, or at least, not enough to be noticed. Another interesting feature of this, though, is that the large error bars still line up. This seems to suggest that the drag coefficient spikes to stall levels right before the flow actually separates. For the moment, though, I don’t have any plausible theories for why this may have happened. 

The other thing different about this trial is the position of the wake rake. Instead of the center, it’s mounted about 4 inches away from the tunnel wall. More on that to come once I’ve got a script to better deal with that data.

I think I’ve already addressed my specific concerns about testing this week (error, reynolds matching, rake data...) so I’ll just take this time for a broader reflection on where we’re at after the first half of NACA 4412 testing.

The most interesting part of these labs had been seeing how all the standard wing section performance charts are made. We used the Theory of Wing Sections book a fair bit in 306, and I just assumed it was one of those things that was best left to professionals. Even though our results aren’t showing me anything I haven’t already seen, it’s actually really helpful to be able to see how these sorts of established references were created. 

One of the most difficult parts of these two labs has been dealing with the massive quantities of data we take in. I’ve gotten a lot more familiar with structures in Matlab, but even so, it’s been tough to introduce enough flexibility into to the code to handle things like the presence or absence of the wake rake, different sets and quantities of angles measured in each set of data, and different mixes of desired outputs. Right now I have code that analyzes the data from this week, and a separate program that churns through data from last week. I’m not looking forward to combining all that into one program.

The biggest improvement since the cylinder lab is the familiarity we’ve all gotten with the lab equipment. For thy cylinder lab, quite a lot of our time was spent trying to understand how the equipment worked, and figure out a system to use it efficiently. Now, we can walk into the lab and be taking data within a couple minutes. As far as experimental improvements, having more pressure taps is nice. Even though there might be a wonky transducer for one of the ports, it seems to have very little effect on the final Cl and Cd data. With the cylinder, though, one dud port affected our results quite a bit.

Both the most baffling and most satisfying thing about our results is the absurdly low error. Close to stall, the error bars expand a fair bit as they should, but when the flow is attached, our error bars end up looking more like error lines. This isn’t necessarily a problem we need to solve, but I want to confirm these results with other groups (or TAs, or Dr. Doig, or anyone who will listen).

Just a quick update: our Cd and Cl plots have error now! It’s shockingly small, though. Here’s a look:

The error bars seem to vary in size correctly, with the largest error happening right at separation. The size of the error may have to do with how it was propagated through the calculations. Isaac and I thought of two ways to do this. 1) Calculate Cd and Cl for each set of pressure readings in a frame. 2) Calculate the standard deviation for pressures at each tap, then propagate those deviations through as if they were pressures. This graph was made using the second strategy, since it was the easiest to code. I’ll go back and do the other one now, though, and hope it has more error. Everyone knows that less error is better, of course, but having error bars this small is making me really uncomfortable.

EDIT: The other version

Apparatus

When I went into the lab today, the first thing I did was check to see if my blue sticky note was still on the angle indicator. To my dismay, it was gone! someone had rigged up this as a replacement:

I have two issues with this setup. 1) It’s ugly. 2) It’s clearly sloping down and left. So I replaced it with another sticky note cutout, starting at the base of the red line on the right and ending by overlapping the degree markers on the left. Unfortunately, I forgot to get a picture of this vastly superior setup, so you’ll just have to trust me on this for now. I may come back and edit this post if my change is still there when I’m next in the lab.

Data

We have data! The new thing this week is the wake rake, so here’s a plot of some wake rake results:

As with all of the mass-overlay plots, its’ not super readable, but I like these ‘cause of the pretty colors. They’re good for quick, flyby impressions of the data, showing  generally correct pressure trends behind the wing, with the separated flow causing a giant low pressure zone in the wake. 

Our Cd and Cl plots are pretty similar to last week’s, so I’ll just include one. The only difference is the higher resolution sampling around points of interest. It’s especially visible around the negative alpha stall point in this Cd chart:

Lab 1 Follow-Up

Before getting into the lab today, I’ve got a couple things to wrap up from last week. First, we have Cd and Cl plots! Here’s a look at one each of those: 

As per Dr. Doig’s suggestion, we’re going to swap out the V in the titles with Re. I’m just now noticing I should add labels, too. Until then: the y axis is the coefficient, and the x axis is the angle of attack. We’ll use these plots to get an idea of when stall is occurring in each case, so that when we take data today we can take finer angle increments.

We’ve also heard from some groups that one of the lower wing ports is reading incorrect values. The port they’re concerned about is right at x/c = .1 in the plot below:

It looks like the transducer at this location might be a little too sensitive. When the trend it belongs to is negative, it’s even more negative, and vice versa for the positive trends. However, this discrepancy doesn’t seem to impact the Cd and Cl plots much, so I won’t worry about it for now.

Lab 2 Pre-Lab

Our first day of testing went well, especially considering that, as the first group in the tunnel, our planning time cut into our testing time. We’ve even got some preliminary plots of our data:

They’re not very helpful. We’re working on creating Cd and Cl vs alpha plots to better see what happens as the angle of attack increases or decreases. But I’m getting ahead of myself.

Before the Test

Before testing, I put together Matlab code to automatically pull our data files into memory, then compute the above Cp vs x/c plots. I had initially programmed it to group plots by angle of attack, but after we decided what to test, I changed the plots to be grouped by speed. 

One of my roommates (hi Paul!), who’s in the Monday/Wednesday section, tipped me off that the angle of the wing was difficult to read due to a gap between the degree markings on the wing and the indicator on the wall. So when I got to lab a bit early, I decided to check for myself. Sure enough:

There’s almost a half inch gap between the red indicator and the degree markings (except zero). So I grabbed a sticky note, Kevin pointed me towards some scissors, and I added this:

Now we could measure the tunnel angle by lining up the degree markings with the top of the sticky note. Even if the note isn’t perfectly level, it’ll still make sure all of are measurements are the correct angle apart, if not quite the correct absolute angle. Looks pretty straight to me, though.

The Experiment

Once I set this up, my teammates started showing up. We decided to take data to allow us to investigate two phenomena: zero lift alpha and the stall angle. For zero lift alpha, we set the bottom of our angle range to -10 degrees, a bit below where the charts say zero lift lies. For the stall point, we incremented the wing up towards 20 and then back down, so we could see how the point of separation/re-attachment changes when approached from different directions. We tested this at two different speeds: 12 m/s and 18 m/s. The 12 m/s speed was chosen so that we could test the same Reynolds number with the finite wing, which has 1/2 the chord length and can only be tested up to ~25 m/s. 18 was chosen just because. So, putting that all together: we rotated the wing from -10 to 20 degrees in 2 degree increments, then back down again at both 12 and 18 m/s. We hope that, in analyzing our data, we’ll see roughly where separation and zero lift are occurring, so that we can sample with finer resolution around these points.

Results

Report done! Here’s some graphs.

The Data

First, individual comparisons of each scenario against the inviscid pressure distribution. 

Low speed, smooth cylinder

Low speed, rough cylinder

High speed, smooth cylinder

High speed, rough cylinder

All together now:

Sorry, information overload, I know. So what does it all boil down to? Well, the graph of all the curves combined offers the clearest comparison of the behavior of all four scenarios. Looking at how long each plot (roughly) follows the inviscid curve before leveling off shows how long the flow managed to stay attached in each case, and looking at the height of each plateau tells us about the pressure imbalance between the front and back of the cylinder. Low speed smooth flow separated first, followed by low speed rough, then by both of the high speed trials. The strength of the low pressure zone behind the cylinder seems to rank: LS rough, LS smooth, HS smooth, and HS rough. The first two end up being reversed in the drag rankings, though, since LS smooth’s low pressure zone is so much larger.

Drag coefficient rankings:

LS smooth: 2.24, LS rough: 2.12, HS smooth: 1.14, HS rough: 1.06

These drag numbers were calculated by discretely integrating the pressure coefficient numbers around the cylinder using the trapezoid rule.

Quirks

There’s some weird stuff in our data. First, take a look at the size of the error bars in the LS Rough plot from about 90 to 270 degrees. At either end of this range, we expected sizeable error bars, since the exact point of separation shifts around as the cylinder sheds vortices. But in the middle? They should be small, like the LS Smooth plot. The reason they’re not is the ports themselves. The first half of this range was covered by ports 1 and 4, and the second half by ports 4 and 3. The reason we chose to measure over a rotation of 180 degrees instead of just 90 was because we noticed a large gap between the measurements of ports R1 and R4 when they overlapped for the first time at 90 degrees. It seems like port R4 may have been partly clogged or leaky, since there’s a gap between the data it measured and either port it shared coverage with. This can also be seen to some degree in the HS Rough trial.

There’s also asymmetry in our data. It’s especially apparent in both high speed trials, where the pressure around 270 degrees is noticeably lower than at 90. This is likely due to the presence of the tunnel wall, which was closer to the cylinder at 270 degrees, artificially raising speed and lowering pressure. If we were to do this test again, we might try a smaller cylinder. Initially I was thinking we should do a better job centering the cylinder too, but having it ever so slightly off is actually helpful - we wouldn’t have known about the wall influence at all had it been dead center, but it would still have affected the experiment.

Conclusions