Week 3 was an amalgamation of testing and planning, though I must say the interesting parts only seemed to occur during Group 4′s time in the wind tunnel. I was somewhat intrigued by this portion of the lab, given that we were finally putting a quantifiable number to the size of the wake behind a wing, as well as the amount of drag that friction actually contributes to the overall drag number. I was back on data duty again, which means I was also on “write a MATLAB script as quick as possible to verify the data” duty. Once the data for the first set of probe measurements had come in, I was able to test it out. The result was something like what is shown below:
I don’t know about you, but that looks like a pretty good wake profile to me, though the data on the left side seems a little sparse. Having developed that code, I decided to take a bit of time to clean my code up so that instead of four for-loops I stow all the repeated calculations in a separate function to be called as needed. Once that was all coded up, I got some pretty good data except for one angle of attack in particular, α=6°.
Uhh, that’s definitely not right. I noticed pretty quickly, however, that the values for total pressure were all within 4 or 5 Pa of each other, which, upon inspection, was also incredibly close to the freestream total pressure. Clearly, we missed the wake somehow. Looking at the probe position, I can see that the probe swept from a position of 316 mm to 331 mm, which was actually pretty far away from the measured location of the trailing edge using the probe (about 308 mm, as I recall). It wasn’t until I had finished my code toward the end of the testing period that I noticed this mistake, so there was what some may call a mad dash to collect the rest of that data.
There are some pretty obvious signs that we had an issue with this run. There’s no obvious lowest point in the data, which could have been solved by moving the probe a little less through the wake (if we had time). There is also a pretty obvious grouping of data points toward the right of the plot, which indicates where we were taking our data before we noticed the mistake.
The rest of the wake plots look much better, however, and it should be pretty easy to grab accurate drag data using one of the other Josh’s code.
Part 2 of Week 3 tested our creative skills as First Team=Best Team had to decide what to do for our flow visualization project. A sort of running joke in DBF is to just chuck some VGs--vortex generators--on a wing to improve the flying characteristics. We decided to see if we could use flow visualization to analyze and quantify the impact (if any) that VGs have on the performance of a wing. Namely, we want to look at the change in the α that the flow detaches halfway (at x/c =.5) from a NACA 4412 wing, where the flow starts to detach, and (if we have time) the frequency of vortex shedding, all of those things compared between a wing with and without VGs. In dividing the labor for this project, I was saddled with the task of researching vortex generators.
Probably the most important things to do with VGs on a wing are their location and size. Too big and they will poke out of the boundary layer and add drag, and too small and they won’t energize the boundary layer enough to obtain the desired effect. The location is also important, though I have a feeling we won’t be able to get too detailed of data, and will have to be satisfied sticking the VGs on our wing in one location and seeing how that impacts performance.
So, how big will our VGs be? Will they be like those on a plane, small relative to the size of the body?
Or will they be like those on a Subaru WRX or STI that won’t come close to sniffing a track?
Some basic hand calcs will give a good estimate of the boundary layer at various points on our wing, and we will use that number to determine how big to make our VGs. Wing construction isn’t supposed to happen until Sunday, so we have a bit of time to work out those numbers.