Statistical Analysis of Go/NoGo Gages

Background and Theory of Go/NoGo Gages

The use of Go/NoGo gages is quite prevalent in any type of manufacturing environment. Essentially Go/NoGo gages are representations of the respective maximum and least material conditions (MMC/LMC) of a feature. These physical representations of the MMC/LMC are then mated with the feature to assess its quality.

For example, if you think about a simple plug gage, the Go side must fit into the hole to pass. If the hole is too small (exceeds MMC) the Go gage will not fit and the part will fail. Conversely, the NoGo gage must not fit in the hole to pass. If the hole is too large (exceeds LMC) the NoGo gage will fit and the part will fail.

In theory, this principle seems quite straightforward. However the rose colored glasses are shattered when it is revealed that the gages, just as the features they intend to assess, are imperfect. Thus the gages themselves must then have tolerances. This tolerance, known as a gagemaker’s tolerance, is typically around 10% of the feature tolerance. The 10% is then split evenly among the Go/NoGo gages. For example, on a 2.000+/-.005 dimension, the gagemaker tolerance would be .001, and the tolerance for each the Go and NoGo gage would be .0005.

The only remaining question is the bias of the tolerance. The typical bias selected is the most conservative; i.e. it is more conservative to risk rejecting good product than to risk accepting bad product. This will result in the Go gage tolerance range being just within the feature tolerance range, and the NoGo gage tolerance range being just outside the feature tolerance range.

So just as your product has a yield, the gages themselves will also have a yield expressed as False Rejections/Total Rejections. Obviously if the gage is your only way to assess the feature, you will never identify any False Rejections, so a 3rd party measurement some orders of magnitude more accurate than the gage would be needed to make this determination.

Problem Statement

Gages are typically designed/selected based on this 10% rule. I haven’t really found any background on where this originated, or if there is any statistical theory justifying it. From what I have found, it is more of an empirical finding that the 10% rule maximizes yield while keeping gage costs manageable.

What I am interested in is the statistical theory behind this gaging process. In other words, is it possible to analytically calculate the probability of these False Rejections? If this were possible, one could better justify their gage design/selection, or possibly improve yield or reduce gage costs for a given application with knowledge about the distribution(s).

Assumptions

For this analysis, I have made the following assumptions.

• All random variables are normally distributed.

• The means of the gages’ random variables are at the center of their respective tolerance ranges.

  • I’m using this assumption in lieu of having any actual information on the distributions of gages.

• All gages are made with 6Sigma manufacturing processes.

  • I’m using this assumption in lieu of having any actual information on the distributions of gages.

Analysis

Let A be a random variable describing the dimension of the feature. Let G be a random variable describing the dimension of the Go gage. Let N be a random variable describing the dimension of the NoGo gage.

For an internal feature, the Go gage passes when it fits inside the feature, i.e. A>G. The NoGo gage passes when it does not fit inside the feature, i.e. A<N. Thus we obtain the following:

P(Pass_Go) = P(A>G)

P(Pass_NoGo) = P(A<N)

The probability P(A>G) may be obtained by double integrating the joint PDF, F_AG(a,g). Because the feature dimension and the gage dimension are independent, the joint PDF may be expressed as the product of the individual PDFs.

F_AG(a,g) = F_A(a) * F_G(g)

Next we must double integrate this expression. Before integrating, we must understand the space we are integrating in. This joint PDF occupies (a,g) space. Each point on the (a,g) plane represents a combination of the dimension of the feature (a) and the dimension of the gage (g). We are only interested in the case where a>g, and both a>0 and g>0. If a is taken to be the horizontal axis and g the vertical axis, this corresponds to the area under the curve a = g (Fig. 1).

Figure 1

Matlab Script

I wrote a simple Matlab script to visualize the joint PDF. The next step is determining how to evaluate the double integral over this shaded region. I don’t think there will be an analytical solution, so barring that option the next logical alternative is numerical integration. However I’m not sure how numerical integration works over semi-infinite regions such as this one.

Github Link

How to Weigh Your Head: Pt. 1

Background

During my time at Boston University, I was a Teaching Assistant for the Product Design course required for all mechanical engineering majors. In contrast to our other engineering courses which taught scientific principles, this course focused on exposing students to structured ideation methods, materials/design selection, functional analysis and decomposition, and how to generate effective engineering problem statements.

