A brief look at what I'm doing. For a description of my project, please start by reading this excerpt from my original project proposal.
The somewhat unfortunate first comment I get when I say that I'm researching odor-sensing in moths is, "You're an aerospace engineer. What's that got to do with moths? Isn't that biology?
The short answer is that I'm not working with moths. I'm working with the odor.
In order to study something like an animal's ability to track odors, it's necessary to consider a system that contains not only the animal but the environment in which it is tracking the odor. In the case of a flying manduka moth, it's clear that any theory of how the animal is tracking odors must take the fluid (i.e. air) through which the moth is tracking the odor into account. If a biologist's idea of how the moth tracks the odor doesn't match the fluid mechanics of how the odor moves through the air, then it cannot explain the moth's behavior.
My goal, therefore, is determine how the odor the moth tracks moves through the air. I need to determine the structure of the fluid flow, or, in other words, I need to know what the flow looks like.
Researchers have come up with many ways over the years to measure fluid flow. For this project, several methods were considered, including using smoke to "dye" the flow and simulate odor. In the end, we chose to use ionized air to track flow. Visually speaking, this is rather unexciting. You can't see the ions released into the air of the wind tunnel, but because the ions are essentially an electrical current, our instruments can pick up the signal very quickly, just the way the moth can pick up odors instantaneously.
One disadvantage to using ions--aside from the obvious inability to see them--is that ions repel one another, whereas odor does not. But, over short distances with reasonable wind velocities, there's not really enough time for the ions to repel one another so much that they alter the basic structure of the flow.
I've basically inherited a set-up called RoboMoth, which is run out of biorobotics. The purpose of RoboMoth is to create a robot that tracks the same way that moths do. Since we're still not sure of how moths track odors, that's a bit up in the air. But, RoboMoth does provide me with sensors for measuring those ions I was talking about.
The following list contains the equipment/software in my system. An asterisk (*) denotes pieces that I added to the existing system.
Words, words, words. Here are some pictures to ease your eyes.
This is about as close as I come to getting a picture of the entire wind tunnel at once. You can see the test
section on the right and the computer I use to control everything off to the left. The black box above the monitor is
the control for the wind tunnel.
A look inside the test section. The vertical arm in the foreground is part of the gantry. The little arm sticking out
from it holds the antenna that serves as my sensor. The foil-clad object in the background is the ion generator.
You can start to see the mass of cables and wires that is the motion control side of things. The white box
in the foreground is the control for the ion generator. Behind that, from left to right, are the pin-board (which transforms
the signal before it goes to the motion controller in the computer), the power supply, and the amplifier. The computer, half
open for easy access to its hardware, is on the right in the foreground.
The ion generator again and the signal conditioner sitting on the floor below it.
In the foreground, you can see the mass of wires that is the pin-board. Behind that, the power supply, and beyond that, the
amplifier.
Before I continue, I should say a little bit about what all these things do. I basically have equipment that does three things: data generation, motion control, and data acquisition. The wind tunnel and ion generator fall into the first category; the gantry, amplifier, motors, power supply, pin-board, and motion controller all manage the motion control. The antenna, signal conditioner, and data acquisition card all manage the data acquisition.
One thing I need to be able to do to run my experiments smoothly is control all of this equipment at the same time. This is where LabVIEW comes in. Having hooked new data acquisition hardware in, it became necessary for me to control all of that as well as the motion control from the computer. The data generation hardware--the wind tunnel and ion generator--has to be switched on by hand, but that's no big deal.
The way I'd like to run my experiments calls for automation. I need to be able to tell the equipment what sort of motion I want it to make and how many data points I want, and then have it run, stopping and recording data at each point without my intervention. Therefore, I needed to construct LabVIEW programs that will do this.
Unfortunately for me, the motion controller wasn't made with the intention of communicating through LabVIEW. It has its own terminal program and programming language that the controller uses.
This screenshot shows the code necessary to instruct the motion controller to turn the motors on, run its homing routine,
and move 0.1 inches in the positive X direction. The code reads: SH; XQ #HOME; PR 1000; BG; Not particularly
user-friendly.
LabVIEW uses programs and functions called VIs (Virtual Instruments), and I found a few that are designed to allow the motion controller to communicate with LabVIEW. Using these, I've been working on several programs, including the following one.
This is a much more user-friendly interface, even though it's still cluttered with some debugging features like the
bits labeled "Motor Response", "Broadcasted Command" and "Intermediate Postions". This program has the ability to turn
the motors on and off, and perform basic motion. The user can input the final position (in inches rather than the encoder
counts the motion controller uses) in X and Y and the number of data points that should be taken.
The program then calculates the intervals through which it should move, executes a move, pauses (eventually it will record data during that pause), records the position of the antenna, and continues until it has completed the ordered routine. Right now, the program isn't complete because I'm having problems with the motion controller losing encoder counts and, therefore, ending up in a different place than where it's supposed to be.
To give an idea of the programming side of things, here's a screenshot of the backend of the program:
LabVIEW is a bit odd for me to work in because it's a graphical programming language. Programs end up looking
a lot like circuit diagrams, actually. Here you can see a small portion of the program whose UI is shown above. This frame
shows the portion that sends orders to the motion controller. There are other frames that handle things like opening and
closing communication with the controller, recording data positions, etc. Although the inputs for data acquisition are
present, I haven't wired them up yet.
The unfortunate truth about trying to run experiments with a lot of equipment is that nothing ever works as intended. In my case, RoboMoth's motion control system seems to have problems keeping track of encoder counts, which is what the system uses to tell where it is in relation to where I told it to be. For example, I can turn the system on, run its homing routine to set its tuning and directional limits, then I can order it to move two inches to the left and tell me its position. The position the controller returns will be very close to two inches, if not exactly two inches in encoder counts. If I get up and measure the distance the gantry has moved, however, it's more likely to be 2.25 inches or 2.125 inches. To make matters worse, the system is never consistent in the amount that it's off by.
My suspicion, therefore, is that the system is losing encoder counts, so that it doesn't know that it's already moved as far as it was supposed to. This could be caused by noise on the encoder lines or by a faulty encoder. Unfortunately for me, I've never been much good with complex circuits and, as the pictures above show, there's a lot to try to keep track of with RoboMoth. Things have gone very slowly the last two weeks or so as I try to figure out where the electrical problem is.
Even though I haven't had the chance to do much more than a couple of very basic experiments, this summer has nonetheless been rewarding. This is the first time that I've really been in charge of my own project. Although I get direction from my advisor, Dr. Ed White, I'm very much the one determining what I do each day, how I'm going to handle experiments, and so forth. There aren't any grad students working with me, and, unlike many undergraduate lab courses, there are no step-by-step instructions on how to perform experiments, nor is there anyone handing me a fully-completed set-up where I just press buttons. In that respect, this experience has been enormously helpful. Since I intend to pursue my studies in graduate school, this work is something of a primer for that.
And, amazingly enough, all my frustrations haven't put me off from studying fluid mechanics in graduate school!
Last updated 15 July 2005