The Question

The professor, Greg Blonder, posed a question to the class during one lecture as an exercise:

How could you determine the weight of someone’s head, without removing it?

This question seemed underwhelming at first, but the as the groups discussed their ideas, they began to realize a solution was not trivial. Their solutions roughly fell into two categories:

1. F = ma, f = (k/m)^(1/2)

   These involved resting the person’s head on a scale or measuring acceleration response to a known force. The main problems with these approaches are that one must make many assumptions for the reaction forces and moments/damping ratios/spring rates in a person’s neck. Additionally, some of these procedures may be harmful/intrusive to the subject, as they involved vibrating the subject by their neck, whacking their head with an instrumented hammer, rapidly rotating the subject, and administering muscle relaxants to the neck muscles. However depending on your definition of success, these could be interpreted as viable solutions. The question was open ended…

2. Fluid Displacement/Buoyancy

   These methods generally involved submerging a person in water up to their neck, or holding them upside down so only their head is underwater. All of these methods fall victim to the common fallacy that buoyant force informs the weight/mass of the submerged object. This is of course not true; the buoyant force is simply equal to the weight of the water displaced and does not depend on the mass of the submerged object. The displacement measurement from this method informs the volume of the head, and combined with density one can obtain mass. However one must either devise a way to measure the average density of someone’s head, or make an assumption. Again depending on the definition of success, assuming the average density and simply measuring volume could be a viable solution for someone’s application.

When the professor revealed his solution, it became clear that class had overlooked one key idea: remote sensing. With remote sensing techniques, it is possible to measure properties of matter without making physical contact. These technologies work by analyzing the EM or acoustic signals propagated by the test article to inform its properties. This problem is in a way already solved by the various medical imaging technologies such as CT scans, MRI, and ultrasound. Once the subject is scanned, the only remaining question is debating where the head ends and the neck begins. But I believe that is outside the scope of this exercise.

Professor Blonder stated that it would be theoretically possible to apply the principles of remote sensing/medical scanners to a more practical, ‘backyard’ solution. His solution, informed by the principles of CT scanning, was to ‘scan’ the subject by placing them on a balance beam at various positions w.r.t the fulcrum, and recording the mass of the weight required to balance the beam at each position. The resulting system of equations could be solved to determine a mass per length vs. length profile of the subject, and by integrating/summing over the length corresponding to the location of the head, the mass of the head may be determined. This is as much detail as he gave. He also stated that one could perform multiple scans at various angles and transform the data into an 2D density map. This is of course the working principle of a CT scanner.

The Project

I found myself still thinking about this exercise years after graduating, and decided to try and pick up where the professor left off. The goal of this project is to assess the feasibility of the method described above for determining the mass of a person’s head. I’ve done some preliminary research on this topic (mostly reading about the principles of Computed Tomography and writing way too many mass balance equations) and have identified some key objectives/stepping stones:

1. Solving the System of Equations for a Single Scan

   This method begins by modeling the human body as a rectangle divided into n equally sized slices of uniform density. Because the density of each slice is uniform, its CG is at it’s midpoint, thus the CG location for each slice is known. The mass/density of each slice is still unknown. This model makes sense if you imagine the limiting case as n approaches infinity; the slices are so thin that their density will essentially be uniform. The ‘body’ is then placed on the balance beam at a known position and a known mass is added to the opposite side at a known position to balance the moments. Summing the moments on each side of the beam, we obtain an equation with n unknowns (the masses of each slice). Thus if you repeat this measurement n times at n unique positions, we end up with a system of n equations with n unknowns. So it seems the problem is solved.

   However upon further thought, I recalled my linear algebra professor’s musings on linear independence and matrix invertability. Reexamining the model, it occurred to me that the equations generated may all be linearly dependent, as the initial equation is just shifted incrementally to create the subsequent equations. The first task will be to determine whether or not this is true. If the equations are linearly dependent, then the matrix cannot be inverted, and Ax = b cannot be solved. Based on a simple hand calc, the method works for a 2x2 matrix, but I’m not sure about larger matrices. Looks like I will have to dust off my linear algebra textbook.

2. Applying the Inverse Radon Transform to Produce an Image

   Assuming the matrix is invertible and the system of equations can be solved, I will write a Matlab or Python script to scan a virtual object at various angles using the scan method developed in objective #1. These scans will then be lined up to construct a sinogram. Each scan represents one column of a sinogram. The Inverse Radon Transform (IRT) will then applied to the sinogram to obtain an image. A filter must be applied in fourier image space to compensate for the center of the image being oversampled.

   I am fairly certain most image processing libraries will have built in functions for the IRT and fourier image space filtering, but I’m not sure about a function to assemble a sinogram from a series of data from multiple scans. I may have to write that function myself.

3. Evaluating the Success of the Solution

   Lastly, I will attempt to estimate uncertainties for a theoretical measurement device, and calculate the theoretical resolution and accuracy of the device.

   Off the top of my head, some of the sources of uncertainty/error will be friction in the fulcrum, position measurement of the body and the balance masses, mass measurement of the balance masses, nonuniform density of the beam and the balance masses, movement of the subject (especially during multiple scans at various angles), and scan angle measurement. There will also be errors from the IRT and image space filter but I’m not yet sure how to quantify those. I suspect it will be quite challenging to figure out how to propagate the base uncertainties of mass and position all the way through the IRT and filtering steps.

   Assuming I’m able to propagate these uncertainties, I will also try to calculate the resolution of such a device by propagating the resolutions of various COTS methods for measuring position and mass. This will let us evaluate the success of this solution and allow for comparison to other solutions.

Stay tuned! More to follow.

MATLAB Project: Membrane Vibration

I was able to get the membrane vibration to work for a rectangular membrane. The equations are quite different for a circular membrane, so I'll need to write a new function for that. I'm still working on implementing this function into the GUI.

Fundamental Mode

p = 1, q =2

p = 2, q =2

p = 4, q =2

p = 3, q =3

Kinematics of Wheeled Mobile Robots Pt. 3

Our team finally got the robot moving and steering! Which means it's finally time for me to start the implementation process of the kinematic and control equations. To further verify and help prepare for the implementation, I made a little simulator in MATLAB to help visualize how the robot will move given certain (steady state) commands. Transient commands are a whole other issue, which I may discuss later. 

The structure of the top level code is simple. It defines the parameters of the robot and of the simulation, and calls the swerve_command function. This function performs the inverse kinematics and spits out the wheel angles and speeds, as well as the position (x, y, theta) information for that time step. Over several time steps, the robot will move. If steady state inputs are held, the wheel angles and speeds will remain constant, even if the robot itself is executing some curvilinear motion. The robot is plotted at each time step. To verify the wheel angles are correct, you need to visually confirm that the wheels are tangent to the path taken by the wheels in each snapshot. 

Confirming the wheel speeds is more difficult. For any type of pure translation all the wheel speeds just need to be the same. This has been confirmed. If there is any type of rotation involved, the wheels will orbiting some central point. If the location of the point is known, then the radius to each wheel can be found and using the omega = v/r equation you can confirm that all the angular speeds about that central point are equal. This is hard to do currently because we are normalizing all our speeds because they are simply throttling values which will be sent to the motors. We do not know exactly what speeds they will spin at. However, the ratios of the speeds are telling. What we know is that the wheels on the largest radius of the orbit must have the highest linear velocity, and the wheels on the smallest radius of the orbit must have the smallest linear velocity. This allows all the wheels to have the same angular velocity around that central point. As you can see from the photos, this phenomenon is evident by the colored velocity vectors. 

There is something funky going on with the way that the motion of the robot is plotted. The wheel angles and speeds look okay, but when I try to plot the motion some of the components of the motion (X and rotation) have the wrong sign and it looks like the robot is skidding across the floor. I haven't been able to figure out why that is yet. I have a feeling it's some kind of sign error but I haven't found it yet.

Open Issues:

1. Figuring out how to update the wheel speeds and angles while moving (transient command inputs)

2. Normalizing the wheel speed outputs to prevent speed commands to the motor from saturating

3. Finding the little sign errors that are messing things up

Bonus:

We also made a little case for the webcam BreakerBot will be using for the First Person View mode for remote operation. BreakerBot is watching you...

MATLAB Project: String Vibration

We recently covered vibrations of strings in my mechanical vibrations class. I decided to try and make a GUI to animate the vibration of the string. There are lots of options for changing the string properties and simulation parameters, as well as subjecting the string to various end conditions and combinations of initial conditions.

I hope to expand this simulation to animate 2-D membranes as well. It would be very cool to simulate how a drum head or the body of a violin vibrates in MATLAB.

MATLAB Four-Bar Linkage Design

The Product Design class I am a TA for had an assignment to design a four-bar mechanism to move a lid on a shipping container up and over so that it rested on the top of the container during loading. There was extra credit awarded to those who could analytically arrive at a design using MATLAB (or some other language). I made my own solution for fun and to check student's solutions. I tried to get it to plot each snapshot (in magenta) but it was not correct and I didn't have time to figure it out. 

So, here's how to design a typical four-bar linkage:

1. Define the desired locations of your coupler. You define two or three locations you want the coupler to travel through. My code only works with three locations.

2. Find the locus of points that is equidistant from where the crank connects to the coupler in each position. If two coupler positions are defined, the locus will be an infinite line (think of the intersection of two circles; connecting the two points forms a line). If three coupler positions are defined, the locus collapses to a single point. This point also happens to be the circumcenter of the triangle formed by the three vertices the bearing must be equidistant from. The bearing must be placed on a point on the locus. If the locus is a single point, your job is done. If the locus is a line, you must select a point on that line to be your bearing location.

3. Repeat step 2 for the points where the rocker connects to the coupler.

4. Once you have the bearing locations for the crank and the rocker, you can easily calculate the lengths of each link.

Learning to Use Simulink

For our senior design project, we are trying to implement a swerve drive system to achieve holonomic robot motion. None of us really know much about controls, but from the information we have gathered online, it seems advantageous to model our control system in Simulink before trying to implement it with code on our robot. Simulink seems pretty simple to use, at least for basic PID loops. If you have a block diagram for the system you want to model, you just drag and drop the blocks of the system and connect them together. You can change the parameters of the blocks simply by double clicking. 

I made a really simple one here of a basic PI loop responding to a step input. You can change the proportional and integral gains to tune the controller, if you wish. 

Here are my concerns regarding the Simulink model:

1. I don't know how to model my inverse kinematics with the standard blocks. Will I have to make my own custom block to do all the kinematics, or make each step of the equation a separate block?

2. How to get the angle of the robot with respect to the ground? In our robot, this will come from a gyro, but how can I model this in Simulink?

3. Step inputs and sinusoid inputs are useful, but it would be really helpful to model the input from our actual joystick. I need to figure out how to do that. There is a joystick block, but I have no idea how to use it.

4. We currently have no idea how to model the robot dynamics (the 'plant', in control theory lingo). This is the most important part. If your plant is inaccurate, your control will not work.

5. Where does the plant begin/end? Should we attempt to model the motor behavior in Simulink? Or make the motor part of the plant? I've found sources online that go either way.

So after a couple hours of playing with Simulink, I think I have solved issue #1. I ended up writing a custom Simulink block from a MATLAB function. It then compiles the MATLAB code into the block. I am making a smaller system to test the kinematics independently. I will check them with the graphs I generated earlier in the semester.

I sort of found a way around #2 for now by integrating the angular rate signal. But the angle from this is before the plant, so it is not really correct. But it may work for now, just to get the system to run.

The main problem I have right now is compiling the code from the MATLAB Function Block. The Simulink-compatible C-compiler is was not installed on my computer, so I had to download the Xcode app and use the compiler. But it's still returning an error, so there is something else I have to fix evidently. 

Kinematics of Wheeled Mobile Robots Pt. 2

I discovered a few minor issues with my previous derivation. I had not converted the unit vectors from one frame to the other correctly, and I left some of the expressions in the unit vectors of an inappropriate frame. MATLAB was used to verify the equations. Simple inputs were sent to the equations and various outputs were plotted for evaluation. The rainbow plots show the physical path of the robot in the XY plane. The color indicates the angle of rotation in degrees. The last graph shows my original eureka moment when I finally realized I fixed the problem. Previously, there was a cusp in the magnitude of velocity when it should have been constant. When I saw the constant red line, I knew I was on the right track. 

Because the control inputs are centered to the robot's frame, if you hold constant translational inputs with a rotation, the robot will end up taking a curved path. However if you hold constant translational inputs with no rotation, the robot will travel straight. This is shown by the graphs with no color change.

Kinematics of Wheeled Mobile Robots

After many discussions, our group has decided that four-wheel drive simply does not permit adequate control of the robot for aligning with the circuit breaker cubicle. So we are reverting to our original drive train choice: swerve drive. Swerve drive is a holonomic locomotion system in which each wheel can pivot about its own vertical axis. Using a swerve drive, the robot will strafe sideways along the face of the circuit breaker cubicle, detecting the edges of the cubicle and using those edges to laterally align the robot. Then, the robot will perform an angular alignment to the face of the cubicle, and advance forward to extract the breaker. The angular alignment and subsequent forward motion would not have been possible with a four-wheel drive system; as the translation and rotation of the robot are coupled.

I derived the inverse kinematics of the robot for our computer engineers to use in their control algorithms. The derivation is quite simple mathematically, but it can easily get confusing to understand from a physical sense. I like to imagine what I would experience if I were sitting on the different points where the wheels are located on the robot. This helps me to see why certain terms are in the resulting equations and verify if the results make sense. 

PDF derivation of the kinematics.

MATLAB Project: Aircraft Designer

This is the master program which all the functions described in previous posts feed into. This takes inputs from the fuselage designer, wing designer, and empennage designer and puts all the components together. The motivation for this project was to be able to quickly and easily iterate through aircraft designs. All of the performance calculations were done in an excel spreadsheet, but Excel is not good at making custom plots or managing data. This program receives the geometric parameters of the airplane calculated by the Excel sheet, and uses them to 'build' the airplane for visualization and accurate component layout.

The component layout in the spreadsheet does not account for the form of the volume components (passenger cabin, cockpit, galley, wing box, etc.). On more than one occasion we had designed a fuselage that seemed to contain all the components, only to realize that the calculated cabin length was longer than the fuselage of the aircraft! This program was intended to solve that problem by visualizing the components for instantaneous feedback on the quality of the layout. 

The other main goal of the program was to facilitate the rapid 3-D modeling of the aircraft. Unlike most other objects undergraduates are used to CADing, aircraft often have complex curvatures and geometries that take a long time to make manually. This program produces curves for the fuselage, main wing, and tail surfaces and positions them according to the design specifications. The coordinates for the curves are then exported as .txt files, which can be uploaded into SolidWorks as curves and lofted together. This drastically reduces the time required to produce a solid model and thus enables more rapid design iteration and evaluation.

I'd like to continue adding more to this program, but it looks like there simply isn't enough room on the UI to add more input boxes. Already, many of the parameters cannot be changed from the UI; the code must be manually altered. I was thinking of adding tabbed panels to increase the number of inputs possible, but from my [limited] research they don't seem to be well supported. I think this version should do for now.

MATLAB Mini Project: Propeller Design

As part of my ongoing aircraft design project, I wrote another MATLAB function to produce propellers whose cross sections could be exported for making models in SolidWorks. The function takes inputs from the design calculations of an Excel spreadsheet. The diameter of the rotor, the number of blades, the twist of the blade, and the airfoils comprising the blade are all used to determine the shape of the propeller. For now, only straight tapered blades defined by a root and tip airfoil can be produced. But this code serves as a first step for designing and plotting more complicated blades with curved planforms and nonlinear twists. Right now the twists are user defined, whereas in reality the twist is set to produce a certain coefficient of lift stated in the Hamilton Standard propeller efficiency chart; this is something else that must be accounted for in the future.

I considered having this function calculate all performance parameters of the propeller, but the only performance estimation method that seemed feasible was the blade element method. This method is far less accurate than the Hamilton Standard propeller efficiency charts used to calculate performance in the Excel sheet. So I decided to stick with the standard method of propeller sizing using the propeller charts and just let my program calculate the propeller's shape.

MATLAB Project: Fuselage Designer

This project builds off my previous MATLAB project for designing and making wings in CAD. I have added basic fuselage plotting capabilities. The user simply defines the maximum diameter and fineness ratios to determine the fuselage length. Then, 11 cross sections are defined by their widths and heights. The shapes of the cross sections are assumed to be ellipses. The tail angle can also be changed. Wing twist has also been added; root and chord angles can now be set.

10/14/15 - Added 3 additional plots: fuselage side view, top view, and max diameter section view. The program can now display seating arrangements, galley, and lavatory locations.

MATLAB Project: Wing Designer

Introduction

This semester I am taking an aircraft design and performance class. The term project is to complete a conceptual aircraft design - each group will be designing a different type of aircraft. Our group is designing an MSA, or Maritime Surveillance Aircraft. The purpose of this aircraft is to loiter for long periods of time at low altitudes to observe/monitor maritime vessels, act as an airborne control center for nearby aircraft, and even deliver payloads (sonobuoys) and ordnance (torpedoes, air-surface missiles). Our professor provided us with Excel spreadsheets that have many of the calculations programmed into them; our goal is to optimize the parameters to meet the requirements. We also need to produce a 3-D model of our design. This is where the Excel sheets lack in ability. They provide very rudimentary 3-views of the aircraft. I decided to use MATLAB to take the results from the Excel spreadsheet and produce coordinates for a wireframe model of the airplane, which could be loaded into CAD software and turned into a 3-D model.

Currently, my MATLAB program can only produce the wireframe of a wing (or any similar aerodynamic surface). I am actively working on expanding it to create fuselage cross sections which will be used to create a 3-D model.

Design

I adapted this program for one I previously made for an aerodynamics class. The inputs were reversed - for that class, the area needed to be calculated for a given wingspan, whereas in the design scenario the wingspan is determined by the area and the aspect ratio, so the inputs needed to be changed. I also added the capability to sweep the wing. I also added the a section on the planform view to show the MAC - this is an important thing to visualize. The 'Export' button creates .txt files with the tip and root airfoil coordinates. These can be loaded into SolidWorks or any other CAD program as a curve, and the tip and root curves can be lofted together into a solid wing. Then the wing is simply mirrored about the root to create the other half and complete the wing.

Capabilities

Plot any 4-digit or 5-digit airfoil (uses my airfoil generator function). Create basic trapezoidal aerodynamic surfaces with airfoil cross sections. Wing twist or washout, and angle of incidence (not visible in GUI yet). Parameters include NACA airfoil, wing reference area, aspect ratio, taper ratio, and LE sweep. Plots MAC and spanwise location of MAC. Export coordinates of root and tip airfoils to create a 3-D model in CAD software.

Improvements

The current method in which the wing is swept is inaccurate, as it 'drags' the tip rearwards (or forwards) to achieve the required leading edge sweep. However the wing should really be rotated such that the airfoils are no longer parallel to the airstream; this is what makes a swept wing effective. Rotating is difficult though, because then you have to account for the fact that tip and the root will be at the incorrect angle, and you have to adjust for that. This is okay to make a model for viewing/aesthetics, but I should look into updating this in the future.  I should also plot points on the quarter chord MAC as this is another important location. I will continue working on this GUI to add fuselage plotting capability. Also the wing washout/twist/angle of incidence parameters can only be accessed from within the code; I need to make boxes on the interface to change these parameters.

MATLAB Project: Boids, AKA Artificial Swarm Intelligence Simulator

If you've ever seen a flock of starlings flying in seemingly effortless coordination, or a school of fish avoiding some hungry sharks, you know what swarm intelligence is. The mesmerizing patterns make it appear like the flock or school is one (or several) cohesive unit(s) being guided - but it's not. The amazing thing about swarms like these is that there is no 'leader'. These patterns arise naturally as a result of a few simple rules that each swarm member follows. For example, each member in the school of fish wants to get into the center of all the other fish, to avoid the predators. In the flock of starlings, each bird has this centering tendency, but also must maintain some separation from other birds to avoid crashing. The swarm members also tend to travel in the same direction/speed as the other swarm members. For example, if they see one member turn, they'll turn too. 

These are the fundamental rules that govern flocking/schooling behavior in animals. Using MATLAB, I made a simulation of this flocking behavior based on Craig Reynolds' original program, using the three aforementioned rules. In the code, each rule has a weighting term which indicates how important the rule is to the boids. By changing the weights, different types of swarms can be modeled. Fish, for example, tend to stay much closer together than birds. So the weighting factor for the cohesion rule would be greater. Insects, on the other hand, don't always tend towards a center or even in the same direction, so those weighting factors would be very low for insects . This yields much more random motion, as one might expect. 

Many other modifications can be made to this simple code. For example, in this version, each boid sees every other boid. But in reality, birds and fish obstruct each other, and so the perceived size of the swarm by each member would be different depending on the location. By defining a radius around each boid that constitutes the visual range of the boid, one can more accurately model the swarming behavior. Additionally, this reduces the number of calculations drastically, and thus increases the speed and number of boids the simulation can handle. For example, my simulation can only handle about 50 to 100 boids before MATLAB runs very slowly. 

Check out the video below to see what my boids look like! For more information about the actual boids programming, click here.

Update 4/22/15: Added mouse tracking capabilities. Boids now follow the mouse pointer! Apologies for the choppy video; it looks like this took up a good chunk of my memory.

MATLAB Project: Accelerometer Position Transducer GUI

For my Instrumentation class, we were tasked with determining the position of a mass on a mechanical oscillator using a transducer. We chose the accelerometer, which is the most difficult transducer to use compared to the others because it has a 2nd order response. Thus, a lot of signal conditioning steps need to be applied to the output of the transducer to find the actual displacement.

Originally, each signal conditioning step was its own MATLAB script. But because the scripts all had different authors, it was difficult for any one of us to go from start to finish with a set of raw data. My solution to this problem was to create a user interface that would allow us to quickly and easily analyze sets of data. The data acquisition would remain its own script and the raw data was saved as a MATLAB data file. The filename is then entered into the GUI and the data is loaded. The static sensitivity of the accelerometer (obtained via calibration) can be entered into the box, but the value from our calibration is already set as the default. The 'Analyze' button does several calculations and makes a few different plots.

The first plot made is just the raw data. The second plot is the magnitude spectrum of the data, so the frequency of our signal and of any noise can be identified. Then the data goes through a bandpass filter to remove the high frequency noise and the DC offset. This filtered voltage as well as its FFT are then plotted. Finally, the signal goes through a double numerical integration to convert the acceleration values into displacement. Because of the cumulative integration technique used, a high pass filter is needed in between integration steps to remove the offset.

Overall I'm quite pleased with how it turned out. I may add more functionality to achieve more of the project's deliverables, but for now this will do.

EDIT: Final Project Report

MATLAB Mini Project: Standing Wave Generator

One of my responsibilities as a teaching assistant at BU Academy was to cover any classes the teacher (Mr. Gary Garber) could not make. This week he is traveling with the BU Academy FIRST Robotics team to the FIRST competitions and I'm covering some of his classes. 

Right now, the class is just starting standing waves. It can be tricky to visualize how the waves actually reflect and interfere with each other. If you're using a spring or a rope to demonstrate this effect, damping is often an issue and other parameters can be difficult to control. If you're using a simulation, the waves usually travel too quickly and it can be difficult to see what's going on. I decided to write a quick MATLAB script to help my students visualize how standing waves form. 

The script basically plots several cycles of a sine wave as it travels down a 'string'. Both the input and the string's response (what we actually see the string doing) are plotted on top of each other so that they can be compared. I took some screencasts and some screenshots to better illustrate the process. It's important to note that this simulation doesn't model resonance or harmonics; it simply reflects the incoming waveform off the wall and adds it to the rest of the wave form. 

This video shows the typical standing wave we are used to seeing. The nodal points can clearly be seen. I took a few other videos showing different inputs, but they don't all fit here. Those videos have been left as an exercise for the reader.

Download the MATLAB file here.

MATLAB Project: Airfoil Generator

I'm taking a class in aerodynamics this semester, and I know we will be working a lot with airfoils. So for fun I decided to write a MATLAB GUI to display any NACA series airfoil. Currently it only works with the 4-series airfoils, but soon I will expand it to work with 5, 6, 7,  8 series airfoils as well.

The program takes inputs of the NACA airfoil number, desired chord length, angle of incidence (AOI), and the wing length. The program then plots each individual airfoil, and lofts the two together in an isometric view. The 'export airfoils' button doesn't work right now, but soon it will export XY coordinates for the airfoils to a text file, so they can be loaded into SolidWorks or another CAD program to make a 3-D model of the wing. 

Download the files to run the program here.